December 2005 - Boost - lists.boost.org

on boost version numbers
by Stefan Seefeld 08 Dec '05

08 Dec '05

Hi there, now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously. I see two issues with the current release numbering scheme: 1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ? 2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other. Comments ? Thanks, Stefan

12 20

Re: [boost] [wave) experiences
by Hartmut Kaiser 08 Dec '05

08 Dec '05

Vambola Kotkas wrote: > Wave Driver C++ preprocessor seems quite useful tool to see what > happens with most macros. Unfortunatelly it needs some debugging > before it can be used to preprocess real code. For example it refuses > (unneccessarily) to process sometimes. > > Silly example 1: > #if __LINE__ == 11112223334 > #pragma message( "Huh!" ) > #endif > Result: > test.cpp(1): error: ill formed integer literal or integer constant > too > large: 11112223334. > > None of the available wave flags did seemingly help. Not that i need > huge integers, however boost sometimes does have way bigger ones so it > must be legal? MS Visual C++ 7.1 processes constants like > 18446744073709551615 without any noise. > See ... 1.33.0 boost/cstdint.hpp line(263): > # if ULONG_MAX == 18446744073709551615 // 2**64 - 1 It's not legal for 32 bit systems. Either flag the 11112223334 with the LL suffix (and the --long_long command line option) or you are out of luck with Wave. At least as long the code is not hidden inside a non-evaluated #if/#endif block. I've fixed Wave after 1.33.0 to accept large numbers in non-evaluated #if expressions, just to allow to compile Boost. > Silly example 2: > #define SHOW2(x) #x > #define SHOW(x) SHOW2(Number is:##x) > #pragma message( SHOW(__LINE__)) > Result: > test.cpp(3): error: pasting the following two tokens does not give a > valid preprocessing token: ":" and "__LINE__" Concatenating two unrelated tokens isn't allowed by the C++ Standard. If you really need this just provide the --variadics command line option, which will enable certain C99 features in C++ (variadics, token concatination of unrelated tokens etc.) > Maybe its buggy and MS made its preprocessor too lousy there ... just > for reference Visual C++ 7.1 preprocess result: Yes, the MSVC preprocessor is lousy. > Side question: How to force wave to use full paths in #line > directives? > Larger projects may contain similarily named files and people > usually have multiple versions of their own software, nothing > to talk of libraries and SDK-s. Wave does use full paths in #line directives as long as the corresponding files are not in the directory of the main file. > Silly thing 2 can be > transformed into Working thing 2: > #define SHOW2(x) #x > #define SHOW(x) SHOW2(x) > #pragma message("Number is:" SHOW(__LINE__)) Wave produces > same output as VC++ 7.1 then: > #line 3 "test.cpp" > #pragma message("Number is:" "3") What's silly here? > Finally ... fair test for preprocessor is if it preprocesses > its own code. > That makes wave to crash with "unexpected exception caught." > Various sets of -P and -D options make it to crash in various > places. I did not manage to find a good set of options so it > does not crash. How to compile debug version of wave with > vc7.1? bjam "-sBUILD=<debug>" ... ? > Without debugging it is hard to further track down > what is going on there. I tried the wave in boost 1.33.0. Frankly speaking, I haven't done this for a long time. So I tried today and got several errors/warnings reported by Wave (which I have to investigate further), but I didn't get any segfault! I'll report on this list with my findings. Could you please elaborate on which compiler you used to generate Wave, which command line options did you use? Regards Hartmut

9 16

File Vault strangeness
by Eric Niebler 08 Dec '05

08 Dec '05

The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 13

Re: [boost] [wave) experiences
by Martin Bonner 07 Dec '05

07 Dec '05

----Original Message---- From: Paul Mensonides [mailto:pmenso57@comcast.net] Sent: 07 December 2005 09:10 To: boost(a)lists.boost.org Subject: Re: [boost] [wave) experiences > Supporting [extended length integers] is not a good idea. > IMO, it is just the beginning of non-standard extensions. > For the purpose of cross-compiling, I don't have a problem > with an option to specify the width. But what about cross compiling from a 32-bit platform for a 64-bit target? (which strikes me as a perfectly reasonable thing to do today). > IMHO, it is in the community's ultimate best interest for > preprocessors and compilers to be as *un-permissive* as possible. ... but in general I agree with this idea. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 5

