- Boost - lists.boost.org

[boost.log] set_open_handler() and set_close_handler() for text_multifile_backend?
by Jamie Allsop 10 Nov '10

10 Nov '10

I think it makes a lot of sense for these methods to be available for the text_multifile_backend as they are for the text_file_backend. My use case is that I am logging data out in html format and being able to log data out as individual html files for browsing through later on. Being able to have an html header and footer added as files are opened and closed makes a lot of sense for this backend. Jamie

2 4

[optional] swap not a member of boost::optional
by Eric Niebler 10 Nov '10

10 Nov '10

It seems like boost::optional has a swap member function on trunk but not on release, and it's been this way for a few releases already. Can we get this inconsistency resolved? I've been bitten by it a few times already when merging things to the release branch. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 1

[graph] Kudos!
by K. Noel Belcourt 10 Nov '10

10 Nov '10

Hi, Just wanted to say nice job to Jeremiah Willcock!! Found this killer graph on page 5: http://www.sandia.gov/LabNews/ln11-05-10/labnews11-05-10.pdf I probably cut the citation off (it reads: Graph courtesy of Jeremiah Willcock, Indiana University). Guessing this was generated with pBGL? -- Noel

1 0

[fusion] rev. 66411 breaks VC 8.0
by Ralf W. Grosse-Kunstleve 10 Nov '10

10 Nov '10

minimal.cpp: #include <boost/fusion/sequence/comparison/less_equal.hpp> cl /c /EHsc /I..\hot\boost minimal.cpp Gives the error below. It works with rev. 66410 but not 66411 (and still not with current 66472): % svn log -v -c66411 ------------------------------------------------------------------------ r66411 | cschmidt | 2010-11-06 05:21:18 -0700 (Sat, 06 Nov 2010) | 1 line Changed paths: M /trunk/boost/fusion/container/deque/deque.hpp A /trunk/boost/fusion/container/deque/detail/is_sequence_impl.hpp M /trunk/boost/fusion/container/vector/detail/vector_n.hpp M /trunk/boost/fusion/sequence/comparison/detail/enable_comparison.hpp M /trunk/boost/fusion/support/detail/is_mpl_sequence.hpp M /trunk/boost/fusion/support/is_sequence.hpp M /trunk/boost/fusion/support/sequence_base.hpp Fusion: removed fusion::sequence_root; Fixes #2335 ------------------------------------------------------------------------ ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2065: 'is_native_fusion_sequence' : undeclared identifier ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected ..\hot\boost\boost/utility/enable_if.hpp(59) : see declaration of 'boost ::disable_if' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2988: unrecognizable template declaration/definition ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2059: syntax error : ',' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2039: 'type' : is not a member of '`global namespace'' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(55) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(55) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected ..\hot\boost\boost/utility/enable_if.hpp(59) : see declaration of 'boost ::disable_if' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(56) : error C2039: 'type' : is not a member of '`global namespace'' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(57) : error C2143: syntax error : missing ';' before '{' ..\hot\boost\boost/fusion/sequence/comparison/less_equal.hpp(57) : error C2447: '{' : missing function header (old-style formal list?)

2 2

Showstopper ticket #4736 not in trunk or release
by Jim Bell 10 Nov '10

10 Nov '10

The patch for showstopper ticket # 4736 isn't in either the trunk or release branches as of this morning (r66453). Did it get missed?

3 7

MinGW's last thread/tss problem: fixable?
by Jim Bell 10 Nov '10

10 Nov '10

Thread is still failing test_tss_lib, now with this... ../libs/thread/test/test_tss.cpp(181): error in "test_tss": Support of automatic tss cleanup for native threading API not available If I understand this correctly, the tss cleanup will never be called for a thread created via the native API. There's no global function that can force a clean-up because nothing can force the underlying thread mechanism to return the thread-specific value for a thread that's already exited. I see some subtle magic in libs/thread/src/win32/tss_pe.cpp, some even for __MINGW32_... Is this for static libs? Any chance we can make that work for MinGW's gcc-4.3.3 and gcc-4.4.0? Also, I think the docs need a "Note" section describing this issue, say thread_local_storage.html, inside the section "Cleanup at thread exit".

2 1

Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts TOMORROW
by Aaron Graham 10 Nov '10

10 Nov '10

