July 2004 - Boost - lists.boost.org

[preprocessor] Digital Mars port
by Daniel James 03 Aug '04

03 Aug '04

I've ported the preprocessor library to the Digital Mars preprocessor. The patch is at: http://myweb.tiscali.co.uk/calamity/patches/preprocessor-1.patch.gz With it, the only test which doesn't pass is the BOOST_PP_LINE test in debug.cpp, because the preprocessor has problems with macro expansion in #line statements. Would it be possible to add this to CVS after the release? Unless I've made a mistake, it won't interfere with any other preprocessors. The patch works around two bugs in the preprocessor. First, in a statement like this: #define FOO(pred, x) BAR(pred(x)) pred(x) won't get expanded. There are several ways to work around this, the one I've mostly used is to write: #define FOO(pred, x) BAR(pred##(x)) You can also use: #define CALL(pred, x) pred(x) #define FOO(pred, x) BAR(CALL(pred, x)) And, with the patch: #define FOO(pred, x) BAR(BOOST_PP_EXPAND(pred(x))) But, I think those two could cause problems with recursion. The other bug is with the preprocessors handling of whitespace. In the following example, neither concatenations work, both give '1 1' instead of '11'. #define EMPTY #define TRAILING_WHITESPACE(x) x EMPTY #define LEADING_WHITESPACE(x) EMPTY x BOOST_PP_CAT(TRAILING_WHITESPACE(1), 1) BOOST_PP_CAT(1, LEADING_WHITESPACE(1)) This causes subtle bugs with macros like this: #define BOOST_PP_LESS(x, y) BOOST_PP_IIF( \ BOOST_PP_NOT_EQUAL(x, y), \ BOOST_PP_LESS_EQUAL, 0 BOOST_PP_TUPLE_EAT_2)(x, y) This leaves a white space after the 0 when x and y are equal which prevents concatenation. This is mainly a problem with BOOST_PP_WHILE, BOOST_PP_FOLD_LEFT etc. It is possible to remove the whitespace by concatenating it to a macro which expands to nothing, but that is only possible when you know that there is definitely going to be whitespace. thanks, Daniel

3 6

Re:Re: [thread] barrier.cpp don't compile with msvc60 & stlport]
by Robert Ramey 02 Aug '04

02 Aug '04

>cool - i use the same configuration! So every has to work ;-)) >Why does it compiles on meta-comm and not on my machine? I tried it on >two differend machines. (but both with the same stlport) >So what's different? >I use the ms-iostream - what kind of iostreams is the regressiontest using? I use msvc + stlport 4.5.3 compiled with streams and it builds the serialization library on my machine w/o problems. The daily tests show what seems to be a similar configuration which fails to build with a compile error in spirit. Sooo one or more of the following is true a) something is different - its not clear what b) spirit 1.6 - needs some sort of tweak - I'm not sure this will ever happen. c) Its really annoying to see a column of all failures knowing that the issue is fixable but not by me. Robert Ramey

3 2

Boost-wide reports: Time to join in!
by Aleksey Gurtovoy 02 Aug '04

02 Aug '04

Now that we have Boost-wide reports up and running [1], I'd like to encourage all regression runners who's results are not represented there yet take a tiny bit of time to join in. The setup procedure is documented in http://tinyurl.com/4pnfd. It's very short and painless, too! It's crucial that we have an objective picture of the codebase when/before we release, and Boost-wide reports is the only instrument that is able to provide us with it. So please, join in! [1] http://www.boost.org/regression-logs/developer -- Aleksey Gurtovoy MetaCommunications Engineering

11 28

serialization - test/compiler status
by Robert Ramey 02 Aug '04

02 Aug '04

