- Boost - lists.boost.org

Confused about threading
by Neal Becker 12 Aug '05

12 Aug '05

I started out by trying to figure out if shared_ptr always uses threading. A quick look at the jamfiles did not suggest that threading was disabled when building single. Then I tried this: nm --demangle libboost_regex-d.a | grep -i thread [ lots of threading symbols ] OK, so why is the single threaded version of a library full of threading references? Is this a problem? Oh, this is gcc/linux system

2 1

[thread] assertion error when exiting app
by Felipe Magno de Almeida 12 Aug '05

12 Aug '05

Hi, I'm having an assertion failed when trying to finish my application. I use Boost.Thread to create one thread and use serialization and spirit that I know use threads either. It wasnt happening when using an earlier boost cvs version... And for some reason I'm not being able to debug it, when trying to the app finishes when reaching the MSVC. I'm using MSVC 7.1 and the assertion is: File: boost-path\libs\thread\build\..\src\tss_hooks.cpp Line: 131 Expression: attached_thread_count == 0 This application uses different threads to create and destroy objects throughout its lifetime(probably even the static/singleton objects). It is an COM object and is accessed through "RPC", where the creation of the singletons takes place... If anybody has any clue to what it could be, I would really appreciate. I'm going to update my boost to the RC2 and see what happens. Thanks in advance, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

2 5

regression on aix
by Toon Knapen 12 Aug '05

12 Aug '05