Re: [boost] BOOST_ENUM proposal
by Job Mulder 07 Dec '05

07 Dec '05

It looks nice, but does it also work with other structures than strings? i.e. BOOST_ENUM(id, (ab_device)("device for your abs", /*activation code*/ 13, /*typical % of time used*/ 0.0) (pc_device)("personal computer", /*activation code*/ 42, /*typical % of time used*/ 100.0) ) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frank Laub Sent: Wednesday, December 07, 2005 12:47 To: boost(a)lists.boost.org Subject: [boost] BOOST_ENUM proposal Hello fellow boosters, I've recently come up with a way to use the boost preprocesor to generate a 'better' enum type. The following is an example of some typical usage. Is anyone else interested in this sort of thing? I'm hoping to get suggestions for how to make it more 'boost-like' in both its implementation and its usage. Is this very readable? Is there a place I can upload the code for people to peruse? #include <iostream> #include <boost/enum.hpp> #include <boost/foreach.hpp> #define foreach BOOST_FOREACH BOOST_ENUM(Level, (Abort)("unrecoverable problem") (Error)("recoverable problem") (Alert)("unexpected behavior") (Info)("expected behavior") (Trace)("normal flow of execution") (Debug)("detailed object state listings") ) int main() { foreach(const string& name, Level::names) { cout << name << endl; } cout << "1: " << Level::names[1] << endl; cout << "toString(Abort): " << Level::toString(Level::Abort) << endl; cout << "getValue(Abort): " << Level::getValue(Level::Abort) << endl; Level::type value = Level::Invalid; bool ret = Level::fromString("Abort", value); cout << "fromString(\"Abort\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("Debug", value); cout << "fromString(\"Debug\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("not in enum", value); cout << "fromString(\"not in enum\"): " << ret << ", " << value << endl; return 0; } With the program output being: Abort Error Alert Info Trace Debug Invalid 1: Error toString(Abort): Abort getValue(Abort): unrecoverable problem fromString("Abort"): 1, 0 fromString("Debug"): 1, 5 fromString("not in enum"): 0, 6 -Frank _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Boost & Threading
by Jens Hibbeler 07 Dec '05

07 Dec '05

Hello Perhaps anyone can give me a hint, how I get ahead or where my error lies? Which I did: 0) Executed Borland builder Patch No. 4 1) Downloaded Spirit 1.6.3, set environment variable SPIRIT_ROOT on the Spirit listing 2) Set environment variable BCCROOT on c:\programme\borland\cbuilder6 3) Dowloaded the Boost LIBRARY (tried one after the other from 1_32-1_33 beta, all versions), and set the BOOST_ROOT environment variable to the listing in which I boost unpacked. 4) At the Boost tools\build\listing\build.bat executed (compiles correctly for Boland) 5) Executed tools\build\jam_src\bin.ntx86\bjam.exe "- sTOOLS=borland" install (compiled also, but with few warnings) 6) At the listing, in which I unpacked Boost, I started the libs\thread\example file once.cpp 7) I made a Porjekt to compile the file 8) I set atthe project settings the include path on C:\Boost\include\boost-1_32 9) I set atthe project attitudes the LIBRARY path on C:\Boost\lib \ 10) The program compiled and linked 11) When starting the project it crhases immediately and started the monitor, which indicates the storage addresses to me. Where does my error lie? Do I have to adjust something special in the Porjekt still? Many greetings from Hamburg, Jens Hibbeler

1 1

Re: [boost] [smart_ptr] BOOST_SP_USE_QUICK_ALLOCATOR andmulti-threading broken on gcc-4.0.2
by Peter Dimov 07 Dec '05

07 Dec '05

Juergen Hunold wrote: > Hi Again ! > > I've taken another attempt to fix this and found a solution. > > On Wednesday 07 December 2005 20:37, Juergen Hunold wrote: >> Question: Is this a bug or a feature ? > > It's a bug. > >> Question: If this is a bug, whats the fix ? > > Please find the fix attached. Applied, thank you. I have no idea how MSVC 7.1 (that I used to test the modification) was able to eat the original horribly broken code, but it managed to.

1 0

[smart_ptr] BOOST_SP_USE_QUICK_ALLOCATOR and multi-threading broken on gcc-4.0.2
by Juergen Hunold 07 Dec '05

07 Dec '05

