February 2011 - Boost - lists.preview.boost.org

[Serialization] Segfaults and exceptions on 32bit Linux with Boost 1.46
by Ioannis Papadopoulos 21 Mar '11

21 Mar '11

Hi, I'm having trouble using Boost.Serialization on a 32bit Linux machine. I have opened a ticket https://svn.boost.org/trac/boost/ticket/5212 Has anyone experienced anything similar? I cannot pinpoint what is the problem exactly so I can provide a patch. Thanks

1 1

[parameter] Compile-time performance
by Domagoj Saric 14 Mar '11

14 Mar '11

I have an in-house framework a part of which is very similar to Boost.Parameter so I tried to refactor it to use Boost.Parameter and, unfortunately, noticed a big compile-time hit (the project has a very large number instantiations of class templates with 'named non-type template parameters'). With my code (and MSVC++ 10) build time was ~56 seconds with a maximum cl.exe memory allocation size of ~720 MB. After switching to Boost.Parameter build time whent to ~2:24 seconds with a maximum cl.exe memory allocation size of ~815 MB. The most likely suspect is the usage of a forward-sequence for parameter type storage (argument packs) from which you fetch passed parameters using key-based lookup with the value_type<> metafunction. In my code I use an associative container (mpl::map) for the task which has a 'natural'/'efficient' key-based lookup... To confirm this I minimally changed the Boost.Parameter-based version of my code only to use mpl::maps instead of Boost.Parameter ArgumentPacks and built time fell to ~58 seconds...(true, this does not have all the compile-time check for correct usage and concept validation that ParameterSpecs and ArgumentPacks have but I'd expect this to have a much smaller effect than key-based lookup on a forward sequence)... Is there an inherent issue that forbids the use of an associative container for ArgumentPacks or can this be fixed? -- "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

3 6

[MPL] Maintenance, patch applciation etc
by Joel Falcou 10 Mar '11

10 Mar '11

As a huge user of MPL all along, i'm a bit saddened by the speed of patching/evolution of the thingy. Currently there is 36 trac item on MPL and I remember a page with a ncie list of future work to go to. Instead of bitching around, i want to propose me as a "co-maintainer" or w/e the proper term is. I have a small amount of free time i want to dedicate to this. So here is the proposal ;)

6 9

[config][clang] Does <boost/config/compiler/clang.hpp> need updating?
by Beman Dawes 09 Mar '11

09 Mar '11

http://clang.llvm.org/cxx_status.html now has a table for C++0x features. rvalue references, variadic templates, and static_asserts are showing as green. Does <boost/config/compiler/clang.hpp> need updating? Is there a maintainer for <boost/config/compiler/clang.hpp>? --Beman

6 15

D-style scope guards?
by Martin Christiansson 07 Mar '11

07 Mar '11

Hi, I have used the good old scopeguard in the past and recently done some experiments with the Boost.ScopeExit library. Still I feel that the clean scope statements in D is missing. It will not be possible to do an equally clean solution without having the same features in the language itself, but I could reach as far as this example that reuses the ScopeExit library: void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_END } The GUARDED_SCOPE_BEGIN macro declares one boolean guard to handle return from several levels of nested scopes and one boolean to guard the current scope from exceptions (will be shadowed in nested scopes). GUARDED_SCOPE_END will set the exception_thrown guard to false before that variable is used by the GUARDED_SCOPE_*() destructors. The latter is actually reused ScopeExit code with an added wrapper with a single if-statement. GUARDED_SCOPE_EXIT() will allways run on scope exit. GUARDED_SCOPE_SUCCESS() will only run if the function is exited with wrapper for return keyword (GUARDED_SCOPE_RETURN). The wrapper must be used since it updates the hidden guard variables. Using plain "return" will behave as if exception was thrown. GUARDED_SCOPE_FAILURE() will run when exception is thrown. There is also a separate GUARDED_SCOPE_NESTED_BEGIN that is supposed to be used for all nested scopes. A reference is kept to the return_called variable in the top-level-scope (variable declared by GUARDED_SCOPE_BEGIN). The biggest issue here is that any extra closing curly bracket inserted between GUARDED_SCOPE_*-definitions and GUARDED_SCOPE_END will cause destructors to run before update of guard variable. Could happen if someone thinks it "looks better" without understanding how stuff works. That kind of error will behave as if exception was thrown. Is this something to investigate further? Messy or potentially useful? Suggestions for improvements? I've appended the contents of my small test program at the end of this email. Can be tested by inserting GUARDED_SCOPE_RETURN() and "throw exception();". Regards, /Martin ----------- #include <iostream> #include <exception> #include <boost/scope_exit.hpp> using namespace std; #define GUARDED_SCOPE_BEGIN bool return_called = false; { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_NESTED_BEGIN { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_END exception_thrown = false; (void) return_called_ref; } #define GUARDED_SCOPE_RETURN(rc) { return_called_ref = true; return rc; } #define GUARDED_SCOPE_EXIT(Seq) BOOST_SCOPE_EXIT(Seq) #define GUARDED_SCOPE_EXIT_END BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_SUCCESS(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(return_called_ref || !exception_thrown) #define GUARDED_SCOPE_SUCCESS_END } BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_FAILURE(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(!return_called_ref && exception_thrown) #define GUARDED_SCOPE_FAILURE_END } BOOST_SCOPE_EXIT_END void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END do { GUARDED_SCOPE_NESTED_BEGIN GUARDED_SCOPE_FAILURE() { cout << "Inner scope: Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_SUCCESS() { cout << "Inner scope: No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_END } while(0); GUARDED_SCOPE_END } int main() { try { foo(); } catch(exception& e) { cout << "main(): Caught exception: " << e.what() << endl; return -1; } cout << "main(): No Errors occurred!" << endl; return 0; }

