- Boost - lists.preview.boost.org

Re:[boost] [serialization] export macros
by Robert Ramey 13 Aug '04

13 Aug '04

> Is there an alternative to the macros for registering types? > (A sample program exhibiting what I am trying is attached.) Have you considered using "forward registration" rather than EXPORT? int main() { Status< Algo< int, double > >* p_s = new DerivedStatus< Algo< int, double > >; ====> boost::archive::text_oarchive oa(std::cout); oa.boost::archive::register_type( static_cast<DerivedStatus_Algo_int_double *>(NULL) ); oa << p_s; } Robert Ramey

1 0

Re:[boost] [serialization] export macros
by Robert Ramey 13 Aug '04

13 Aug '04

> Does anyone know a work around that does not need the typedefs? I had > a look at the preprocessor library but I couldnt come up with a > solution. Is there an alternative to the macros for registering types? The BOOST_CLASS_EXPORT facility has been a struggle to get implemented so that it can be used in a natural way. Besides the problem you mention here (which is a new one for me) There were some new ones that have become apparent with compilers that use two-phase lookup. Another problem is over-zealous unreachable code optimization of some compilers eliminates the code that implements the serialization. The fix for this is inherently non-portable. Subject to the above it does work - but is kind of fragile and really not quite right - it will need to be re-implemented (yet) again. So I'm interested in your cases. Is it possible you could make a few boostified test programs that we would like to see work but currently fail at compile time? The really funny part about BOOST_CLASS_EXPORT is that is started out soooo simple and ends up touching on all sorts of unexpected difficulties. The good part is that its not a fundamental building block of the system so fixing it up won't impact the rest of the system. So there is hope. Robert Ramey

1 0

date_time broken on intel-win32-8.0
by Stefan Slapeta 13 Aug '04

13 Aug '04

http://tinyurl.com/4y6tx LINK : fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-gd-1_32.lib' Has anybody an idea where to search? Stefan

3 5

regex win32 memory leaks
by Thomas Witt 13 Aug '04

13 Aug '04

Hi, I am having a windows MFC app that dynamically links to the regex lib. On application shutdown the memory leak detection kicks in and diagnoses leaks in the regex dll. If I use the static lib everything seems to be fine. I have to admit that I don't have a clue what's going on. Any ideas? Thomas BTW this is vc-7.1 boost 1.31 -- Thomas Witt witt(a)acm.org

3 2

RE: [boost] [serialization] BOOST_CLASS_EXPORT_GUID: expected `; ' before '('
by Rob Lievaart 13 Aug '04

13 Aug '04

Hi, The load tests need the output of the save tests, but they are not run in that order. If you run the tests again, then the output from the previous run should still be there, and then you can see if they actually pass or not Kind regards, Rob Lievaart. > Unfortunately, I see new failures in the > test_level_class_info_load_*_archive test that > http://boost.sourceforge.net/regression-logs/cs-Linux.html (dated > 2004-08-12) reports as passing. The test output does not tell me much: > > serialization - test_level_class_info_load_binary_archive - gcc > > Linker output: > > Chmod1 > ../bin/boost/libs/serialization/test/test_level_class_info_load_binary_archi ve.test/gcc/debug/test_level_class_info_load_binary_archive > > > Run output: > > Exception in "call_test_main": std::exception: stream error > > *** errors detected in test case "call_test_main"; see standard output > for details > Test case "call_test_main" was aborted due to uncaught exception, user > assert or system error > > EXIT STATUS: 200

2 1

[serialization] BOOST_CLASS_EXPORT_GUID: expected `; ' before '('
by Christoph Ludwig 13 Aug '04

13 Aug '04

Hi, the regression logs (dated 2004-08-10) show that, e.g., test_exported_text_archive fails for gcc 3.4.1: http://tinyurl.com/3tek6. That's the same problem I mentioned today in another post; in a simple test case I could solve the problem with the attached patch. However, I am not going to pretend that I understand how all the specializations and explicit instantiations in the export machinery interact. And I didn't have time yet to run a more complex test or the regression tests against the patched version. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 1

[boost.test] Visibility problem in fixed_mapping.hpp
by Markus Schöpflin 13 Aug '04

13 Aug '04

In my efforts to make boost.test compile with tru64cxx65 I came about the following issue. Currently, class fixed_mapping contains a private member called elem_type which is later on used in the inline definition of an operator() contained in two inline structs. class fixed_mapping { typedef ... elem_type; struct p1 : public ... { bool operator()(elem_type const &x, ...) { ... } } }; My compiler complains that elem_type is inaccessible in the definition of operator() and I think it is right to complain. I fixed this by making elem_type public, but possibly operator() could be made a friend of fixed mapping as well. Markus

3 3

[serialization] export macros
by Christoph Ludwig 13 Aug '04

13 Aug '04

Hi, working with the post-review version #20 of the serialization library, I encountered problems with respect to the export macros (BOOST_CLASS_EXPORT_GUID etc.). I decided to check the Boost CVS for changes - but it turns out the problems became worse :-( (FWIW, I use gcc 3.4.1 on a Linux x86 machine.) I need to register class template specializations that have several arguments. Unfortunately, the preprocessor does not know about template argument lists and treats the 2nd, 3rd,... template argument as separate macro arguments. Therefore, the expansion of the export macros fails due to a wrong number of macro arguments. It does not help to surround the template-id with parentheses since after the macro expansion the argument is used as a template argument itself and the compiler rejects the "superfluous" parentheses in the new template argument list. With serialization#20 I had the workaround to define a typedef for the template specialization within an anonymous namespace. I could then pass this typedef to the export macros. But this approach becomes soon impractical if you write a library with internal class templates depending on some user defined types. Does anyone know a work around that does not need the typedefs? I had a look at the preprocessor library but I couldnt come up with a solution. Is there an alternative to the macros for registering types? (A sample program exhibiting what I am trying is attached.) Anyway, with the current CVS, even above mentioned workaround fails; I am going to discuss the reason in a separate posting. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

3 3

range broken in current cvs
by Neal Becker 13 Aug '04

13 Aug '04

Just updated from mainline cvs. Then even range.hpp by itself will not compile: g++34 -x c++ -fsyntax-only -I /usr/local/src/boost.cvs /usr/local/src/boost.cvs/boost/range.hpp In file included from /usr/local/src/boost.cvs/boost/range.hpp:21: /usr/local/src/boost.cvs/boost/range/sub_range.hpp:66: error: `iterator' does not name a type /usr/local/src/boost.cvs/boost/range/sub_range.hpp:66: error: (perhaps `typename boost::iterator_range<typename boost::result_iterator_of<C>::type>::iterator' was intended) /usr/local/src/boost.cvs/boost/range/sub_range.hpp:68: error: `iterator' does not name a type /usr/local/src/boost.cvs/boost/range/sub_range.hpp:68: error: (perhaps `typename boost::iterator_range<typename boost::result_iterator_of<C>::type>::iterator' was intended)

3 3

Request to regression testers
by Michael Stevens 13 Aug '04

13 Aug '04

Firstly thanks to all those currently running regression tests, they really are very useful. I'm not sure what load the meta-comm web server gets but I am certainly accessing the results on a regular basis! At the moment the only thing the regression test system cannot do automatically is purge stale targets that are no longer part of the build. By the look of the results some regression testers are conservative and delete the target bin directories. Would it be possible for 'RubeckAssociates' and 'Martin Wille' to do this on a one of basis. I have a test7 in ublas which was only temporarily part of the regression run. The old stale results are somewhat confusing the test picture. Thanks! Thanks, Michael

3 2