I've been working to make changes in the serialization system to support more platforms and pass more tests. I'm approaching the end of what I can do. The following comments reflect the state of the library as I recently uploaded and so may not be reflected by the current test tables. Windows platforms from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Metroworks CodeWarrior 9.2. - all test failures are related to one of the following three pending issues: a) slist test doesn't compile. The error is related to the internals of the slist implementation which I've been unable to decipher. b) link errors/warnings of replicated symbols. A number of tests - all those that use export and perhaps others generate duplicate symbol warnings for i/o streams. The generated executables also fail with unexpected messages. I suspect an issue with the compiler configuration files cwpro9.hpp for this platform. c) tests using non-intrusive serialization fail to find overload for serialization functions. (Commeau also has this problem). I suspect a compiler bug. So far I've been unable to resolve these issues and would be very appreciative if someone who has and interest and experience with this compiler would like to investigate this issues. MSVC-STLPORT a) In some environments - has a problem compiling spirit 1.6.1. I believe this has to be resolved by tweaking spirit. Borland Passes most tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. MSVC 6.0/7.0 Pass mosts tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. These are documented in the manual. VC 7.1 Passing 100 % VC 8.0 Small problem with compile error in library build - I'm hoping that this will build and pass 100 % Gcc 3.x Passing 100 %. Tests on platforms which don't support wide char i/o (e.g. cygwin and mingw). show failure for the related tests This is a feature of the build/bjam system and are not to be considered failures. Intel 7.1 This fails when export is used with invalid dynamic cast. This is unresolvable by me as I don't have this compiler on my system. Anyone with and interest in this compiler is invited to jump in. Intel 8.0 Passing 100 % MACOS - Darwin from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Previous test results show failure with wide-char i/o. I believe I have addressed this and hoped that next results will show 100 %. Current test results suggest an issue outside my influence. The program links with messages which suggest some sort of issue related to the test_exec_monitor. I would be very appreciative if anyone else want's to take a look at this. Linux - from http://boost.sourceforge.net/regression-logs/cs-Linux/developer/serializatio n.html Gcc 3.2.3, 3.3.2, 3.3.3 Pass 100% Gcc 2.95 This system doesn't support new style streams. This might be made to work but I can't justify the effort. Gcc 2.95 - stlport This probably could be made to work without tooo much problem - but as before its hard to justify the effort given the availability of a free upgrade to gcc 3.3+. As in the case of all the stlport tests, its not clear whether or not the version of stlport is built with streams and in some case which version is being used. GCC 3.4.1 This always passed 100 % - I made and corrected an obscure error while working on other platforms. I'm hoping for 100% next time Intel 7.1 Same as above for gcc 3.4.1 Intel 8.0 Hmmmm this passes 100% in windows and I believe has passed before. This situation is much confused by the policy of frequent releases of compiler updates. We label all of these intel 8.0 even though they are not the same. This os/compiler combination exhibits problems with the array test and export. I see it as unresolvable by me. Interested parties are invited to jump in. Other platforms - from http://boost.sourceforge.net/regression-logs/ AIX This is hung up in the compilation of large mpl expression. Working around this would require access to such a compiler platform which I don't have. This will only get resolved if someone has sufficient interest/necessity to invest the required effort. HP-UX/PARISC - aCC These compiles fail to build the library. The error messages suggest that these compilers don't support enough C++ template syntax to be useable without undertaking heroic efforts and having direct access to the compiler/platrom. IRIX64 This libraries aren't being tested frequently enough to be useful for resolving problems of library implementation. I am marking these platforms unusable for the serialization library. Robert Ramey

2 1

VC 7.1 level 4 warnings (thread, lexical_cast)
by Johan Nilsson 01 Aug '04

01 Aug '04

[Should this really go to boost.users instead?] Hi, loads of warnings are generated when compiling code with VC 7.1 using Boost.Thread and lexical_cast with the warning level set to 4. I use Boost 1.31.0, but at a quick look at the latest versions they seem to have the same problem * Boost.Thread generates numerous C4275 and C4251 (both related to dll-interface), examples: --- ../../../deps\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' d:\VS.NET_2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' ../../../deps\boost\boost\thread\thread.hpp(78) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' --- * lexical_cast generates C4511, C4512 + C4127, examples: -- ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4512: 'boost::detail::lexical_stream<Target,Source>' : assignment operator could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4511: 'boost::detail::lexical_stream<Target,Source>' : copy constructor could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(133) : warning C4127: conditional expression is constant --- Would it be possible to get rid of those using pragmas in the header files? I wouldn't mind disabling C4511/4512 globally but the other ones I'd prefer not to. Selectively disabling the other warnings when including the files is practically impossible. I guess this has been discussed before, but why not compile with warning level 4 + warnings as errors by default? // Johan

