August 2004 - Boost - lists.preview.boost.org

Re:Re:[boost] [serialization] CW8 and the recent changes...
by Robert Ramey 08 Aug '04

08 Aug '04

Rene Rivera wrote: > The most recent changes cause a large number of new warnings to show up. > The are all of the form: > ### mwcc Compiler: > # In: ..\boost\serialization\void_cast.hpp > # From: ..\libs\serialization\test\test_array.cpp > # -------------------------------------------------- > # 188: __declspec(noinline) __declspec(dllexport) > # Warning: ^^^^^^^^ > # illegal type qualifier(s) Thanks, I'm on it - I'll check in a fix soon. I'm still struggling with cwpro8+ but haven't run out of options yet so stay tuned and have patience. Robert Ramey

2 1

[preprocessor] More changes for Digital Mars, and some of the examples.
by Daniel James 08 Aug '04

08 Aug '04

Hello, I've got some more changes for the preprocessor library. I noticed the other day that there are no tests for sequences in the preprocessor library, which meant that I hadn't tested them on Digital Mars, so I missed a couple of changes that were needed there. I've put up a patch at: http://myweb.tiscali.co.uk/calamity/patches/preprocessor-2.patch.gz This also contains some unit tests for sequences (I just took the list tests and made some changes). It also fixes some typos in the examples in the reference documentation. Daniel

1 0

RE:RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

One final thought that didn't occur to me before would be to make your own "provably portable" archive. The current libraries all contain a default "fall through" which handles otherwise unspecified types. This could cause surprises when moving code/archives between environments. The alternative would be to make your own archive (or perhaps a derivation) which restricted the serializable types to those that have been specifically accounted for. More work - but might be necessary to guarantee archive portability. Also this might support the idea that the archives produced be accessable by other applications which don't use the serialization library which normally would be much more awkward to implement. Just a thought. Robert Ramey

1 0

RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

Walter Landry wrote: > I am thinking of using your serialization library as part of another > project [1]. It will be writing files that need to be read by > multiple operating systems far into the future. So I was wondering, > how stable is the output format? I will be serializing maps, lists, > strings, bitsets, and some simple classes. Do you forsee any possible > changes in the disk format of those kinds of objects? This is an exceptionally good question. I'm amazed that no one has yet to raise it. If you don't mind, I will post it to the list as I don't believe others have given this the importance I believe it deserves. Anyway - here's my answer: It is one of the stated goals that this system produce portable archives as well as use portable code. By portable archives I mean archives that can save data structures on one platform (compiler/os/library) and recovered to another. This is not as easy as it might seem. I have take specific steps in the design and implementation to achieve this. a) My preferred archive - the simple text archive saves/loads primitives as text. This is inherently portable across platforms. XML is also portable. The included binary archive is not-portabable. The signature processing code will detect egregious violations of portability and trap with an exception. However this is not an exhaustive check. There is a demo which includes a portable binary archive. Floating point primitives would have to be added to make this complete. Ralf W Grosse-Kunstleve has submitted code that would address this but I haven't spent any time with it. b) I have taken extra pains that certain things are serialized the same way across platforms. Take std::list<int> for example. Practical efficiency considerations suggest that this should be stored without class information. The simple way of specifying this depends upon the usage of TPS which not all environments support. So I have used a different method to accomplish this. c) In the archive signature - there is a library format version index. If the format the archive type changes the newer code could include branch to deal with older format. I'm hoping it will never be necessary to use this but its there - btw - its now at #3. This would be a fallback. Possible problems: a) In practice, true archive portability will require more. For example, suppose I save an integer on a 64 bit machine to a text archive and load it to a machine which supports 32 bits. This would work fine - until the 64 bit machine saves an integer > 2^32 . This problem wouldn't be detected until the archive is loaded - way too late. Note that wchar_t, which is serialized as an integer, is 4 byte on gcc and 2 bytes everywhere else. So its possible/likely that this problem would surface where you least expect it. b) there are subtle problems than can arise. On some machines size_t is a macro that resolves to an integer while on some it's a true type. Saving a datum as an integer in one environment while recovering it as a type ( with a class id ) on another machine create surprises. Worse (or maybe better) this issue could look different for different archives. Text archives save/load book-keeping info (class-id, object-id, etc. in sequence so differences of this type will cause problems. XML archives include this information as attributes in the XML start tag. Attributes are retrieved by tag rather than by sequence (thanks to spirit) so in XML archives might work where the normal text archive fails. The good news is that this problem has been considered as goal from the very start. So all code has been written to accommodate this goal. That bad news is that this facility hasn't been exhaustively tested. What's needed is a separate/additional test suite which tests archive portability. This would mean a set of "canonical archives". The save test would create a new archives and compare each one to its "canonical" canonical counterpart. The load test would load the canonical archive and check to see that we recovered what we expected to. Implementation of such tests would reveal a host of small errors. For example, int64_t is just a typedef with gcc on a 64 platform while its separate type on on a 32 bit platform. This breaks compilation of the polymorphic archive at compiler time. In itself, its not too hard to resolve. But it requires careful thought to resolve it once and for all. Conclusion and recommendation So, if you want to use the serialization library for your project I would suggest. a) Just start doing it. The serialization library saves an incredible amount of coding and you can effectively just get on with the other more intesting parts of your project. b) When its time to think build your app on another platform and transfer archives between environments, you can rethink the issue. This is basically and economic argument. At this point: i) You will have invested no effort in serialization, so if it were deemed unsuitable, you would have lost no investment of effort if you decide to replace it with something else. ii) Maybe you'll get lucky and someone else will have made the archive portability test suite and the archives your interested in can be "guaranteed" portable. iii) If ii) above hasn't happened, you'll have to make your own archive portability test suite. The cost of this is also zero. This is because if you use some alternative to the serialization library, you'll still have to test the passing of serialized data between platforms in any case. If you make an archive portability test suite, please consider adding it to the library and tests. (Hmm - you're an academic - making such a test suite would be a great small project for one of your students. Important, educational, small enough to do in reasonable time, orthogonal to your main project goal - whatever that might be). Thanks for considering the serialization library for your project. Robert Ramey