See this gcc bugzilla entry for a discussion I've had about chrono support in the gcc implementation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 Unfortunately, monotonic_clock support, even if it exists, is a transparent lie. It's not so much a problem with the chrono library as it is a problem with the thread library's use of chrono. A monotonic clock is used to provide somewhat accurate/reliable wait times even in the face of changing clocks, especially in the case of mutexes and condition variables. When condition::wait_until is called with a monotonic_clock time_point, that time_point is translated to a system_clock time_point. If the system_clock is changed (via NTP, adjtime, settimeofday, etc) between when convert_to<system_clock> is called and when the underlying posix call is made, the very reason for using monotonic_clock defenestrates and splatters all over the pavement. Depending on the magnitude of the clock change, wait_until could hang forever. In my opinion, all convert_to calls in the thread library should go to the monotonic_clock, if available. Not system_clock. I couldn't get the gcc people to understand this, so I won't be able to use <chrono> in the standard library sans modification. Maybe boost will get it right? Let me know if I'm missing a subtle point that moots my concerns. Other than that, I think the this library is great. I need it badly. I haven't looked over all the code yet, but what I've seen looks good.

3 2

mkl+boost problems
by Andrey Asadchev 10 Nov '10

10 Nov '10

Hello. mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable: 70 /** CPU codes for int MKL_CPU_DETECT(void) **/ 71 #ifdef _IPF 72 #define ITP 0 73 #else 74 #ifdef _EM64T 75 #define NI 0 76 #define CT 1 77 #define MNI 2 78 #define PNR 3 79 #else 80 #define DEF 0 81 #define PIII 1 82 #define P4 2 83 #define P4P 3 84 #define P4M 4 85 #endif 86 #endif This P4 variable creates havoc of MPL templates which have P4 template parameters names. What to do?

9 10

Re: [boost] [msm] Event deferring causes stack overflow
by Christophe Henry 09 Nov '10

09 Nov '10

> Hi All > > We have found a serious problem in msm back end for event deferring. > I case there is a composite state and the outer state machine defers 2 > events when it is in the composite state, the 1st event deferred fine > in the deferred queue of the outer state machine. > Than the 2nd event is processed and this is deferred as well as a part > of this deferral msm back end dispatches the 1st event but it is still > deferred and saved again in the deferred queue but than msm processes > the deferred queue again as an action of the deferral of the 1st event > and dispatches the 2nd event again which is deferred and the cycle > repeats itself until the system runs out of call stack. Hi, No, it's not that serious, but still not nice. The problem is that the principle of the Defer functor is not working and I am wondering if I should keep it. To make short, Defer is an action, and for all front-ends, actions return void. This has the unintended effect of marking the transition results as "handled" instead of "deferred", which breaks my defensive measures. If you replace the transitions by the standard UML method of marking the state as deferring (through the deferred_events typedef), you have no more stack overflow. Now I understand that the Defer functor is cool and offering to remove it is guaranteed to cause disappointment, so I see 2 possibilities: - explaining its limitations in the doc - making a change to all front-ends for this special case to work around the fact that actions return void For the meantime, use the "normal" way and I will see if I find a workaround. Cheers, Christophe

2 1

[mpl] mpl::c_str fails for mpl::push_back
by vicente.botet 09 Nov '10

09 Nov '10

Hi, the following results in a compile error for msvc-10.0. It works for gcc-3.4, gcc-4.3, gcc-4.5. typedef mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'> hello; typedef mpl::push_back<hello, mpl::char_<'!'> >::type hello2; BOOST_TEST((std::string(mpl::c_str<hello2>::value)== "hello world!")); // line 59 C:\cygwin\boost\v44\boost/mpl/string.hpp(592) : error C2039: 'value_type' : is not a member of 'boost::mpl::vector12<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11>' with [ T0=boost::mpl::integral_c<char,104>, T1=boost::mpl::integral_c<char,101>, T2=boost::mpl::integral_c<char,108>, T3=boost::mpl::integral_c<char,108>, T4=boost::mpl::integral_c<char,111>, T5=boost::mpl::integral_c<char,32>, T6=boost::mpl::integral_c<char,119>, T7=boost::mpl::integral_c<char,111>, T8=boost::mpl::integral_c<char,114>, T9=boost::mpl::integral_c<char,108>, T10=boost::mpl::integral_c<char,100>, T11=boost::mpl::char_<33> ] io\match_pass.cpp(59) : see reference to class template instantiation 'boost::mpl::c_str<Sequence>' being compiled with [ Sequence=hello2 ] Is this a known bug? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 13