3 3

lexical cast and locale
by Martin 01 Aug '04

01 Aug '04

This might be a stupid question but I couldn't find anything in the documentation about it. How do I control the locale used in lexical cast? More specificly I want to control the decimal separator.

2 2

Review Wizard - Status Report
by Tom Brinkman 01 Aug '04

01 Aug '04

I'm currently attempting to contact the authors of the eight remaining libraries to be reviewed. I will start the reviews immediately after the next release of boost is completed. If you are one of the eight authors, and I have not contacted you yet, please contact me directly, and tell me what your availability is. I will schedule the reviews in the months of August, September and October. Please tell me if you have a suggestion for a review manager for your library or if you have any questions about the review process. I will research them for you. Tom Brinkman Review Wizard reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

[algorithm/string] predicate failure for CW8
by Rene Rivera 31 Jul '04

31 Jul '04

It took some digging but I figured out what the problem with the failure on this test is for CW8. Basically CW8 is doing a copy construction on the use of static_cast for a reference when the type of the reference is itself a template typename. In all other cases it does the cast correctly. The work-around is to do the cast on the pointer type and dereference instead of the cast on the reference directly: =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/classification.hpp,v retrieving revision 1.4 diff -u -r1.4 classification.hpp --- classification.hpp 15 Jul 2004 21:48:25 -0000 1.4 +++ classification.hpp 29 Jul 2004 21:32:49 -0000 @@ -236,8 +236,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_andF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2) ); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2) ); } //! predicate 'or' composition predicate @@ -257,8 +257,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_orF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2)); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2)); } //! predicate negation operator @@ -273,7 +273,7 @@ inline detail::pred_notF<PredT> operator!( const predicate_facade<PredT>& Pred ) { - return detail::pred_notF<PredT>(static_cast<const PredT&>(Pred)); + return detail::pred_notF<PredT>(*static_cast<const PredT*>(&Pred)); } } // namespace algorithm =================================================================== Those changes make it work on CW8, and it still works on VC7.1 and MinGW. OK to commit?? -- I'll assume the answer is *yes* after a few hours ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 5

[serialization] use of iterator_facade, CW8 build fixed.
by Rene Rivera 31 Jul '04

31 Jul '04

In another painfully hunt to fix the problems with the seriazation lib issues in CW8... I tracked the problem down to another instance of: static_cast<const&>(x) where x is a template with template ctors. The problem was in iterator_facade, and not directly in the serialization lib which made it even harder to find :-( Anyway, I applied this change (figured since this is a known problem by now with an easy portable solution it would not be a problem)... =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/iterator_facade.hpp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iterator_facade.hpp 31 Jul 2004 18:10:00 -0000 1.26 +++ iterator_facade.hpp 31 Jul 2004 22:56:49 -0000 1.27 @@ -814,8 +814,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - static_cast<Derived1 const&>(lhs) \ - , static_cast<Derived2 const&>(rhs) \ + *static_cast<Derived1 const*>(&lhs) \ + , *static_cast<Derived2 const*>(&rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } =================================================================== After that the serialization lib builds, and tests run. Of course not all tests pass ;-) VC7.1 and Mingw behave as before also. PS. There was one other minor change to the libs/serialization/test/Jamfile to account for locale requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[Graph] New branch for graph library development (graph_devel)
by Doug Gregor 31 Jul '04

31 Jul '04

I've started a new branch for further development of the graph library, graph_devel. At the moment it contains only a small amount of work (Brandes' algorithm for betweenness centrality and the Kamada-Kawai spring layout for undirected graphs), but it will be used for more aggressive development as well. Algorithms will be merged to mainline so long as we _aren't_ planning a release in the next few days, but any infrastructure changes will remain on the branch for a bit longer. I've only branched the boost/graph and libs/graph directories. Doug

1 0