This week we upgraded our VisualAge compiler from 6.0.0.8 to 6.0.0.13 (because of problems with the preprocessor) which is the latest PTF (which is ibm speak for 'service pack'). We will thus also use this updated version to run the regression tests during the weekend (which are reported here: http://tinyurl.com/bms8v) However we will have *many* regressions because of compilation problems in some headers that are (indirectly) used in many places. For instance one problem is the gcc_3_2_wknd struct in mpl/has_xxx.hpp (see attached compiler error report). I fiddled around a bit with it and I do not understand why the compiler reports gcc_3_2_wknd to be an incomplete class. I also noted that defining gcc_3_2_wknd outside of the trait struct works. But this solution is also problematic from the moment the BOOST_MPL_HAS_XX_TRAIT_NAMED_DEF is used twice in which case the gcc_3_2_wknd will be defined twice ;-( Any suggestions are welcome! warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). ...patience... ...found 1200 targets... ...updating 444 targets... MkDir1 ../../../bin.v2/libs/mpl MkDir1 ../../../bin.v2/libs/mpl/test MkDir1 ../../../bin.v2/libs/mpl/test/largest_int.test MkDir1 ../../../bin.v2/libs/mpl/test/largest_int.test/vacpp MkDir1 ../../../bin.v2/libs/mpl/test/largest_int.test/vacpp/debug vacpp.compile.c++ ../../../bin.v2/libs/mpl/test/largest_int.test/vacpp/debug/largest_int.o **passed** ../../../bin.v2/libs/mpl/test/largest_int.test/vacpp/debug/largest_int.test MkDir1 ../../../bin.v2/libs/mpl/test/msvc_is_class.test MkDir1 ../../../bin.v2/libs/mpl/test/msvc_is_class.test/vacpp MkDir1 ../../../bin.v2/libs/mpl/test/msvc_is_class.test/vacpp/debug vacpp.compile.c++ ../../../bin.v2/libs/mpl/test/msvc_is_class.test/vacpp/debug/msvc_is_class.o **passed** ../../../bin.v2/libs/mpl/test/msvc_is_class.test/vacpp/debug/msvc_is_class.test MkDir1 ../../../bin.v2/libs/mpl/test/template_arity.test MkDir1 ../../../bin.v2/libs/mpl/test/template_arity.test/vacpp MkDir1 ../../../bin.v2/libs/mpl/test/template_arity.test/vacpp/debug vacpp.compile.c++ ../../../bin.v2/libs/mpl/test/template_arity.test/vacpp/debug/template_arity.o **passed** ../../../bin.v2/libs/mpl/test/template_arity.test/vacpp/debug/template_arity.test MkDir1 ../../../bin.v2/libs/mpl/test/advance.test MkDir1 ../../../bin.v2/libs/mpl/test/advance.test/vacpp MkDir1 ../../../bin.v2/libs/mpl/test/advance.test/vacpp/debug vacpp.compile.c++ ../../../bin.v2/libs/mpl/test/advance.test/vacpp/debug/advance.o "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-0062 (S) The incomplete class "gcc_3_2_wknd" must not be used as a qualifier. "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-0700 (I) The previous message was produced while processing "boost::mpl::aux::has_tag<iter<0>,struct mpl_::bool_<0> >::value". "../../../boost/mpl/aux_/has_tag.hpp", line 20.35: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::aux::has_tag<iter<0>,mpl_::bool_<0> >". "../../../boost/mpl/if.hpp", line 55.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<0>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<0> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<0>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<0>,mpl_::int_<10> >". "advance.cpp", line 35.2: 1540-0700 (I) The previous message was produced while processing "test35()". "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-1269 (S) The template argument for the non-type template parameter of type "bool" must be an integral constant expression. "../../../boost/mpl/if.hpp", line 63.68: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::aux::has_tag<iter<0>,mpl_::bool_<0> >". "../../../boost/mpl/if.hpp", line 55.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<0>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<0> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<0>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<0>,mpl_::int_<10> >". "advance.cpp", line 35.2: 1540-0700 (I) The previous message was produced while processing "test35()". "../../../boost/mpl/if.hpp", line 63.11: 1540-1122 (S) A non-type template parameter cannot have type "bool". "../../../boost/mpl/tag.hpp", line 33.7: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<0>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<0> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<0>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<0>,mpl_::int_<10> >". "advance.cpp", line 35.2: 1540-0700 (I) The previous message was produced while processing "test35()". "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-0062 (S) The incomplete class "gcc_3_2_wknd" must not be used as a qualifier. "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-0700 (I) The previous message was produced while processing "boost::mpl::aux::has_tag<iter<10>,struct mpl_::bool_<0> >::value". "../../../boost/mpl/aux_/has_tag.hpp", line 20.35: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::aux::has_tag<iter<10>,mpl_::bool_<0> >". "../../../boost/mpl/if.hpp", line 55.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<10>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<10> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<10>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<10>,mpl_::int_<-10> >". "advance.cpp", line 44.2: 1540-0700 (I) The previous message was produced while processing "test44()". "../../../boost/mpl/aux_/has_tag.hpp", line 20.1: 1540-1269 (S) The template argument for the non-type template parameter of type "bool" must be an integral constant expression. "../../../boost/mpl/if.hpp", line 63.68: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::aux::has_tag<iter<10>,mpl_::bool_<0> >". "../../../boost/mpl/if.hpp", line 55.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<10>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<10> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<10>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<10>,mpl_::int_<-10> >". "advance.cpp", line 44.2: 1540-0700 (I) The previous message was produced while processing "test44()". "../../../boost/mpl/if.hpp", line 63.11: 1540-1122 (S) A non-type template parameter cannot have type "bool". "../../../boost/mpl/tag.hpp", line 33.7: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::if_<boost::mpl::aux::has_tag<iter<10>,mpl_::bool_<0> >,boost::mpl::aux::tag_impl<iter<10> >,mpl_::void_>". "../../../boost/mpl/tag.hpp", line 31.57: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::tag<iter<10>,mpl_::void_>". "../../../boost/mpl/advance.hpp", line 56.8: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::advance<iter<10>,mpl_::int_<-10> >". "advance.cpp", line 44.2: 1540-0700 (I) The previous message was produced while processing "test44()". /usr/vacpp/bin/xlC -c -DBOOST_ALL_NO_LIB=1 -qNOOPTimize -qnoinline -g -qeh -qrtti -I"../../.." -o "../../../bin.v2/libs/mpl/test/advance.test/vacpp/debug/advance.o" "advance.cpp"

1 0

Re: [boost] New boost webpage
by Martin Bonner 12 Aug '05

12 Aug '05

----Original Message---- From: Andreas Huber [mailto:ahd6974-spamgroupstrap@yahoo.com] Sent: 09 August 2005 21:24 To: boost(a)lists.boost.org Subject: Re: [boost] New boost webpage > Aleksey Gurtovoy wrote: >> Beth Jacobson writes: >>> David Abrahams wrote: >>>> Beth, your proposals sound interesting... but they'd be a whole lot >>>> easier to evaluate if you'd just make up the page or CSS stuff >>>> required and post it where we can all get a look at it. >>>> >>> >>> Done. The test page is up at http://bajac.com/boost/ >> >> Could we please, please get this rolled in 1.33? IMO this is a huge >> improvement in terms of the page readability. > > That's also my opinion (I did like some tiny details of the old page > better but that could be taken care of for 1.34). > > Regards, I really like the new link colouring. It seems to me that embedding links in continous text in a way that is a) easy to ignore when you are reading the text and b) easy to find when you are looking for the link, is essentially a hard problem. I would argue that Beth has got about as close as we are going to get (although I believe Rene objects to underlines). It WOULD be really nice to get this in to 1.33, but on the other hand I am not sure we have a consensus yet AND it is awfully late in the day to be making /any/ changes to the release. Final question: How do we go about establishing if we have a consensus or not so that we can at least update the main boost website? (Even if we can't include in 1.33). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

9 12

[1.33.0] RC_1_33_0 branch is CLOSED
by Douglas Gregor 12 Aug '05

12 Aug '05

The 1.33.0 release branch is now closed. Doug

2 2

[RFC] Alternative any design
by Pablo Aguilar 12 Aug '05

12 Aug '05

[I got an error when sending, please excuse me if this shows up twice] Hi, First of all, thanks to everyone who's commented on the proposed any alternative. Given that the alignment issue doesn't seem to be easy to solve, I'm thinking of giving up on trying to align correctly, and just skip the "in place storing of value" optimization when it might be an issue. So I'm wondering, is the following a proper way to detect alignment problems? <code> typedef void* any_buffer_base_type; // could be customized int const ANY_BUFFER_SIZE = sizeof(any_buffer_base_type); union object_holder { char buffer[ANY_BUFFER_SIZE]; void* pointer; any_buffer_base_type alignment_dummy_; }; template<typename T> struct optimize { enum { T_size_ = sizeof(T) , base_size_ = sizeof(any_buffer_base_type) , size_ok_ = (T_size_ <= base_size_) , T_align_ = alignment_of<T>::value , base_align_= alignment_of<any_buffer_base_type>::value , align_ok_ = ((base_align_ % T_align_) == 0) , value = size_ok_ && align_ok_ }; }; </code> I looked at Optional's alignment tecnique, and couldn't come up with how to use it, given that the stored type for any changes at runtime. If there's something I missed about this, any help would be welcome. My current solution is to use the above shown code (assuming it works, of course!), and fall back on heap based storage when optimization is deemed not possible. The 2nd question I had to ask is, how should any's alignment type be specified, with a configuration macro or through a template parameter? I haven't posted an updated version, given that there's some issues (other than alignment) still requiring attention. Thanks in advance for any help you might provide, Pablo Aguilar

1 0

[RFC] Alternative any design
by Pablo Aguilar 12 Aug '05

12 Aug '05

Hi, First of all, thanks to everyone who's commented on the proposed any alternative. Given that the alignment issue doesn't seem to be easy to solve, I'm thinking of giving up on trying to align correctly, and just skip the "in place storing of value" optimization when it might be an issue. So I'm wondering, is the following a proper way to detect alignment problems? <code> typedef void* any_buffer_base_type; // could be customized int const ANY_BUFFER_SIZE = sizeof(any_buffer_base_type); union object_holder { char buffer[ANY_BUFFER_SIZE]; void* pointer; any_buffer_base_type alignment_dummy_; }; template<typename T> struct optimize { enum { T_size_ = sizeof(T) , base_size_ = sizeof(any_buffer_base_type) , size_ok_ = (T_size_ <= base_size_) , T_align_ = alignment_of<T>::value , base_align_= alignment_of<any_buffer_base_type>::value , align_ok_ = ((base_align_ % T_align_) == 0) , value = size_ok_ && align_ok_ }; }; </code> I looked at Optional's alignment tecnique, and couldn't come up with how to use it, given that the stored type for any changes at runtime. If there's something I missed about this, any help would be welcome. My current solution is to use the above shown code (assuming it works, of course!), and fall back on heap based storage when optimization is deemed not possible. The 2nd question I had to ask is, how should any's alignment type be specified, with a configuration macro or through a template parameter? I haven't posted an updated version, given that there's some issues (other than alignment) still requiring attention. Thanks in advance for any help you might provide, Pablo Aguilar

1 0

[wave] No dynamic lib?
by Neal Becker 12 Aug '05

12 Aug '05

I notice that 1.33.0-rc2 doesn't build dynamic libs for wave. Is this intentional?

2 3

Re: [boost] [thread] assertion error when exiting app
by Sean Huang 11 Aug '05

11 Aug '05

> I didnt understand your solution... > You call on_thread_exit in the end of the threads that are created > with boost::thread ? Even if there are, possibly, other(COM) threads > running? It has nothing to do with boost::thread. I call on_thread_exit on any threads that use boost::thread_specific_ptr. on_thread_exit can be called multiple times so this workaround works with boost::thread too. One thing important is you cannot use boost::thread_specific_ptr after the call. I would consider this as a hack not a solution. Sean

1 0

archive stuck?
by Gennadiy Rozental 11 Aug '05

11 Aug '05

I don't see this month messages here: http://lists.boost.org/boost/2005/08/date.php Gennadiy

3 4