November 2010 - Boost - lists.boost.org

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

[msm] Event deferring causes stack overflow
by Richard Szabo 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. please find the code to reproduce the problem in attachment. thanks for the help in advance. Br. Richie

1 0

Boost and (Microsoft's) _SECURE_SCL
by Martin B. 09 Nov '10

09 Nov '10

Boost and Microsoft's _SECURE_SCL Long story short of this post: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? The Microsoft (Dinkumware) _SECURE_SCL=1 macro [1],[2] adds additional checks to standard library iterators/containers, rendering them ABI incompatible with _SECURE_SCL setting 0 vs. 1. This in turn leads to crashes when using a wrong combination of this flag. For example: [3] This has been discussed numerous times before: [4], [5], [6] -- see [5] for a list of further links to more threads. A trac issue [7] to add a specific build option has been closed as invalid. What I have been unable to determine is what the status is on supporting an additional *name mangling scheme* for the _SECURE_SCL option. From what I can discern from the current Getting Started page [8], not only do we not support any such name mangling, but the _SECURE_SCL macro (or the new _ITERATOR_DEBUG_LEVEL macro in VS2010) is not even mentioned on the Getting Started page. Since Visual Studio 2005 defaulted to _SECURE_SCL=1 and boost just uses the default, many people hit this when they used _SECURE_SCL=0 to improve performance in their release builds. (Which, as an aside, doesn't yield too much, as the real showstopper is the - independent! - _HAS_ITERATOR_DEBUGGING macro and that is only active in debug builds anyway.) In Visual Studio 2010, the situation is reversed, as Microsoft decided to now default to _SECURE_SCL=0. That means the people who change it to 1 in their release build for additional security will be bitten by the problem. (Or not, as it seems that they added some link-time checks in VS2010 to detect mismatches regarding the _ITERATOR_DEBUG_LEVEL. [9]) OK, so now again: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? -- Or are we just going to ignore the issue since VS2010 defaults to the "boost preferred" - off - option now anyway? By "boost preferred" I mean that from some of the discussions it seemed to me that there was doubts w/rgd to complexity issues etc. when _SECURE_SCL is on. cheers, Martin p.s.: FWIW, here's how /I/ compile my release version of boost 1.44 on VS2005: bjam.exe --build-type=complete variant=release toolset=msvc-8.0 threading=multi define=_SECURE_SCL=0 --with-regex --with-program_options --with-test --with-serialization stage [1] Visual Studio 2005 - _SECURE_SCL : http://msdn.microsoft.com/en-us/library/aa985896%28VS.80%29.aspx [2] Visual Studio 2010 - _SECURE SCL : http://msdn.microsoft.com/en-us/library/aa985896%28v=VS.100%29.aspx [3] access violation with _SECURE_SCL turned off : http://lists.boost.org/boost-users/2009/02/45137.php [4] _SECURE_SCL for msvc (2009) : http://thread.gmane.org/gmane.comp.lib.boost.devel/185898/focus=185987 [5] MSVC _SECURE_SCL causes ABI change, ODR violation - mangle library names? : http://lists.boost.org/boost-users/2008/10/41253.php [6] Re: Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes : http://thread.gmane.org/gmane.comp.lib.boost.devel/144082/focus=144089 [7] Add build option to define _secure_scl=0 + add runtime check to ensure no ODR violation : https://svn.boost.org/trac/boost/ticket/2086 [8] Boost 1.44 Getting Started on Windows : http://www.boost.org/doc/libs/1_44_0/more/getting_started/windows.html [9] Visual STuduio 2010 - detect_mismatch : http://msdn.microsoft.com/en-us/library/ee956429.aspx

5 11

encryption?
by Brian Wood 09 Nov '10

09 Nov '10

I recall a few threads on the subject of a fledgling Boost Encryption library, but haven't seen anything about it recently. Could someone update me on this? I've used OpenSSL enough to desire a C++ alternative. (Imagine some existing Boost libs written in C.) -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384 "The kingdom of heaven is like a treasure hidden in the field, which a man found and hid again; and from joy over it he goes and sells all that he has and buys that field."

1 0

[function] new implementation
by Domagoj Saric 09 Nov '10

09 Nov '10