1 0

detail/iterator.hpp: workaround_test fails with two-phase lookup (+ patch)
by Stefan Slapeta 08 Aug '04

08 Aug '04

On compilers with two-phase lookup (CW*) the workaround_test (range lib) fails because of incorrect typedefs in iterator.hpp. (Yes, I know it's very strange to disable partial specialization on a compiler with two-phase lookup.) OK to commit this patch for detail/iterator.hpp? Stefan Index: iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/iterator.hpp,v retrieving revision 1.30 diff -u -r1.30 iterator.hpp --- iterator.hpp 26 Jul 2004 00:31:59 -0000 1.30 +++ iterator.hpp 5 Aug 2004 09:35:08 -0000 @@ -334,8 +334,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef value_type* pointer; - typedef value_type& reference; + typedef typename std::iterator_traits<Iterator>::value_type* pointer; + typedef typename std::iterator_traits<Iterator>::value_type& reference; }; template <class Iterator> @@ -343,8 +343,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef const value_type* pointer; - typedef const value_type& reference; + typedef const typename std::iterator_traits<Iterator>::value_type* pointer; + typedef const typename std::iterator_traits<Iterator>::value_type& reference; }; # ifdef BOOST_BAD_OUTPUT_ITERATOR_SPECIALIZATION

3 8

return type of arithmetic operators
by beckmann.bremen＠t-online.de 08 Aug '04

08 Aug '04

Hi, I want to use the arithmetic operators from boost/operators.hpp but found something strange. If one takes for example boost::rational which uses boost::addable (and others), it is possible to write the following: boost::rational<int> x, y, z; x + y = z; This is not possible for integral types. Is this intended, considered minor or just overseen? Wouldn't it be better for the arithmetic operators to return const T instead of T? Thank you in advance, Thomas

2 1

[1.32 Plan] release status?
by JOAQUIN LOPEZ MU?Z 08 Aug '04

08 Aug '04

Hi all, I have only limited access to the list these days, so my apologies if there's been some progress in this area that I missed to read about. Are we ready to schedule a final deadline for branching? >From what Alexsey stated last week, I understand we are now in a position to inspect results for all the relevant platforms, and the turnaround cycle is kept under a healthy 24 hours. The issues reports show regressions (red cells) for only five libraries, and the number of yellow cells is, IMHO, resonable, given the many exotic compilers that have been recently introduced in the regression tests. OTOH, the release date has slipped over three weeks now, and I guess we cannot just go on forever fixing things, as it is not realistic to expect that every issue be resolved in a reasonable amount of time. Maybe having some fixed schedule for branching will help concentrate on those problems that are really important. Just my 2 cents. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

concept_check: abnormal termination on CW 8.3?
by Stefan Slapeta 07 Aug '04

07 Aug '04

This concept_check test case http://tinyurl.com/5q3zk on CW 8.3 looks like an abnormal termination. Please could somebody with access to this compiler verify that? Stefan

3 2

[serialization] CW8 and the recent changes...
by Rene Rivera 07 Aug '04

07 Aug '04

The most recent changes cause a large number of new warnings to show up. The are all of the form: ### mwcc Compiler: # In: ..\boost\serialization\void_cast.hpp # From: ..\libs\serialization\test\test_array.cpp # -------------------------------------------------- # 188: __declspec(noinline) __declspec(dllexport) # Warning: ^^^^^^^^ # illegal type qualifier(s) # (included from: # base_object.hpp:30 # nvp.hpp:26 # interface_oarchive.hpp:26 # common_oarchive.hpp:20 # basic_xml_oarchive.hpp:28 # xml_oarchive.hpp:30 # xml_archive.hpp:8 # test_tools.hpp:108 # test_array.cpp:20) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[boost.thread] regression on vc7.1
by Bronek Kozicki 07 Aug '04

07 Aug '04

Apparently there's some problem with tss on vc7.1, see http://tinyurl.com/5zqrs . I will look into it later today. I hope that we still have time to fix it, no need to pull static library support out of release 1.32. B.

2 1