September 2005 - Boost - lists.preview.boost.org

[any] documentation is not up-to-date
by Alexander Nasonov 22 Sep '05

22 Sep '05

The any_cast documentation ( http://www.boost.org/doc/html/any_cast.html ) doesn't reflect latest changes in any.hpp. Now it's legal to get direct access to any's content using any_cast<ValueType&> syntax. New overload should be added: template<typename T> T any_cast(any & operand); All occurrences of ValueType in the overload template<typename ValueType> ValueType any_cast(const any & operand); should be replaced with T (where T is either ValueType or a reference to ValueType). In section "Returns" replace If passed a value or reference, it returns a copy of the value content if successful. with If passed a value or reference, it returns held value if successful. If T is ValueType, it returns a copy of the held value, otherwise, if T is a (possibly const qualified) reference to ValueType, it returns a reference to the held value. In section "Throws" replace "the overload taking an any value" with "overloads taking an any value" Section "Rationale" should be removed. -- Alexander Nasonov

1 1

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

> Hi all, > > I've recently downloaded boost to run on an IBM mainfram z/OS system > (a port of vacpp). I'm trying to compile multi_index\example\hashed. > cpp (which I called stuff.cpp) > and I'm getting the following errors. I'm a relative newbie with C++ > so I'm completely bamboozled by the compiler errors. Help with this > will be greatly appreciated as I am currently in the process of > trying to convince management to switch to C++ from C, and boost is > one of my big hitting selling points. > > "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: > CCN5431 (S) The declarator cannot be qualified with the enclosing > namespace "mpl_". > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: > CCN5431 (S) The declarator cannot be qualified with the enclosing > namespace "mpl_". > "/FTS1/tmp/doc/boost/mpl/has_key.hpp", line 32.20: CCN5408 (S) The > base class "apply<boost::mpl::set0<mpl_::na>, > boost::multi_index::detail::duplicate_tag_mark>" is declared but not > defined. > "/FTS1/tmp/doc/boost/multi_index/detail/no_duplicate_tags.hpp", line > 60.23: CCN5700 (I) The previous message was produced while > processing "struct boost::mpl::has_key<boost::mpl::set0<mpl_::na>, > boost::multi_index::detail::duplicate_tag_mark>". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 200. > 41: CCN5016 (S) The expression must be an integral constant > expression. > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 200. > 33: CCN5700 (I) The previous message was produced while > processing "boost::detail::is_base_and_derived_impl<boost:: > multi_index::detail::tag_marker,boost::multi_index::tag<mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na> >::value". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 188. > 8: CCN5700 (I) The previous message was produced while > processing "struct boost::detail::is_base_and_derived_impl<boost:: > multi_index::detail::tag_marker,boost::multi_index::tag<mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na> >". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 209. > 7: CCN6269 (S) The template argument for the non-type template > parameter of type "bool" must be an integral constant expression. > "/FTS1/tmp/doc/boost/multi_index/tag.hpp", line 61.37: CCN5700 (I) > The previous message was produced while processing "struct > boost::is_base_and_derived<boost::multi_index::detail::tag_marker, > boost::multi_index::tag<mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na> >". I think this problem is due to a difference in the version number in the __IBMCPP__ macro. Although the z/OS compiler is ported from VACPP the __IBMCPP__ macro has a different version number. >From the z/OS 1.6 programming reference: __IBMCPP__ C ++ Only. This macro indicates the version number of the z/OS C++ compiler. The format of the version number that is provided by the macro is integer PVRRM, where : P Represents the compiler product v 0 for C/370 v 1 for AD/Cycle C/370 and C/C++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for z/OS C/C++ v 4 for z/OS C/C++ Release 2 and laterV Represents the version number RR Represents the release number M Represents the modification numberIn z/OS C/C++ Version 1 Release 6, the value of the macro is 41060. I'm probably the first person to try to use boost on the big iron. The macro __MVS__ is set to 1 if running on z/OS. I'm happy to assist in any way possible in porting boost to z/OS.

1 0

[Review] xpressive review period extended
by Thomas Witt 22 Sep '05

22 Sep '05

Hi, after being declared half-closed (my bad) the review period for Eric Niebler's xpressive library has now been extended until Sunday Sep 25. The original announcement can be found here: http://tinyurl.com/dk2yz Some additional information is in this posting: http://tinyurl.com/dphjc Thomas Review Manager xpressive

1 0

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <dgmfeo$q1v$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > I think generally this is a good idea, but it has a small problem. I > would expect that BOOST_ASSUME should turn into __assume when compiled > in "release" mode of MSVC. As of above proposed solution this is not > the case - user additionally needs to define BOOST_DISABLE_ASSERTS to > get __assume. So when NDEBUG is defined and BOOST_DISABLE_ASSERTS is > not (I think this is 99% of cases, because few people actually use > BOOST_DISABLE_ASSERTS), BOOST_ASSUME will expand to BOOST_ASSERT and > the whole thing will be useless. I did not use NDEBUG because BOOST_ASSERT doesn't, and I didn't want to revisit that decision. I imagine the policy is to use fine-grained flags and then add: #ifdef NDEBUG #define BOOST_DISABLE_ASSERTS #endif in a user-editable header somewhere. Arguably there should be a BOOST_DISABLE_ASSUMES, too, but for now I'll use BOOST_DISABLE_ASSERTS. > # define BOOST_ASSUME(e) { BOOST_ASSERT(e); if (e); else __assume(0); } That evaluates e twice, and if e is false it is not clear whether the assert will actually do anything because it could be optimised away. I think: # define BOOST_ASSUME(e) __assume(e) is simpler and better. > There's also a question what should BOOST_ENABLE_ASSERT_HANDLER do with > BOOST_ASSUME? Should it invoke the handler if condition is false? Only if BOOST_DISABLE_ASSERTS is not defined. So the full code would be: #include <boost/config.hpp> #if defined(BOOST_MSVC) && defined(BOOST_DISABLE_ASSERTS) # define BOOST_ASSUME(e) __assume(e) #else # define BOOST_ASSUME(e) BOOST_ASSERT(e) #endif -- Dave Harris, Nottingham, UK.

4 3

Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

Hi all, I've recently= downloaded boost to run on an IBM mainfram z/OS system (a port of vacpp). = I'm trying to compile multi_index\example\hashed.cpp (which I called stuf= f.cpp) and I'm getting the following errors. I'm a relative newbie with= C++ so I'm completely bamboozled by the compiler errors. Help with this wi= ll be greatly appreciated as I am currently in the process of trying to con= vince management to switch to C++ from C, and boost is one of my big hittin= g selling points. "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrappe= r.hpp", line 85.30: CCN5431 (S) The declarator cannot be qualified with the= enclosing namespace "mpl_". = ; &n= bsp; ; &n= bsp; = ; &n= bsp; ; &n= bsp; = ; "'DOC.USER.CPP(STUFF)'", line 47.= 60: CCN6281 (W) "offsetof" cannot be applied to "struct word_counter_en= try". It is not a POD (plain old data) type. &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; &= nbsp; &nbs= p; &= nbsp; "'DOC.USER.CPP(STUFF)'", line= 47.60: CCN6281 (W) "offsetof" cannot be applied to "struct word_counter= _entry". It is not a POD (plain old data) type.&n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; &n= bsp; "'DOC.USER.CPP(STUFF)'",= line 47.60: CCN6281 (W) "offsetof" cannot be applied to "struct word_cou= nter_entry". It is not a POD (plain old data) typ= e. &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; "'DOC.USER.CPP(STUFF= )'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "struct word= _counter_entry". It is not a POD (plain old dat= a) type. &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; "'DOC.USER.CPP= (STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "struct = word_counter_entry". It is not a POD (plain old= data) type. &nb= sp; &nb= sp; = &nb= sp; &nb= sp; "'DOC.USER= .CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "str= uct word_counter_entry". It is not a POD (plain= old data) type. = ; &n= bsp; ; &n= bsp; = ; &n= bsp; ; &n= bsp; "/FTS1= /tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: CCN5431 (S) = The declarator cannot be qualified with the enclosing namespace "mpl_= ". &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; &= nbsp; "/FTS1/tmp/doc/boost/mpl/has_key.hpp", line 32.20: CCN5408 (S) = The base class "apply<boost::mpl::set0<mpl_::na>, &nb= sp; boost::multi_index::detail::duplicate_tag_mark>" is d eclared but not defined. &nb= sp; = &nb sp; = "/FTS1/tmp/doc/boost/multi_index/det ail/no_duplicate_tags.hpp", line 60.23: CCN5700 (I) The previous messag= e was produced while processing "struct boost::mpl::has_key&l t;boost::mpl::set0<mpl_::na>,boost::multi_index::detail::duplicat e_tag_mark>". &= nbsp; "/FTS1/tmp/doc/boost/type_traits/= is_base_and_derived.hpp", line 200.41: CCN5016 (S) The expression mus= t be an integral constant expression. &n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; &n= bsp; = ; "/FTS1/tmp/doc/boost/type_traits/is_base_and_deri= ved.hpp", line 200.33: CCN5700 (I) The previous message was produced while& nbsp; processing "boost::detail:: is_base_and_derived_impl<boost::multi_index::detail::tag_m ar= ker,boost::multi_index::tag<mpl_::na, &= nbsp; mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na ,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl _::= na,mpl_::na, mpl_::na,mpl_::na,mpl_::na= ,mpl_::na,mpl_::na> >::value". = ; &n= bsp; = ; &n bsp; = ; &n= bsp; "/FTS1/tmp/doc/boost/type_traits/i= s_base_and_derived.hpp", line 188.8: CCN5700 (I) The previous message= was produced while p= rocessing "struct boost::detail::is_base_and_derived_impl<boost: :multi_index::detail::tag_marker,boost::multi_index::tag<mpl_: :n= a, mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mp l_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_ ::na,= mpl_::na, mpl_::na,mpl_::na,mpl_::na,mp= l_::na,mpl_::na> >". &nb= sp; = &nb= sp; &nb= sp; "/FT= S1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 209.7: = CCN6269 (S) The template argument for the non-type template parameter= of type "bool" must be an integral constant expression. &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; "/FTS1/tmp/doc/boost/multi_index/tag.hpp", line 61.37: CCN5700 (I) The p= revious message was produced while processing "struct &nbs p; boost::is_base_and_derived<boost::multi_index::de tail::tag_marker,boost::multi_index::tag<mpl_::na,mpl_::na,mpl = _::na,mpl_::na, mpl_::na,mpl_::na,mpl _::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_: :na,m= pl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, &nb sp; mpl_::na,mpl_::na> >". = ; &n= bsp;

2 2

Boost publicity - article authors?
by Matthew Vogt 21 Sep '05

21 Sep '05

If anyone is interested in writing a brief article publicising boost, the Linux Weekly News (which covers open-source software as much as Linux) would be interested in receiving a submission. If anybody (maybe Björn Karlsson?) has suitable copy ready, the contact details are forwarded below: Matt lwn(a)lwn.net (LWN.net) Sent by: lwn(a)lwn.net 21/09/2005 06:36 AM To: mvogt(a)jupiters.com.au cc: Subject: Re: LWN Development page should cover boost releases Greetings Matt, thanks for the info on Boost. We're always looking for guest authors, if you would be interested in writing up a summary of the Boost project, that would make a good LWN development page lead article. We typically pay around $75 for such articles. We have an author guide here: http://lwn.net/op/AuthorGuide.lwn -Forrest Cook LWN.net - your Linux information source lwn(a)lwn.net -- Matthew Vogt mattvogt(a)warpmail.net -- http://www.fastmail.fm - mmm... Fastmail...

1 0

[wave] build hangs on GNU/Linux/amd64
by Russell Kliese 21 Sep '05

21 Sep '05

I've been trying to build boost on an amd64 machine under Debian Linux but it hangs trying to compile part of the wave library. Is it possible to skip building the wave library as a temporary work around (I am not familiar with jam)? I'm using the deb source package (from 1.33.0) from the unstable Debian distribution: http://packages.debian.org/unstable/source/boost I am building on the stable distribution (i.e. trying to create a back port because of the broken timed mutexes in 1.32). The build gets to: "g++" -c -Wall -ftemplate-depth-255 -D_REENTRANT -g -O0 -fno-inline -pthread -I"bin/boost/libs/wave/build" -I"/home/users/russell/cvs/debPackages/boost/boost_1_33_0" -I "/home/users/russell/cvs/debPackages/boost/boost_1_33_0" -o "bin/boost/libs/wave/build/libboost_wave.a/gcc/debug/threading-multi/instantiate_cpp_literalgrs.o" "/home/users/russell/cvs/debPackages/boost/boost_1_33_0/libs/wave/build/../src/instantiate_cpp_literalgrs.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "bin/boost/libs/wave/build/libboost_wave.a/gcc/debug/threading-multi/instantiate_cpp_literalgrs.o" at which point it hangs (top shows cc1plus using 99.9% CPU). Please let me know if I can supply more info to help debug this problem. Russell Kliese

5 4

[bigint] operator< problem
by Janusz Piwowarski 21 Sep '05

21 Sep '05

Hello I have the problem with boost::bigint (from boost-sandbox). There's minimal example: #include "boost/bigint.hpp" int main (void) { boost::bigint b = 1; while ( b < 1001 ) b *= 10; } Loop never ends; is it known issue? Compiler g++ 3.4.2 (mingw) -- Regards, Janusz

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 21 Sep '05

21 Sep '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Rob Stewart > Sent: Friday, September 16, 2005 2:06 PM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] Checked Integral Class > > > From: "Matt Doyle" <mdoyle(a)a-m-c.com> > > > From: "michael toksvig" <michaeltoksvig(a)yahoo.com> > > > > > add two numbers in the 1-10 range, and you invariably end=20 > > > up with a number=20 > > > > in the 2-20 range > > > > Yep. However, when considering constrained ranges, I find it > > > surprising that the result would be *permitted* to exceed the > > > constraints of the inputs. > > > > IOW, I'd have expect the result to be constrained to be 2-10. > > > Yes, that means that combinations exist that violate that > > > constraint, but at least it wouldn't surprise me. > > > > > YES, that's exactly the point I was trying to make earlier > - you just = > > did a much better job of explaining it :) > > Thanks, if in fact I was addressing your concern. > > > IMO, the constraints and/or policies set forth when the > type was defined = > > must apply for the lifetime of the type. > > To be certain we're talking about the same thing, Michael and I > have been discussing the result of a computation. Built-in types > regularly undergo promotions when participating in such > expressions, so the question is whether something similar should > happen for a checked integral class and what form it should take. > > Michael was positing that the result type should account for the > full range of values possible from the computation. I argued > against that. > > I should also point out that built-in types don't behave that > way; they can overflow silently, but they don't magically gain > range. (The analogy isn't strong, but has some bearing, I > think.) I think we are talking about the same thing but from different angles, consider this simple case; typedef constrained_value<0, 10, policy> MyCV; MyCV a = 6; MyCv b = 8; MyCv c = a + b; // Should fail If the user wants "c" to be able to hold the result of "a + b" he should define a new type that would accommodate it. We are on the same page aren't we? > > -- > > Rob Stewart stewart(a)sig.com > Software Engineer http://www.sig.com > Susquehanna International Group, LLP using std::disclaimer; > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by Fortigate {X3BTB534}

4 4

[Test] 1.33 compile error for Win9x/ME targets
by Christopher Kohlhoff 21 Sep '05

21 Sep '05

I'm trying to use the Boost Test framework for unit testing in asio but it doesn't work for Win9x/ME targets without a minor fix. The problem is due to boost/test/impl/execution_monitor.ipp only checking for _WIN32_WINNT, when the #define for Win9x/ME is _WIN32_WINDOWS. I had to make the following change to get it to work: @@ -55,7 +55,7 @@ # define BOOST_MS_STRUCTURED_EXCEPTION_HANDLING -# ifndef _WIN32_WINNT +# if !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS) # ifdef _WINBASE_ # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h # else I also encountered this as an error, rather than a warning as intended, because #warning is not supported by MSVC. It should probably use #pragma message("...") instead. Cheers, Chris

2 1