Hi ! I'm using smart_ptr (read shared_ptr) and BOOST_SP_USE_QUICK_ALLOCATOR to speed my program up. My programs broke when "boost/detail/quick_allocator.hpp" Revision 1.9 was commited to HEAD. I've been able to reproduce this behaviour with the smart_ptr testcase and Boost.Build V2 which the attached path "smart_ptr.diff" to libs/smart_ptr/test/Jamfile.v2 I'm cross-posting this to boost-build because the simple command bjam --v2 threading=multi/define=BOOST_SP_USE_QUICK_ALLOCATOR did not work. See build-error.txt for full backtrace. The gcc error is ../../../boost/detail/quick_allocator.hpp:176: error: conflicting declaration 'boost::detail::lightweight_mutex boost::detail::allocator_impl<size, align_>::mutex_init' ../../../boost/detail/quick_allocator.hpp:81: error: 'boost::detail::allocator_impl<size, align_>::mutex_init' has a previous declaration as 'boost::detail::lightweight_mutex * boost::detail::allocator_impl<size, align_>::mutex_init' Please find the error message "error.txt" attached. System: Debian Unstable/testing gcc -v : gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) I've tried the obvious fix by adding the missing asterisk (*) gcc complains about but then gcc bails out with ../../../boost/detail/quick_allocator.hpp:176: error: expected primary-expression before 'allocator_impl' (see fix-error.txt) I've checked my copy of "C++ Templates" for static template member (page 97/98) but have no other clue and no copy of the holy standard... Question: Is this a bug or a feature ? Question: Is there any way to add tests for BOOST_SP_USE_QUICK_ALLOCATOR and treading=multi to Boost.Test (V2) in order to catch such a regression. Question: Can someone reproduce this ? Question: If this is a bug, whats the fix ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

1 0

[math] floating point classification - testing help wanted
by John Maddock 07 Dec '05

07 Dec '05

For a while now I've been meaning to clean up my floating-point classification code to provide a more reliable way of testing for Nan's and infinities. The new TR1 complex number code could really use this to improved it's reliability. I believe Robert Ramey was looking for this functionality for serialisation, and frankly it's hard to write any serious floating point code without it. So... attached is a first version of an fpclassify implementation for Boost (if there's interest). As long as this one works (not a given unfortunately) then it's obviously trivial to sit isnan, isinfinity etc on top of it. So.... I'm looking for testers to run the attached program on as many different platforms/compilers as possible, basically I want to see if there's any mileage in this or if I'm on to a looser with this code! Please build the test program with optimisations turned on: many compilers make non-IEEE arithmetic assumptions once you tell them to optimise the code. Tested so far: Win32: VC6: Can't detect signaling NaN's (_isnan is broken). VC7, 7.1, 8: OK Intel 7, 8, 9: OK provided you're not using the VC6 runtime. GCC cygwin: OK. Borland 5.6.4: So broken I don't know where to begin :-( HP-UX: gcc-3.4.2: OK. aCC: OK (native fpclassify broken for long doubles, but portable version works). Tru64: cxx : OK (but can't test infinities/NaN's as they're not supported? Suse Linux: gcc-3.3.3 : OK. Many thanks, John.

15 44

Re: [boost] [shared_ptr] constructor accepting auto_ptr
by Martin Bonner 07 Dec '05

07 Dec '05

----Original Message---- From: Yuval Ronen [mailto:ronen_yuval@yahoo.com] Sent: 07 December 2005 16:20 To: boost(a)lists.boost.org Subject: Re: [boost] [shared_ptr] constructor accepting auto_ptr > Peter Dimov wrote: >> The reference adds a strong exception safety guarantee. If the >> shared_ptr constructor fails, the source auto_ptr is left intact. >> Pass by value would have already zeroed out the source. >> >> If you want to achieve the equivalent of pass by value, you can use >> an explicit .release(). >> >> This warning would actually be an error on a stricter compiler. >> >> One happy day the compiler writers will bring us the rvalue >> reference, the constructor will take auto_ptr &&, and all will be >> well with the world. :-) > > Does that mean that on a stricter compiler, when passing a temporary > auto_ptr, I *have* to use the '.release()' way, and *can't* get the > strong exception guarantee? No. You can always create a named temporary, and bind the reference to that. > > Thanks a lot to both of you Peter and Howard for your help. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0