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

[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

mingw-stlport toolset
by Janusz Piwowarski 13 Aug '04

13 Aug '04

Hello, I created these toolset trying to run program_options library (mingw actually doesn't support wide char streams). Maybe it could be useful for someone else. Regards, Janusz

2 2

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

13 Aug '04

>However, this problem is by no means specific to the serialization >library. Whenever you have a macro that takes a classname you may face >this issue. One could consider it a (inherent) preprocessor >shortcoming solved by means of template programming. Therefore the >preprocessor library or one of the libraries from Boost's Generic >Programming and Template Metaprogramming sections seem a more natural >place to me for such a tool. Of course, I don't know if one of the >authors of these libraries agrees and plans to eventually include such >a template. >Since the next release is (hopefully) not long away I'd only mention >this workaround in the documentation of the export macros. Once the >release is out and everything has settled down there's time to discuss >where this template belongs. >This template requires so few keystrokes that for the time being the >users that need it can easily provide it themselves. But in order to >avoid unnecessary bloat of Boost I wouldn't like to see it duplicated >in several Boost libraries in the end. Wow a very clear and concise explanation - I'm sold - I'll just tweak the docs and declare victory. Robert Ramey

1 0

Re:[boost] Re: [serialization] BOOST_CLASS_EXPORT_GUID: expected
by Robert Ramey 13 Aug '04

13 Aug '04

David Abrahams wrote: >"Robert Ramey" <ramey(a)rrsd.com> writes: >> If any Jamfile guru wants to explain a convenient way to require certain >> tests to be performed in a certain order I would be very grateful. >You could make one dependent on another. But why do you need to do >that? A few demos/tests are really a pair - one to save and one to load. In some cases this was to illustrate the fact that the system worked even though saveing and loading were not done in the same program which apparently wasn't altogether clear otherwise. In other cases, the tests are separate executables because, its possible that the version of class has changed but the version it was save under is the previous one so it's a lot more clear to check this case with a pair of tests. That is, class serialization traits can be changed but if we load an older archive, the traits have to be the ones that the archive used when saved. There's an opportunity for confusing the current serialization traits with the "historical ones" hence the separate executables. In the future this will probably be even more necessary as there really is a need to test for archive portability. This means having/creating canonical archives to test against before testing load. I don't remember all the scenarios but in testing persistence, it can be convenient to specify sequence. On the other hand, I'm pretty reluctant to make my Jamfile for serialization/test any more elaborate than it already is since I don't realy feel I understand the jam system all that well. Robert Ramey

1 0

[Serialization] doc error
by Christoph Ludwig 12 Aug '04

12 Aug '04

Hi, libs/serialization/doc/headers.html gives an overview when to include which serialization headers. (Robert, this overview turned out to be quite helpful!) However, some of the paths stated are wrong: The documentation lists all headers in the section `Serializations Declaration' under boost/archive, but they are actually in boost/serialization. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 0

true64cxx and toupper
by Gennadiy Rozental 12 Aug '04

12 Aug '04

cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^ How should deal with this one? Any pointers? Gennadiy.

7 21

Re:Re: [boost] Re: serialization and cwpro status
by Robert Ramey 12 Aug '04

12 Aug '04

Message: 6 Date: Wed, 11 Aug 2004 23:46:32 -0500 From: Rene Rivera <grafik.list(a)redshift-software.com> Subject: To: Message-ID: <411AF628.80605(a)redshift-software.com> Content-Type: text/plain; charset=us-ascii; format=flowed Robert Ramey wrote: >> Actually I'm not doing the testing. I'm just relying >> on the table of test results which refers to compiler "CW" So I don't >>really >> know what version it is. >It's 9.2, or possibly 9.3. Stefan should really label the version. >Stefan: if you tell me which version you are running I can add a toolset >into CVS for it. Hmmm so the current set of facts is: Ramey:CWPro 9.2 in debug mode - fails export tests Rivera:CWPro 8.3 in release mode - fails export tests Stephan:CWPro 9.2?3 in ? mode - passes export tests. Its not clear to me how to address this. I would love to know what I'm doing differently than Stephan is. We're using the same tool set - cwpro9 or are we? Shouldn't the heading on the results table correspond to the toolset name? I'm using the toolset labeled cwpro9 - is this the correct one to use? Robert Ramey

3 2