quantity-devel Mailing List for Quantities
Brought to you by:
berndspeiser
Menu
▾
▴
quantity-devel — discussion between Quantities developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(28) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ber...@t-...> - 2007-04-10 08:29:11
|
Dominik Brugger wrote: > Hi, > > well this is certainly one of the many "feature clashs" that > make C++ so troublesome. The core problem is > instantiation of templates, which occurs *after* the preprocessor > run. For this reason no automatic generation of names > is possible for template classes. > > The only solution I see is the one proposed in the newsgroup, > that is using typeid. This will obviously work as long as we > use the same compiler and portability across different platforms > is not an issue. We could establish an additional mechanism, which is maybe not VERY elegant, but it should work: we add a static const std::string ID to each class to be serialized (we have to add some code anyway ...). This can be related to the Name of the class, in the case of templates, we need also to code in some way the ID of parametrizing classes. I had done this for the old version of XML save/load in ExcitationFunction. Although this will be obsolete soon (when we have introduced the sreialization concept), it might be a model. Now, I have started to do something like this in the context of serialization with the Quantity classes. I will upload this to cvs later this morning. I have coded into this template serialization ID (TSID) the Quantity, the storage unit and the mode of the quantity into one string, which is then given to BOOST_CLASS_EXPORT_GUID - unfortunately not yet automatically. I am afraid - and I agree with the above - that we might have to substitute the preprocessor macros by some template construct ... Another problem which I have in the moment, is that I need to code the `storage type' (i.e., is the Quantity given as int, double, bool, etc) into the TSID. Does anyone know about some code which does convert a POD type into a corresponding string? Also, the TSID construction is not yet complete for some units (the Composed units) and some modes of quantities. Bernd -- ======================================================================= Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2007-04-09 08:54:01
|
Dominik Brugger wrote: > Hello, > > yesterday it was correctly pointed out by Bernd Speiser, > that serialization of whole class hierarchies necessitates > the usage of the Factory design pattern. > > But it is not necessary to wrap up boost::serialization > with this kind of mechanism as it is already provided by > the library. > > To illustrate the serialization capabilities consider the > example program below. One important point are the > BOOST_EXPORT_GUID makros which equip each > class with a globally unique identifier. If these are > omitted the code will compile, but when reading back > the objects at runtime an exception of type "unregistered class" > will be thrown. Otherwise the objects are correctly read > back without knowing the exact type (polymorphic base*). > > Dominik Brugger Hi, yes, I am convinced in the meantime. Test with the Quantity library show thatb it indeed works in this way. (this is why I crosspost this e-mail to the quantity-devel list). One problem remains which has already been discussed several times in the boost mailing list (see, http://thread.gmane.org/gmane.comp.lib.boost.user/13244/focus=13300): automatic `registration' of template classes is not possible. This means that we explicitly have to register all necessary instances of a templare class with the serialization library. I have no clear idea in the very moment how to overcome this. One important aspect of this may also be that we have to assemble the unique identifier names for templated classes. Anyway, I will try to finalize the Quantity classes for serialization quickly. Bernd > > #include <boost/archive/xml_iarchive.hpp> > #include <boost/archive/xml_oarchive.hpp> > #include <boost/serialization/serialization.hpp> > #include <boost/serialization/base_object.hpp> > #include <boost/serialization/nvp.hpp> > #include <boost/serialization/export.hpp> > #include <fstream> > #include <iostream> > > class base > { > public: > base() : data(3.14) {} > virtual void print() > { > std::cout << "base.data " << data << std::endl; > } > private: > friend class boost::serialization::access; > template<class Archive> > void serialize(Archive & ar, const unsigned int file_version) > { > ar & BOOST_SERIALIZATION_NVP(data); > } > double data; > }; > > class derived1 : public base > { > public: > derived1() : derived1_data(42) {} > virtual void print() > { > base::print(); > std::cout << "derived1.data " << derived1_data << std::endl; > } > private: > friend class boost::serialization::access; > template<class Archive> > void serialize(Archive &ar, const unsigned int file_version) > { > ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(base) > & BOOST_SERIALIZATION_NVP(derived1_data); > } > int derived1_data; > }; > > class derived2 : public base > { > public: > derived2() : derived2_data(123) {} > virtual void print() > { > base::print(); > std::cout << "derived2.data " << derived2_data << std::endl; > } > private: > friend class boost::serialization::access; > template<class Archive> > void serialize(Archive &ar, const unsigned int file_version) > { > ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(base) > & BOOST_SERIALIZATION_NVP(derived2_data); > } > int derived2_data; > }; > > BOOST_CLASS_EXPORT_GUID(base, "base"); > BOOST_CLASS_EXPORT_GUID(derived1, "derived1"); > BOOST_CLASS_EXPORT_GUID(derived2, "derived2"); > > void save(const char *testfile) > { > std::ofstream os(testfile); > boost::archive::xml_oarchive oa(os); > > base *b1 = new derived1(); > base *b2 = new derived2(); > > oa << BOOST_SERIALIZATION_NVP(b1); > oa << BOOST_SERIALIZATION_NVP(b2); > > delete b1; > delete b2; > } > > void load(const char *testfile) > { > std::ifstream is(testfile); > boost::archive::xml_iarchive ia(is); > > // Note that we do not know anything about the type > // of stored objects at this point > base *b1 = NULL; > base *b2 = NULL; > > // The factory design pattern is already included in > // boost::serialization > ia >> BOOST_SERIALIZATION_NVP(b1); > ia >> BOOST_SERIALIZATION_NVP(b2); > > // Dump to stdout to check that we read back the right > // types > std::cout << "Read: "; > b1->print(); > std::cout << "Read: "; > b2->print(); > > delete b1; > delete b2; > } > > int main(int argc, char* argv[]) > { > // Note that calls to save/load can be made in > // different program runs, compilation units etc. > save("test.xml"); > load("test.xml"); > return EXIT_SUCCESS; > } -- ======================================================================= Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2007-02-12 17:23:26
|
Dear all, due to the incompatibilities in compiling Quantities with gcc 3.3.3 and=20 4.1.2, I branched the cvs tree into the main trunk (compatible with gcc=20 4.1.2) and a branch `oldgcc' (compatible with at least gcc 3.3.3). Please take into account this change if you extract code from cvs. Nest regards Bernd --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bernd Speiser Institut f=FCr Organische Chemie Auf der Morgenstelle 18 D-72076 T=FCbingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: <ber...@t-...> - 2007-02-12 17:20:30
|
Hi all, I have just released a new version of the Quantities code and also of=20 BSUtilities. As you can see, there are now two versions of the=20 Quantities code. The reason for this is the following: For earlier versions, we had used gcc 3.3.3 as the compiler. Most of the = code compiled just fine, although in the latest release it was no longer = possible to compile the test programs. This has now been corrected.=20 However, when I tried to compile the code with gcc 4.1.2 (part of the=20 new openSuSE 10.2 distribution), errors prohibited the success of the=20 compilation, most probably due to much more strict adherence to the C++=20 standard. These bugs have now been corrected and the resulting code is in=20 BSUtilities-0.6.1 and Quantities-1.2.1. Unfortunately, it turned out=20 that some changes were not backwards compatible with gcc 3.3.3.=20 Therefore, I provided also a package Quantities-1.2.1-oldgcc, which=20 should be used with older versions of the compiler. I can not determine=20 at the moment, which of the intermediate compiler versions will compile=20 each of the codes. The BSUtilities-0.6.1 release is valid for both=20 Quantities releases. Best regards Bernd -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bernd Speiser Institut f=FCr Organische Chemie Auf der Morgenstelle 18 D-72076 T=FCbingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: <ber...@t-...> - 2006-04-24 16:29:31
|
Kai Ludwig wrote: > Thank you Bernd, > > >>So ---------------------> please download a recent cvs-Version of Loki >>to get rid of this warning. > > > now, there is a new Loki release 0.1.4 available. > It seems to work well. However, for the > installation of the lokilib.a with g++ > a patch was necessary (reported in one > of the mailing lists): One must add > > #include <stdint.h> > > in loki's SmartPtr.h (e.g. at line 42) > > Regards > Kai > > > All right - seems to work. Has been installed on echem9 also. Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2006-04-24 12:30:44
|
Thank you Bernd, > So ---------------------> please download a recent cvs-Version of Loki > to get rid of this warning. now, there is a new Loki release 0.1.4 available. It seems to work well. However, for the installation of the lokilib.a with g++ a patch was necessary (reported in one of the mailing lists): One must add #include <stdint.h> in loki's SmartPtr.h (e.g. at line 42) Regards Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Mail: kai...@un... |
|
From: Bernd S. <ber...@un...> - 2006-04-24 09:20:18
|
Kai Ludwig wrote: Kai, here is what I wrote on Jan 14, 2006 in an e-mail to the Quantity devel list: Dear quantity develop members, I will upload to cvs in a minute a new version of the Quantity library code, which has some important improvements for future work. Unfortunately, I had to do quite a bit of changes, when starting to use the most recent Loki library (v. 0.1.3). So, if you download and install the most recent version, please make sure you have installed the most recent Loki library. Have fun Bernd Maybe I should have sent this to the quantity users list as well, sorry ... But the problem is also somewhere else, see the following mail to the EChem++ devel list on Feb 23, 2006: Hi, I have just downloaded and installed on echem9 the most rcent version of the loki library (cvs version). It has been installed in parallel to the previous (stable) version 0.1.3. Th enew headers and the library are available through the same paths as the previous ones, which have been moved to /usr/lib/libloki-0.1.3 and /usr/include/loki-0.1.3. I needed the new version due to a bug which has been fixed upon my request. The cvs version of EChem++ should not be influenced by this. Once I upload the Experiment hierarchy you might need to use the new loki lib also on your local machines. Best regards Bernd So ---------------------> please download a recent cvs-Version of Loki to get rid of this warning. Regards Bernd > g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"Quantities\" > -DVERSION=\"1.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I.. -I/usr/include/loki > -I/home/kl/software/src/quantity/BSUtilities -Wall -Werror -W -pedantic > -MT libGeneralQuantities_la-Digital.lo -MD -MP -MF > .deps/libGeneralQuantities_la-Digital.Tpo -c Digital.cc -fPIC -DPIC -o > .libs/libGeneralQuantities_la-Digital.o > /usr/include/loki/Functor.h: In copy constructor ` > Loki::Private::FunctorImplBase<R, ThreadingModel>::FunctorImplBase(const > Loki::Private::FunctorImplBase<R, ThreadingModel>&) [with R = > quantity::DedimReturn<quantity::Quantity<quantity::digital::Dimension, > quantity::digital::Unit, quantity::digital::Units, > quantity::digital::Unity, > bool>, quantity::digital::Unity>, ThreadingModel = Loki::SingleThreaded]': > /usr/include/loki/Functor.h:917: instantiated from > `Loki::FunctorHandler<ParentFunctor, Fun>* > Loki::FunctorHandler<ParentFunctor, Fun>::DoClone() const [with > ParentFunctor = > Loki::Functor<quantity::DedimReturn<quantity::Quantity<quantity::digital::Dimension, > quantity::digital::Unit, quantity::digital::Units, > quantity::digital::Unity, bool>, quantity::digital::Unity>, > Loki::Typelist<Loki::Tuple<Loki::Typelist<Loki::EmptyType, Loki::NullType> > >>, Loki::NullType>, Loki::SingleThreaded>, Fun = > > quantity::DedimReturn<quantity::Quantity<quantity::digital::Dimension, > quantity::digital::Unit, quantity::digital::Units, > quantity::digital::Unity, bool>, quantity::digital::Unity> > (*)(Loki::Tuple<Loki::Typelist<Loki::EmptyType, Loki::NullType> >)]' > /usr/include/loki/Functor.h:68: instantiated from here > /usr/include/loki/Functor.h:61: warning: base class `class > Loki::SmallObject<Loki::SingleThreaded, 4096, 256, 4, > Loki::LongevityLifetime::DieAsSmallObjectParent>' should be explicitly > initialized in the copy constructor > make[2]: *** [libGeneralQuantities_la-Digital.lo] Fehler 1 > make[2]: Leaving directory > `/home/kl/software/src/quantity/Quantities/GeneralQuantities' > make[1]: *** [install-recursive] Fehler 1 > > -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2006-04-24 09:00:06
|
Helle Bernd, today, I've done a new checkout of the quantity CVS tree in order to compile the experiment hierarchy of EChem++. Below you find the error message that occured during compilation of the quantity lib. Regards, Kai g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\= "\" -DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"Quantiti= es\" -DVERSION=3D\"1.2\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1 -DHAVE_MEMO= RY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1 -DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 -I. -I. -I.. -I/usr/include/loki -I/home/kl/software/src/quantity/BSUtilities -Wall -Werror -W -pedantic -MT libGeneralQuantities_la-Digital.lo -MD -MP -MF .deps/libGeneralQuantities_la-Digital.Tpo -c Digital.cc -fPIC -DPIC -o .libs/libGeneralQuantities_la-Digital.o /usr/include/loki/Functor.h: In copy constructor ` Loki::Private::FunctorImplBase<R, ThreadingModel>::FunctorImplBase(con= st Loki::Private::FunctorImplBase<R, ThreadingModel>&) [with R =3D quantity::DedimReturn<quantity::Quantity<quantity::digital::Dimension, quantity::digital::Unit, quantity::digital::Units, quantity::digital::Unity, bool>, quantity::digital::Unity>, ThreadingModel =3D Loki::SingleThrea= ded]': /usr/include/loki/Functor.h:917: instantiated from `Loki::FunctorHandler<ParentFunctor, Fun>* Loki::FunctorHandler<ParentFunctor, Fun>::DoClone() const [with ParentFunctor =3D Loki::Functor<quantity::DedimReturn<quantity::Quantity<quantity::digital:= :Dimension, quantity::digital::Unit, quantity::digital::Units, quantity::digital::Unity, bool>, quantity::digital::Unity>, Loki::Typelist<Loki::Tuple<Loki::Typelist<Loki::EmptyType, Loki::NullType= > >, Loki::NullType>, Loki::SingleThreaded>, Fun =3D quantity::DedimReturn<quantity::Quantity<quantity::digital::Dimension, quantity::digital::Unit, quantity::digital::Units, quantity::digital::Unity, bool>, quantity::digital::Unity> (*)(Loki::Tuple<Loki::Typelist<Loki::EmptyType, Loki::NullType> >)]' /usr/include/loki/Functor.h:68: instantiated from here /usr/include/loki/Functor.h:61: warning: base class `class Loki::SmallObject<Loki::SingleThreaded, 4096, 256, 4, Loki::LongevityLifetime::DieAsSmallObjectParent>' should be explicitly initialized in the copy constructor make[2]: *** [libGeneralQuantities_la-Digital.lo] Fehler 1 make[2]: Leaving directory `/home/kl/software/src/quantity/Quantities/GeneralQuantities' make[1]: *** [install-recursive] Fehler 1 --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Mail: kai...@un... |
|
From: <ber...@t-...> - 2006-01-14 18:05:29
|
Hi, I forgot to mention: please also make a top level cvs checkout of Quantities in order get all necessary files! Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2006-01-14 17:52:02
|
Dear quantity develop members, I will upload to cvs in a minute a new version of the Quantity library code, which has some important improvements for future work. Unfortunately, I had to do quite a bit of changes, when starting to use the most recent Loki library (v. 0.1.3). So, if you download and install the most recent version, please make sure you have installed the most recent Loki library. Have fun Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2006-01-10 17:17:03
|
Hi, I have done some changes in Quantities to prepare for some important additional functionality. I have just uploaded some changes to cvs. Please get the files with an update. Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2006-01-03 17:44:40
|
Dear all, I have just deleted a couple of empty and obsolete directories from the Quantities tree. If you want to get rid of them use a top level checkout -P. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2005-06-12 19:27:53
|
Dear all, I changed the default value of the optimize flag in Quantities configure.in back to diabled, since I realized who long it takes to compile the test program with optimization switched on. After downloading the most recent cvs-version, please type bootstrap and re-configure before compiling. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Bernd S. <ber...@un...> - 2005-06-06 11:32:29
|
Kai Ludwig wrote: > Hello Bernd, > > in file QuantityCluser.h (line 487). > Wouldn't it be better to declare > the length and number functions as > 'const' ? > I want to call these functions from > another const member function. OK, done BS -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: Kai L. <kai...@un...> - 2005-06-06 09:31:52
|
Hello Bernd, in file QuantityCluser.h (line 487). Wouldn't it be better to declare the length and number functions as 'const' ? I want to call these functions from another const member function. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: +49-7071-29-73049 Mail: kai...@un... |
|
From: Bernd S. <ber...@un...> - 2005-03-14 09:55:19
|
Hi, Kai and I have just added some additional information to the Quantities build process. Since this has implications on EChem++ developers, I am sending this to both lists! The most recent version is located on the cvs server. The new options are explained in the README and README_FIRST files, as well as in the on-line documentation. Please read carefully. In particular, the default settings for the optimize option has been changed, and a new option for switching on the Werror flag of the gcc compiler have been added. While devleoping Quantities, you should use --disable-optimize and --enable-Werror when configuring the package. When you just use Quantities, you may keep the default values. Apart from this, the newest version has some bug fixes and minor improvements in the code. Have fun. Best regards Bernd -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: <ber...@t-...> - 2005-03-11 16:56:50
|
Hi, after including the new --enable-optimize flag into the autotool support for the Quantities library, I checked the compiler flags used. I find that a flag that I used to have in my old makefiles was -Werror. This makes all warnings to errors. I always thought it a good idea to get even all warnings wiped out, and possibly have cleaner code than without that flag (see also Alexandrescu and Sutter's comment: `The compiler is your friend'). There might be some reason for taking this out (e.g., some of you have some nasty problem with a warning which you may NOT be flagged as error ...), but let's discuss the various possibilities. I would vote in favor of the stricter flag, i.e. including -Werror. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Bernd S. <ber...@un...> - 2005-03-07 15:05:13
|
Hi all, according to Kai's suggestions I have changed the recent namespace naming scheme in Quantities into yet a new one: Symbols for the individual PhysicalQuantitie Xxx are now in namespaces xxx (lower case, without underscore), respectively. Sorry for the inconvenience. I hope that now some of the linking problems will disappear. Please let me know. Also, the Experiment and ExcitationFunction code has been adapted to these changes. Furthermore, a PowerEtSegment has been added for the sake of Alain's GUI. Best regards and have fun Bernd -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: Bernd S. <ber...@un...> - 2005-01-25 15:35:39
|
I have just uploaded a new version of Quantities to the cvs server. This contains a couple of bug fixed, but mainly a new scheme for standardization and reverse standardization (i.e., recalculation) of values between units. In particular, the design of the class hierarchies was changed in such a way that now standardization is no longer the responsibility of a Unit (which shouldn't know about the existence of recalculation anyway) but rather of a Quantity. In the process of these changes, also a couple of changes in names of classes were introduced (mainly, low level stuff). Please use the new version after checkout, and do inform me of any problems encountered. Regards and gave fun Bernd -- =================================================================== Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser =================================================================== |
|
From: <ber...@t-...> - 2004-07-14 19:02:35
|
resending since I received an error message from the mail system -------- Original Message -------- Subject: Re: [Quantity-devel] temperature conversion Date: Mon, 12 Jul 2004 17:32:22 +0200 From: ber...@t-... (Bernd Speiser) Reply-To: ber...@un... To: ber...@un... CC: qua...@li..., qua...@li... References: <40E...@un...> <40E...@un...> <40F...@un...> Bernd Speiser wrote: As regards the "implicit conversion" problem, > CelsiusTemperature Tc2 (0.); > ThermodynamicTemperature Tt3 (298.15); > ThermodynamicTemperature Tt4a = Tt3 + Tc2; // prints 298.15 K (wrong) > ThermodynamicTemperature Tt4b = Tc2 + Tt3; // prints 571.3 K > CelsiusTemperature Tc4a = Tt3 + Tc2; // prints 25 oC > CelsiusTemperature Tc4b = Tc2 + Tt3; // prints 298.15 oC (wrong) this was related to a non-safe operator+=, which accepted ANY quantity as a right hand side operand. This has now been changed. The above addition statements do no longer compile, as one should expect. Explicit conversion between the temperatures is still possible. The new version has just been uploaded to cvs. Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2004-07-11 15:20:17
|
Bernd Speiser wrote: > > What possible solutions do we have? > > (1) decide for one of the above - but which one? - and accept the situation > (2) remove DegreeCelsiusTemperature from TemperatureGroup and put it into a > new GT, simultaneously disallow operations between objects of same > dimension > but different variable type. This would require an explicit > conversion if > arithmetics between the types are desired, which would not be > possible with > the present constructors. I tried to solve the problem by separating Temperatures into ThermodynamicTemperature (in K and DegreeRankine, according to the Mills book), CelsiusTemperature, and FahrenheitTemperature, by updating the conversion and assignment operators in Variable (which was good to do anyway; before copy construction and assignment was certainly not strict enough), and by providing explicit conversion methods for the *Temperatures. Now, one can e.g. explicitly convert CelsiusTemperature into ThermodynamicTemperature before performing an addition. Then, of course, addition becomes commutative, although, e.g. the additions in CelsiusTemperature Tc2 (0.); ThermodynamicTemperature Tt3 (298.15); ThermodynamicTemperature Tt4a = Tt3 + Tc2; // prints 298.15 K (wrong) ThermodynamicTemperature Tt4b = Tc2 + Tt3; // prints 571.3 K CelsiusTemperature Tc4a = Tt3 + Tc2; // prints 25 oC CelsiusTemperature Tc4b = Tc2 + Tt3; // prints 298.15 oC (wrong) yield different results! On the other hand, ThermodynamicTemperature Tt5 = Tt3 + ThermodynamicTemperature (Tc2); ThermodynamicTemperature Tt6 = ThermodynamicTemperature (Tc2) + Tt3; yield the same result (571.3 K). So, in my opinion, in lieu of a possibility to disallow mixed expressions completely, there should be extreme care with such mixed cases, and explicit conversion should ALWAYS be used. Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2004-07-09 15:00:27
|
I have fixed the Fahrenheit bug.
However, another problem appeared:
If we perform arithmetic operations (e.g., add, operator+) with objects from the
same group (e.g., TemperatureGroup), but with different Unit (e.g., of type
Temperature, with U = DefaultUnit = Kelvin, and of type
DegreeCelsiusTemperature, with U = DegreeCelsius), then incompatibilities arise.
Either the addition operation is no longer commutative, or the results are
commutative, but counter-intuitive.
For example, if we have (with rounded values)
Temperature T1 (298.0); // T1 = 298.0 K = 25 oC
DegreeCelsiusTemperature T2 (0.); // T2 = 0 oC = 273 K
then, when (1) we recalculate the value of the second operand to that of the
first and perform the addition, we get
T1 + T2 = 571 K i.e. 298 K + (recalculated from 0 oC) 273 K, result in
Kelvin
T2 + T1 = 25 oC i.e. 0 oC + (recalculated from 298 K) 25 oC
The problem is that 25 oC != 571 K, and might be worse if we do someting like
T = T1 + T2 + T3 ...
When (2) we perform the addition always in the default unit (Kelvin) and
recalculate to the result unit after the addition, we get
T1 + T2 = 571 K i.e. 298 K + (recalculated from 0 oC) 273 K, result in
Kelvin
T2 + T1 = 298 oC i.e. (recalculated from 0 oC) 273 K + 273 K = 571 K,
recalculated into 298 oC
In the second case, the two values can be interconverted ok (i.e. 298 oC are 571
K), but we would intuitively expect the result to be 25 oC + 0oC = 25 oC.
What possible solutions do we have?
(1) decide for one of the above - but which one? - and accept the situation
(2) remove DegreeCelsiusTemperature from TemperatureGroup and put it into a
new GT, simultaneously disallow operations between objects of same dimension
but different variable type. This would require an explicit conversion if
arithmetics between the types are desired, which would not be possible with
the present constructors.
Any ideas?
Bernd
--
=======================================================================
Bernd Speiser
Institut f"ur Organische Chemie
Auf der Morgenstelle 18
D-72076 T"ubingen
Germany
phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory)
fax: +49-7071-295518
e-mail: ber...@un...
Internet: http://www.uni-tuebingen.de/speiser
=======================================================================
|
|
From: <ber...@t-...> - 2004-07-09 08:21:17
|
Kai Ludwig wrote: Kai, > just implemented a combo box for temperature units. > As we discussed yesterday, I check the available units > with the allsymbols() method: > > YK .... well, I can see the problem. There might be several solutions: (1) as you suggested, there could be a `selective' method, e.g. commonsymbols () - but how would one make the selection in a proper way. The selection will probably depend on the application! (2) we have a method, say nonprefixsymbols (), which returns only the `main' units whithout all those having the prefixes attached. This would lead to a loss of information since the prefixes are lost in all cases, even those where one wants to have them attached. (3) the application deals with the selection by displaying only those units, which are deemed important in the present context. I'd suggest solution (3) in the moment. Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: <ber...@t-...> - 2004-07-09 08:16:39
|
Hi, I just uploaded to the cvs server a re-written version of Quantities which now includes conversion betwwen units which have a more complex relation than just proportionality, e.g. Kelvin and DegreeCelsius in the Temperature quantity. There is still a bug in the DegreeFahrenheit, but I hope to resolve this during the day and will upload that also. After download, please re-make the complete library, since almost all physical quantity definitions have changed. Hope this works fine. Regards Bernd -- ======================================================================= Bernd Speiser Institut f"ur Organische Chemie Auf der Morgenstelle 18 D-72076 T"ubingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: ber...@un... Internet: http://www.uni-tuebingen.de/speiser ======================================================================= |
|
From: Kai L. <kai...@un...> - 2004-07-07 07:31:52
|
Bernd, find attached files that support surface concentration. Kai --=20 http://echempp.sourceforge.net Kai Ludwig Institut f=FCr Organische Chemie Auf der Morgenstelle 18 72076 T=FCbingen Tel.: 07071/29-73049 Mail: kai...@un... |