Hi, <...those that followed the latest function related discussions can skip the first paragraph...> For about a year and half now (or even more but that's about how long I've been involved in the matter) there have been repeated discussions/requests/complaints about various aspects of Boost.Function. Most of those fall into one or more of these categories: - overall code speed overhead - overall code bloat overhead - lack of configurability - dependencies on RTTI and exception handling with the most frequently brought up specific issue being the various implications (in all of the above mentioned areas) of the hardcoded throw-on-empty behaviour... Unfortunately Boost.Function code remained virtually unchanged (except for the added RTTI emulation for platforms w/o RTTI support) with all of the issues still remaining... The new implementation proposal @: https://svn.boost.org/svn/boost/sandbox/function/boost/function http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… Objects solves or at least provides drastic improvements for all of the mentioned issues. It is intended as a drop in replacement for the current implementation and as such I have so far tested it in the following ways: - compiling some real world code: VC10, GCC 4.2.1, LLVM-GCC 4.2.1, GCC 4.5.1, GCC 4.6, Clang 2.0, Clang 2.8 - compiling and running a real world project: VC10, Clang 2.8 - building Boost trunk: VC10, GCC 4.2.1, GCC 4.5.1, Clang 2.0 - running Boost regression tests for Function, Signals, Signals2, Thread, Program Options and Graph libraries: VC10, GCC 4.2.1, Clang 2.0. (All of the tests passed except for two bogus assertion failure boxes that pop up with VC10 and the Program Options tests during the automated regression test procedure that OTOH do not popup when I run the same tests manually through the VC10 IDE, i.e. the tests finish successfully...I tried to make sure all the relevant compiler switches were the same in both cases so I am out of ideas what else can make the difference.....) Next, let me give you a comparison of for-size-optimized code generated by VC10 with both the current and the proposed implementation for a short code snippet demonstrating invocation, construction and assignment: struct X { int foo( int const x ) const { return x + y; }; int y; }; int main( int /*argc*/, char * * /*argv*/ ) { using namespace boost; X x; function<int(int)> foof( boost::bind( &X::foo, &x, _1 ) ); foof( 0 ); function<int(int)> barf; barf = foof; barf( 1 ); return 0; } Notice in new_function_code_listing.txt how all of the wrapper code in the new Function was completely transparent to the compiler and was completely inlined to relatively simple machine code with direct calls to/through the vtable pointers...while OTOH in current_function_code_listing.txt the code generated for the "barf = foof;" assignement alone is several times larger than the entire code generated for the new Function implementation. The small asm snippet of the generated invoker/'thunk'/'trampoline' code also demonstrates the effects of various tweaks done to minimize or all together remove the need for any stack adjustment on the invoker side... The new implementation of course has the same semantics and exception safety guarantee levels as the original/current one. Listing all of the improvements and detailed implementation changes here in the first post would be quite cluttering as they are quite numerous. Those that desire more tests and details right now, can follow this trail: http://lists.boost.org/Archives/boost/2010/01/160908.php As for the dependencies issue this is solved in several ways: - use of exception handling: new code uses guard objects instead of explicit exception handling and provides a way to change on-empty-behaviour so that the EH code/dependency can easily be removed/disabled - use of RTTI (for getting the type of the stored function object): this can be globally disabled with the BOOST_FUNCTION_NO_RTTI macro. BOOST_NO_RTTI is not used for this purpose for backward compatibility reasons: in the current implementation it actually turns on RTTI emulation...The idea is to also add per instantiation RTTI on-off configurability... 'Configurability' will probably be the most controversial issue/change because it required the addition of an extra template parameter through which an MPL list of policies can be specified at compile-time. This parameter is properly defaulted to allow existing code to compile without changes while providing current Boost.Function behaviour (e.g. on-empty- behaviour). As all the performed tests showed this to also be true in practice the proposed code should IMO go in as a straight drop-in replacement but, of course, I might have missed some important higher level detail/concern so this is open to discussion... Currently two policies are supported: - on throw behaviour (with throw-on-empty, nop-on-empty and assert-on-empty handlers provided) - whether the function instantiation should mark itself (i.e. its operator()) as nothrow. Additional policies my be added later, for example: - sizeof and/or alignment of the SBO buffer - default allocator - per instantiation RTTI on/off ... Finally, there is one more addition, somewhat 'unholy' as it brings in the concept of binding into Boost.Function but considering its efficiency and/or verbosity benefits (and the fact that the first issue can be 'explained away' by saying that this is not actually 'binding' but a workaround for the lack-of-delegates-support C++ language deficiency). The addition is in the form of two more assign() member function overloads (one for a free function that has the exact signature as the Boost.Function instantiation, and one for a member function that has a matching signature with the addition of a this pointer) that allow assignment of (suitably typed) plain (free or member) functions specified as non-type-template parameters. This allows for the removal of the extra indirect-call-through-function-pointer otherwise incurred by traditional assignment of function pointers (not functors), which is actually a rather common use case. For example, in the above example given, one can now write: foof.assign<X, &X::foo>( x ); and get a trivial invoker with the X::foo() target function inlined straight in... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

7 27

Will test/doc be merged?
by Jim Bell 08 Nov '10

08 Nov '10

Looks like a lot of changes to test/doc and subdirectories were committed to the trunk on 6/10/2010. They fix at least one problem I saw. (doc/html/index.html, BOOST_TEST_PASSPOINT points to "Logging floating point type numbers", which is in the mis-named file BOOST_TEST_PASSPOINT.html.) Anyone know the status? Can it be merged into the release?

1 0