9 16

[type_traits] extension has_operator_xxx - cv qualifiers and references
by Frédéric Bron 06 Mar '11

06 Mar '11

New version of the type_traits extension available here: - vault unix newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - vault dos newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - sandbox: http://svn.boost.org/svn/boost/sandbox/type_traits/ This version now handles correctly cv qualifiers and references, which was not the case before. Frédéric

4 33

[1.46.1] Should we try for a point release?
by Beman Dawes 03 Mar '11

03 Mar '11

>From my viewpoint, the process of putting together a release is now smooth enough that I'm willing to do a point release, but... (1) Do we have enough fixes that will be ready by, say, a week from today to make a point release worthwhile? (2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release. (3) The C++ committee meets March 21-26 in Madrid. That means there's about three weeks, say March 14 - April 3, where those of us, including me, going to that meeting will be too tied up for Boost work. That why (1) says "a week from today". --Beman

6 9

GSoC SIMD project
by Mathias Gaunard 02 Mar '11

02 Mar '11

Joel Falcou and I have a SIMD library in the works that we plan to submit to Boost by May; we've also submitted a boostcon talk on the subject. Would it be acceptable to propose a GSoC project within Boost which could involve porting the library to new architectures, writing more tests, documentation, and examples, playing with it to implement fast vectorized functions for common tasks, etc.?

8 17

[enums] Interest in an alternative emulation of scoped enums classes
by Vicente Botet 01 Mar '11

01 Mar '11

