- Boost - lists.boost.org

Support requests report
by Marshall Clow 15 Jan '07

15 Jan '07

[ Down from 45 on Wednesday - thanks to those who took from 'nobody' ] Support count: 40 9 grafik 5 vladimir_prus 4 johnmaddock 3 ramey 3 nobody 3 jsiek 3 jbandela 2 turkanis 2 az_sw_dude 1 urzuga 1 samuel_k 1 rogeeff 1 hkaiser 1 fcacciola 1 djowel Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: support new 2007 DST rules for timezone db Bug #: 1471723 <http://sourceforge.net/tracker/index.php?func=detail&aid=1471723&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: new timezone db file for #1471723 - 2007 DST support Bug #: 1478619 <http://sourceforge.net/tracker/index.php?func=detail&aid=1478619&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Embedded python won't compile Bug #: 1391956 <http://sourceforge.net/tracker/index.php?func=detail&aid=1391956&group_id=7…> Assignee: fcacciola <http://sourceforge.net/users/fcacciola/> Summary: boost::optional<enum> fails with /CLR Bug #: 973424 <http://sourceforge.net/tracker/index.php?func=detail&aid=973424&group_id=75…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Jam Fails to Build Bug #: 954048 <http://sourceforge.net/tracker/index.php?func=detail&aid=954048&group_id=75…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Boost on opteron AMD Bug #: 1200700 <http://sourceforge.net/tracker/index.php?func=detail&aid=1200700&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Linker Problems with VC .NET 2003 / STLPort / Boost Bug #: 1292345 <http://sourceforge.net/tracker/index.php?func=detail&aid=1292345&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Unable to build boost with Dinkumware STL version 4.02 Bug #: 1336312 <http://sourceforge.net/tracker/index.php?func=detail&aid=1336312&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Compiling only needed version Bug #: 1377001 <http://sourceforge.net/tracker/index.php?func=detail&aid=1377001&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Building universal binary on MacOSX Bug #: 1409774 <http://sourceforge.net/tracker/index.php?func=detail&aid=1409774&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Cross compiling boost for Windows CE (ARM) from VS2005 Bug #: 1457763 <http://sourceforge.net/tracker/index.php?func=detail&aid=1457763&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: libraries won't build Bug #: 1524001 <http://sourceforge.net/tracker/index.php?func=detail&aid=1524001&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: Having some trouble building boost Bug #: 1534701 <http://sourceforge.net/tracker/index.php?func=detail&aid=1534701&group_id=7…> Assignee: hkaiser <http://sourceforge.net/users/hkaiser/> Summary: compiler is out of heap space in pass 2 Bug #: 1481122 <http://sourceforge.net/tracker/index.php?func=detail&aid=1481122&group_id=7…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Problem compiling :/ Bug #: 942349 <http://sourceforge.net/tracker/index.php?func=detail&aid=942349&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: SLOOOWW tokenizer compilation on VC++6.0 Bug #: 969590 <http://sourceforge.net/tracker/index.php?func=detail&aid=969590&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Visual C++ 'Language Extensions' support Bug #: 1039338 <http://sourceforge.net/tracker/index.php?func=detail&aid=1039338&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Regex Bug #: 1156957 <http://sourceforge.net/tracker/index.php?func=detail&aid=1156957&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Problem running configure for unsupported platform Bug #: 1339778 <http://sourceforge.net/tracker/index.php?func=detail&aid=1339778&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: regex - perl syntax affects what gets matched Bug #: 1519824 <http://sourceforge.net/tracker/index.php?func=detail&aid=1519824&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Crash on RH machine with gcc < 3.4 Bug #: 1635211 <http://sourceforge.net/tracker/index.php?func=detail&aid=1635211&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Boost with Dinkumware C++ Library !? Bug #: 531963 <http://sourceforge.net/tracker/index.php?func=detail&aid=531963&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: creating my own properties Bug #: 619615 <http://sourceforge.net/tracker/index.php?func=detail&aid=619615&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Max Flow Algorithm Bug #: 1445526 <http://sourceforge.net/tracker/index.php?func=detail&aid=1445526&group_id=7…> Assignee: nobody Summary: Having problems with building boost Bug #: 1545941 <http://sourceforge.net/tracker/index.php?func=detail&aid=1545941&group_id=7…> Assignee: nobody Summary: Building Boost with Open Watcom Compiler Bug #: 1547257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1547257&group_id=7…> Assignee: nobody Summary: memory pattern question Bug #: 1634278 <http://sourceforge.net/tracker/index.php?func=detail&aid=1634278&group_id=7…> Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: serialization and namespaces incompatability Bug #: 1628807 <http://sourceforge.net/tracker/index.php?func=detail&aid=1628807&group_id=7…> Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: boost serialization operators & and << and >> Bug #: 1630494 <http://sourceforge.net/tracker/index.php?func=detail&aid=1630494&group_id=7…> Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: Deriving Serialization classes Bug #: 1633062 <http://sourceforge.net/tracker/index.php?func=detail&aid=1633062&group_id=7…> Assignee: rogeeff <http://sourceforge.net/users/rogeeff/> Summary: failing on 6 targets in MacOS X Bug #: 1572712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1572712&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: Boost.Format doesn't work on MSVC with /vd2 compiler option Bug #: 1545133 <http://sourceforge.net/tracker/index.php?func=detail&aid=1545133&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: Boost.Iostreams and newline translation Bug #: 1299123 <http://sourceforge.net/tracker/index.php?func=detail&aid=1299123&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: boost.iostreams file_descriptor and sharing Bug #: 1445474 <http://sourceforge.net/tracker/index.php?func=detail&aid=1445474&group_id=7…> Assignee: urzuga <http://sourceforge.net/users/urzuga/> Summary: lambda vs pure virtual functions Bug #: 1231445 <http://sourceforge.net/tracker/index.php?func=detail&aid=1231445&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: program_options Can one have options with optional values? Bug #: 1102652 <http://sourceforge.net/tracker/index.php?func=detail&aid=1102652&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: program_options Can one have options with optional values? Bug #: 1102664 <http://sourceforge.net/tracker/index.php?func=detail&aid=1102664&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: program_options bug? Bug #: 1114084 <http://sourceforge.net/tracker/index.php?func=detail&aid=1114084&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: Boost.Build v2 build script help for evc4 Bug #: 1498919 <http://sourceforge.net/tracker/index.php?func=detail&aid=1498919&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: Bjam build should support attachment of individual build ids Bug #: 1530168 <http://sourceforge.net/tracker/index.php?func=detail&aid=1530168&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Warning from share_ptr
by Paul A Bristow 15 Jan '07

