- Boost - lists.boost.org

[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

[multi_index] scalar insert interface
by Maxim Yegorushkin 08 Nov '10

08 Nov '10

Hey guys, In ordered_index there are two scalar insert overloads: std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x); The second version is lacking the bool result, which is sometimes required. In my source code of boost-1_42 I patched the second version like this: ==== .../ordered_index.hpp#2 (text) ==== @@ -97,6 +99,16 @@ struct ordered_unique_tag{}; struct ordered_non_unique_tag{}; +template<class T, class U> +struct auto_cast_pair : std::pair<T, U> +{ + typedef std::pair<T, U> base_pair; + auto_cast_pair(base_pair const& b) : base_pair(b) {} + using base_pair::operator=; + operator T&() { return this->first; } + operator T const&() const { return this->first; } +}; + template< typename KeyFromValue,typename Compare, typename SuperMeta,typename TagList,typename Category @@ -274,14 +286,14 @@ return std::pair<iterator,bool>(make_iterator(p.first),p.second); } - iterator insert(iterator position,value_param_type x) + auto_cast_pair<iterator,bool> insert(iterator position,value_param_type x) { BOOST_MULTI_INDEX_CHECK_VALID_ITERATOR(position); BOOST_MULTI_INDEX_CHECK_IS_OWNER(position,*this); BOOST_MULTI_INDEX_ORD_INDEX_CHECK_INVARIANT; std::pair<final_node_type*,bool> p=this->final_insert_( x,static_cast<final_node_type*>(position.get_node())); - return make_iterator(p.first); + return std::pair<iterator,bool>(make_iterator(p.first),p.second); } template<typename InputIterator> Now it automatically figures which return value one wants. Just an idea. -- Max

4 5

[mpl] map insert
by vicente.botet 08 Nov '10

08 Nov '10

Hi, in /libs/mpl/doc/refmanual/map.html insert<m,x>::type point to the description of insert<m,pos,x>::type. In addition I don't find the descrition of insert<m,x>::type in libs/mpl/doc/refmanual/intrinsic-metafunctions.html Can this be added? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

Re: [boost] [Boost-commit] svn:boost r66442 - in trunk/boost: math/tools test test/impl
by Jürgen Hunold 08 Nov '10

08 Nov '10

Hi ! On Sunday, 7. November 2010 21:05:06 admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2010-11-07 15:05:04 EST (Sun, 07 Nov 2010) > New Revision: 66442 > URL: http://svn.boost.org/trac/boost/changeset/66442 > > Log: > Clang hand-holding, mostly for issues caused by Clang defining GCC macros. I do not think that removing the inclusion of "fenv.h" for clang is the right solution. According to http://llvm.org/bugs/show_bug.cgi?id=6907 it is a known compiler bug that clang fails to correctly load "fenv.h" in certain environments (several gcc versions installed...) I've been working around this by simply adding (see below) > Text files modified: > trunk/boost/math/tools/config.hpp | 2 +- > trunk/boost/test/execution_monitor.hpp | 15 ++++++++------- > trunk/boost/test/impl/execution_monitor.ipp | 18 +++++++++--------- > 3 files changed, 18 insertions(+), 17 deletions(-) > > Modified: trunk/boost/math/tools/config.hpp > =========================================================================== > === --- trunk/boost/math/tools/config.hpp (original) > +++ trunk/boost/math/tools/config.hpp 2010-11-07 15:05:04 EST (Sun, 07 > Nov 2010) @@ -255,7 +255,7 @@ > } // namespace tools > }} // namespace boost namespace math > > -#if (defined(__linux__) && !defined(__UCLIBC__)) || defined(__QNX__) || > defined(__IBMCPP__) +#if (defined(__linux__) && !defined(__UCLIBC__) && > !defined(__clang__)) || defined(__QNX__) || defined(__IBMCPP__) > > #include <fenv.h> #if defined(__clang__) #include </usr/include/fenvh.> #else for my local working copies. > return ~old_cw & BOOST_FPE_ALL; > -#elif defined(__GLIBC__) && defined(__USE_GNU) > +#elif defined(__GLIBC__) && defined(__USE_GNU) && !defined(BOOST_CLANG) > > ::feclearexcept(BOOST_FPE_ALL); And this actually removes fp-Support from Boost.Test. Not good. Please find a better solution. And/Or mark the relevant places with Todo containing a reference to the clang bug report. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 4

[mpl] What about wstring, u16string and u32string
by vicente.botet 08 Nov '10

08 Nov '10

Hi, I was considering to use mpl::string to implement chrono_io but I see that there are not the couterparts wstring, u16string and u32string. Without these classes I could not use the mpl strings. Is there a possibility to add these classes to Boost.Mpl? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 2