Hi, I have been working in an alternative implementation of the Beman's Scoped enums macros (http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=new_topic…) Daniel James proposed. The macros are very similar BOOST_ENUM_CLASS_START(algae, uint8) { green, red, cyan } BOOST_ENUM_CLASS_END(algae, uint8) algae sample( algae::red ); void func(algae); The major advantages are: * No need to use a macro to name the type in most of the cases * The type is not implicitly convertible to the underlying type neither to bool and so it is closer the intended goal of strongly enums. * Allows to state explicitly the underlying type The major liabilities are: * In some context we can not use the enum class. This is the case of switch statements and template parameters. In order to get the native enum value a free function enums::get_value allows to workaround that in a portable way. algae v; ... switch (boost::enums::get_value(v)) { case algae ::green: return("EnumClass::Default"); case algae ::red: return("EnumClass::Enum1"); case algae ::cyan : } * the emulation is not an enum, that is is_enum(algae)::value is false The user can use is_enum<enum_type<EC>::type> or the library could provide an is_enum nested on the enums namespace. enums::is_enum<EC> or we can specialize boost::is_enum<EC> For template parameters the meta-function enum_type gives the type of the native enum used by the emulation. template <enums::enum_type<algae>::type V> struct ex; * Use in union The emulation providing constructors (which is optional) can not be used in unions if the compiler doesn't allows class with constructors in unions. * default value There is no portable way to manage with standard *implicit* default values if the enum class emulation can not define constructors. I have found an explicit way that allows to assign the default value. Use default_value<EC>(). This function will be equivalent to EC() if enum class is supported by the compiler. algae e(enums::default_value<algae>()); * Explicit conversion from int There is no portable way to manage with standard *explicit* conversion of ints if the enum class emulation can not define constructors. I have found an explicit way that allows to manage with explicit conversion using a function convert_to<EC>(v) instead of the Constructor. This function will be equivalent to EC(v) if enum class is supported algae e(convert_to<algae>(1)); There is not too much documentation yet. You can find the code and some test in the sandbox https://svn.boost.org/svn/boost/sandbox/enums I could provide alternative macros for users considering a better approach necessary * PP Sequence Syntax BOOST_ENUM_CLASS(EnumClass, Underlying, ( (Enum0) (0) ) ( (Enum1) ) ( (Enum2) ) ); PP Variadic Syntax BOOST_ENUM_CLASS(EnumClass, Underlying, (Enum0) (0), Enum1, Enum2 ); With the macros the meta-functions and the functions we can write portable code using strongly scoped enums. Is there any interest for this in Boost? Comments or suggestions appreciated, Vicente P.S. the convert_to function is the one of Boost.Conversion. -- View this message in context: http://boost.2283326.n4.nabble.com/enums-Interest-in-an-alternative-emulati… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[scope_exit] MSVC error C2355: 'this' : can only be referenced inside non-static member functions
by Lorenzo Caminiti 01 Mar '11

01 Mar '11

Hello all, I am trying to use Boost.ScopeExit parameter binding mechanism to implement Boost.LocalFunction. To do so, I need to use some internal ScopeExit code to detect the type of `this` and bind its value to the local function declaration. The following code works on GCC but not on MSVC... This appears to be a MSVC 2008 bug: http://connect.microsoft.com/VisualStudio/feedback/details/331418/erroneous… 1) Can anyone please try this code on MSVC versions later than 2008 to see if it was fixed? 2) Do you know of a workaround for this problem? // File: lf03.cpp #include <boost/scope_exit.hpp> struct c { void f() { typedef void (*this_t)(int this_ ); #if defined(BOOST_MSVC) // for MSVC typedef boost::type_of::msvc_typeid_wrapper< sizeof(*boost::type_of::encode_start( #else // for GCC typedef __typeof__( boost::type_of::ensure_obj( #endif boost::scope_exit::aux::wrap( boost::scope_exit::aux::deref( this, (this_t)0 ) ) ) #if defined(BOOST_MSVC) // for MSVC )>::type #else // for GCC ) #endif this_w; } }; int main() { c cc; cc.f(); return 0; } I get this error on MSVC 2008 but the code compiles just fine on GCC: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. lf03.cpp using native typeof lf03.cpp(17) : error C2355: 'this' : can only be referenced inside non-static member functions lf03.cpp(22) : error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list C:\Program Files\boost\boost_1_42\boost/typeof/msvc/typeof_impl.hpp(212) : see declaration of 'boost::type_of::msvc_typeid_wrapper' Thank you very much. -- Lorenzo

5 8