15 Jan '07

I am getting an annoying warning when building boost_math.dll AND generating Microsoft VS 8.0 'managed' code /clr:pure, even at warning level 1. (clr code is needed because we are building a Windows .net form in C# to demonstrate Math function and Statistics Distribution using John Maddock's Math Toolkit in C++. Aside - with a lot of annoying wrapping, John has made this work). The message is: C4793 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' Adding this #pragma to the top of our boost_math.cpp file does NOT suppress it. #pragma warning(disable: 4793) // 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' Is this worrying? Is there something wrong with the pushing and popping of warnings? Someone has already done some message suppression for SGI I see. #ifdef sgi // Turn off: the last argument of the varargs function "sp_enable_shared_from_this" is unnamed # pragma set woff 3506 #endif Is this the right way to deal with it for MSVC in shared_prt.hpp? #ifdef _MSC_VER #pragma warning(push) #pragma warning(disable: 4793) // 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' #endif inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } #ifdef sgi # pragma reset woff 3506 #endif #ifdef _MSC_VER #pragma warning(pop) #endif With this it gives a clean compile :-)) Could/should this is added to the normal Boost shared_prt.hpp? Or is there a cleaner solution that avoids vararg? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

2 2

BoostCon 2007 Program Committee progress report
by Beman Dawes 15 Jan '07

15 Jan '07

We've got interesting proposals from experienced presenters, have accepted a bunch, and have started to put together a tentative schedule for the week. We should finish accepting proposals in the next week or so and be able to go public with the schedule real soon after that. The people we have sessions proposals from are listed below. If you sent in a proposal and are not on the list, please contact me right away! Dave Abrahams Beman Dawes Jeff Garland Doug Gregor Mat Marcus Scott Meyers Eric Niebler Kevlin Henney Howard Hinnant Harmut Kaiser / Joel de Guzman Sean Parent Gennadiy Rozental Timothy Shead Jeremy Siek Matthias Troyer The conference dates (May 14-16) are firm, and other arrangements are moving forward. See http://www.boost.org/more/BoostCon07.html Thanks to Dave Abrahams and Boost-Consulting for providing the wiki we are using to coordinate conference planning. It is invaluable. --Beman Dawes, BoostCon 2007 Program Committee chair

1 0

[type_traits] please update is_convertible.hpp header in the RC branch
by Boris Gubenko 15 Jan '07

15 Jan '07

The version of boost/type_traits/is_convertible.hpp in RC_1_34_0 branch has wrong conditionalization for HP-UX. It has been fixed in CVS HEAD -- see below. This bug is causing two tests to fail on HP-UX/aCC6 in RC_1_34_0: . is_convertible_test from type_traits library . tr1_is_convertible_test from tr1 library I've confirmed, that with the HEAD version of the header, the two tests above pass (the type_traits library is, actually, becomes green) and using the HEAD version of the header in RC_1_34_0 testing does not introduce any regressions. Please, update boost/type_traits/is_convertible.hpp header in the RC branch with the version in CVS HEAD. As you can see from the attached differences, this bugfix is the only change in this header between CVS HEAD and the RC branch. Thanks, Boris Index: is_convertible.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_convertible.hpp,v retrieving revision 1.37 retrieving revision 1.38 diff -r1.37 -r1.38 343c343 < #ifndef __HP_aCC --- > #if !BOOST_WORKAROUND(__HP_aCC, < 60700)

2 1

[xpressive] HEAD doc issue
by Vladimir Prus 15 Jan '07

15 Jan '07

At the moment, CVS HEAD has this in lib/xpressive/doc/Jamfile.v2: xml xpressive : xpressive.qbk : <dependency>autodoc ; What is the reason for <dependency>autodoc here? I don't think that the target is used during generation of xpressive.xml, and I also believe that this change breaks doc build. With it, running bjam in that dir does not work. Without it works. I think this problem exists since the change was committed on 22 Oct 2006. Comments? - Volodya

4 13

Re: [boost] [shared_ptr] how does quick_allocator free its memory pool?
by Steven Watanabe 14 Jan '07

14 Jan '07

AMDG > Peter Dimov wrote: > >> > gchen wrote: >> >>> >> But it seems that quick_allocator never free the memory pool (blocks) >>> >> after my program exits, do I miss something? >>> >> > >> > It doesn't. After your program exits, all memory is automatically freed by >> > the OS. There's no need to free it explicitly, except maybe to keep >> > simplistic leak checkers happy. >> > >> Maybe we can have a special allocation function for when the memory might never be freed. void* allocate_potentially_unfreed_memory(std::size_t size) { #ifdef BOOST_SIMPLISTIC_LEAK_CHECKER char* result = static_cast<char*>(::operator new(size + (std::max)(MAXIMUM_ALIGNMENT, 16))); std::strcpy(result, "boost::unfreed"); return(result + (std::max)(MAXIMUM_ALIGNMENT, 16)); #else return(::operator new(size)); #endif } In Christ, Steven Watanabe

1 0

Re: [boost] Warning from share_ptr
by Steven Watanabe 14 Jan '07

14 Jan '07

AMDG "Peter Dimov" wrote: > Avoiding the ... isn't as trivial as it appears. You might want to try > replacing > > inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) > { > } > > with > > struct sp_any_pointer > { > template<class T> sp_any_pointer( T* ) {} > }; > > inline void sp_enable_shared_from_this( shared_count const & /*pn*/, > sp_any_pointer, sp_any_pointer ) > { > } > > for the _MANAGED case and see if it helps. Also, you can make the return type non-void and use sizeof to avoid calling it. struct enable_shared_from_this_t { enable_shared_from_this_t operator,(int); }; typedef char no; struct yes { no dummy[2]; }; no test_sp_enable_shared_from_this(enable_shared_from_this_t); template<class T> yes test_sp_enable_shared_from_this( T const &); template<class T, class Y> void sp_enable_shared_from_this( shared_count const & pn, boost::enable_shared_from_this<T> const * pe, Y const * px ) { if(pe != 0) pe->_internal_weak_this._internal_assign(const_cast<Y*>(px), pn); } struct sp_any_pointer { template<class T> sp_any_pointer( T* ) {} }; inline void sp_enable_shared_from_this( shared_count const & /*pn*/, sp_any_pointer, sp_any_pointer ) { } //inline enable_shared_from_this_t sp_enable_shared_from_this( shared_count const & /*pn*/, ... ); template<class T, class Y> void call_sp_enable_shared_from_this_impl( shared_count const & pn, T const * pe, Y const * px, boost::mpl::true_ ) { sp_enable_shared_from_this(pn, pe, px); } template<class T, class Y> void call_sp_enable_shared_from_this_impl( shared_count const &, T const *, Y const *, boost::mpl::false_ ) { } template<class T, class Y> void call_sp_enable_shared_from_this( shared_count const & pn, T const * pe, Y const * px) { boost::mpl::bool_<sizeof( test_sp_enable_shared_from_this((sp_enable_shared_from_this(pn, pe, px),0)) )==sizeof(yes)> condition; call_sp_enable_shared_from_this_impl(pn, pe, px, condition); } In Christ, Steven Watanabe

1 0

[Report] 25 regressions on RC_1_34_0
by Douglas Gregor 14 Jan '07

14 Jan '07

Boost Regression test failures Report time: 2007-01-14T08:21:02Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 25 failures in 6 libraries concept_check (15) date_time (1) regex (1) test (2) utility (1) wave (5) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64 |wave| testwave: darwin-4.0.1 gcc-4.1.1_sunos_i86pc testwave_dll: darwin-4.0.1 gcc-3.3.6 gcc-4.1.1_sunos_i86pc

2 1

[shared_ptr] how does quick_allocator free its memory pool?
by gchen 14 Jan '07

14 Jan '07

I am trying to enable BOOST_SP_USE_QUICK_ALLOCATOR while using shared_ptr, so to make shared_ptr to use quick_allocator to alloc/dealloc memory, But it seems that quick_allocator never free the memory pool (blocks) after my program exits, do I miss something? Or do I need extra step to use quick_allocator? I am using boost cvs head, vs2005, and disabled BOOST_HAS_THREADS (yes, for speed issue, same reason for using quick_allocator), vs2005.

2 2

[Threads] uncoditional scoped lock?
by Sohail Somani 14 Jan '07

14 Jan '07

Hi, Somewhat longer-than-normal-noise follows :) Consider the following pseudo-code which has a race condition: condition g_some_cond; mutex g_condition_mtx; void thread_fn() { { ... // get lock g_some_cond.wait(condition_lock); } // do work } void main_thread() { thread_group grp; // Start all threads and have them wait on the condition for(i in [0,N)) grp.create_thread(&thread_fn); { ... // get lock g_some_cond.notify_all(); // let threads continue } } The race condition is of course that it is possible that not all threads actually start waiting on the condition before notify_all() is called. In this case, it is possible to solve the race condition in two ways: 1) Have the last thread that reaches the condition wait, signal to the main thread 2) Have the main thread checking the condition before notify_all() I don't really like the first case because it requires bi-directional signalling between the threads. Though in my ignorance, I really do consider it the correct solution. The second solution would look something like this: while(true) { scoped_lock cond_lock(g_condition_mtx); // .num_waiting_threads() is made up if(N_EXPECTED_THREADS==g_some_cond.num_waiting_threads()){break;} // release lock } Should the second pattern be encapsulated in the condition object somehow? It is almost like timed_wait(mtx,xt,pred) but there is no timeout. So maybe untimed_wait()? Is there another way to do this? Thanks for your eyes! Sohail

4 6