- Boost - lists.boost.org

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

License
by Andrei Alexandrescu (See Website for Email) 12 Aug '04

12 Aug '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. (Not sure what those contributions are, but I got that email.) Way to go boost! Andrei

1 0

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

12 Aug '04

David Abrahams wrote: >Are you really testing CW 7.x? Hmm - I thought I was. 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. CWPro9 fails export and wide char tests on my machine when built for debug and CWPro8 fails tests on Rene's machine and he builds for release. So I just assumed the CW referred to some previous version. Since it was passing I never had to find out what it really was. >If you really count on the result of is_convertible being true when >it should be, then no, you don't have enough tests. >FWIW, I dropped CW 7.x support in Boost.Python and the iterators >library when CW 9 came out and have not received a single complaint. >I think VC6 is arguably the only 2-version-old compiler that might >warrant continued support. I never set out to make CW pass. It just did. I have spent time with CWPro as Rene expressed an interest and has been willing to help. The same goes for Borland where Pavel Vozenilek invested most of the effort. I wouldn't have done either of these were it not for this. I should say they did take a lot more effort than I originally anticipated - but then that applies to just about everything I do. Generally, I would agree that it makes no sense to spend effort to accommodate a compiler for which an upgrade is available. I wonder if having them in our test matrix creates a subtle pressure on developers to do the otherwise un-necessary work. It sort of plays on the obsessive aspect of the typical software developer personality. Robert Ramey

3 3