October 2012 - Boost - lists.preview.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

Interest in Base2/16/32/64 Encoding Library?
by Thomas Kemmer 27 Jan '14

27 Jan '14

Dear Boost Developers, I would like to know if there is interest in incorporating a generic Base2/16/32/64 encoding library into Boost. I am the author of such a libray, hosted at http://code.google.com/p/stlencoders/ and would be willing to contribute and make the effort of "Boostifying" it, if the Boost community is interested in such a thing. There have been several suggestions for a Base64 encoding library on this mailing list in the past. Most of them have been dismissed, since Boost already provides a Base64 implementation with Boost.Serialization's "Dataflow Iterators". Though I appreciate the dataflow iterator's design, from personal experience I think that for the basic task of encoding/decoding, a higher-level interface, e.g. one that takes padding and intermittent whitespace (MIME) into account, would benefit many developers. Currently, the stlencoders library - implements the Base16, Base32 and Base64 encoding schemes as defined in RFC 4648. Base2, i.e. binary encoding, is also supported. - implements encoding and decoding operations as generic algorithms that operate on STL-style iterators - supports different encoding alphabets using custom traits classes - supports different character types - lets the user define if/which non-alphabet characters should be ignored via predicates - provides reasonable performance that matches most "plain C" implementations stlencoders is currently designed as a stand-alone library with no dependencies on Boost (or anything but C++03); it would therefore take some effort and guidance from the community to properly integrate it with the rest of Boost. I would therefore appreciate any feedback regarding your interest in this. Kind Regards, Thomas

7 11

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 6

[scope_exit] D-style scope(failure) and scope(success) in C++
by Evgeny Panasyuk 30 Sep '13

30 Sep '13

Hello all, D language has scope(exit), scope(success) and scope(failure) features - http://dlang.org/statement.html#ScopeGuardStatement : "... scope(exit) executes NonEmptyOrScopeBlockStatement when the scope exits normally or when it exits due to exception unwinding. scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. scope(success) executes NonEmptyOrScopeBlockStatement when the scope exits normally. ..." Andrei Alexandrescu describes some of uses cases for scope(exit), scope(success), scope(failure) at his recent talk : http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Suc… There is Boost.ScopeExit library which emulates D's scope(exit) via BOOST_SCOPE_EXIT macro, but there are no analogues for D's scope(failure) and scope(success). Current alternative for these features is ScopeGuard idiom ( http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard , http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… ). Boost.ScopeExit library itself suggests to use ScopeGuard - http://www.boost.org/doc/libs/1_51_0/libs/scope_exit/doc/html/scope_exit/al… : " Boost.ScopeExit is similar to scope(exit) feature built into the D programming language. A curious reader may notice that the library does not implement scope(success) and scope(failure) of the D language. Unfortunately, these are not possible in C++ because failure or success conditions cannot be determined by calling std::uncaught_exception (see Guru of the Week #47 for details about std::uncaught_exception and if it has any good use at all). However, this is not a big problem because these two D's constructs can be expressed in terms of scope(exit) and a bool commit variable (similarly to some examples presented in the Tutorial section). " I have made small library ( https://github.com/panaseleus/stack_unwinding#d-style-scope-guardsactions ) which supplies primitives (class unwinding_indicator, UNWINDING_AWARE_DESTRUCTOR macro) to determining when object destructor is called due to stack-unwinding or due to normal scope leaving. Currently it is implemented on top of platform-specific implementation of uncaught_exception_count function and tested on: {MSVC2005, MSVC2008, MSVC2010, MSVC2012, GCC4.1.2, GCC4.4.6, Clang3.2}x{x32, x64}x{default settings}. uncaught_exception_count is a function similar to std::uncaught_exception from standard library, but instead of boolean result it returns unsigned int showing current count of uncaught exceptions. Such primitives allow us to implement scope(success) and scope(failure) features in C++. I have made several proof-of-concepts: * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_ac… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/example_… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_gu… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/boost_sc… boost_scopes.cpp example shows usage of BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS: try { cout << "Case #1: stack unwinding" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END throw 1; } catch(int){} { cout << "Case #2: normal exit" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END } Output is: " Case #1: stack unwinding failure exit Case #2: normal exit success exit " Currently BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS are implemented based on boost_1_51_0/boost/scope_exit.hpp by copy-paste and replace (just for proof-or-concept, of course it is possible solution with much less duplication). Semantically meaningful changes can be viewed as diff at https://github.com/panaseleus/stack_unwinding/commit/d5513404323490ea99d9b6… Before posting here, I made posts on several C++ forums, but unfortunately get only a few feedbacks regarding ScopeFailure and ScopeSuccess. What do you think? Thank you. P.S. Related discussion: http://lists.boost.org/Archives/boost/2010/09/171051.php Best Regards, Evgeny Panasyuk

6 27

[asio] Randomly having problems reading from the socket
by Torben Wiggerich 29 Jul '13

29 Jul '13

Hi all, I have some problems using the boost.asio.read for a TCP-socket. So far it works fine, but it randomly stops the transfer for at least 5 seconds. To resolve the error I used a simple synchronous server and client from the boost examples and modified it too send a larger amount of data. (307400 Bytes; this size comes from the program I'm trying to get run). On the client side I also changed the reading from the socket to read the complete data with boost.asio.read and transfer_all as argument. Both, server and client, measure the time for sending and reading to the socket and will give an error if it needs more than 1 second. Here is the sourcecode for the server: #include <iostream> #include <string> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main() { try { boost::asio::io_service io_service; tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); tcp::socket socket(io_service); acceptor.accept(socket); unsigned char * array = new unsigned char[307400]; for (;;) { boost::system::error_code ignored_error; ptime startTime = microsec_clock::universal_time(); boost::asio::write(socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), ignored_error); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } My client sourcecode: #include <iostream> #include <boost/array.hpp> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main(int argc, char* argv[]) { try { if (argc != 2) { std::cerr << "Usage: client <host>" << std::endl; return 1; } boost::asio::io_service io_service; boost::asio::ip::tcp::endpoint endpoint( boost::asio::ip::address::from_string( argv[1] ), 8002 ); tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; socket.connect( endpoint, error ); if (error) throw boost::system::system_error(error); int counter = 0; unsigned char* array = new unsigned char[307400]; for (;;) { boost::system::error_code error; ptime startTime = microsec_clock::universal_time(); size_t len = boost::asio::read( socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), error ); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( error ) { printf( "body read error %s\n", error.message().c_str() ); } if ( counter % 5000 == 0 ) { std::cout << "passed: " << counter << "\r"; } ++counter; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } To reproduce the error just let it run for a while. It can take up to 30 minutes or even more... After a while it will produce the line: "ERROR needed too much time: 5007ms". Maybe with slightly different times, but all around 5 seconds. I tested it on different machines with Windows Vista and Seven. So am I'm doing sth. wrong? Is the reading from the socket correct? I'm using boost version 1.44. Kind regards Torben Wiggerich

6 11

A more convenient Variant visitation syntax
by Kevin Wu Won 19 Jul '13

19 Jul '13

While Boost Variant is a wonderful library that fills a genuine hole in the C++ language, it is not as nice to use as it could be. The "correct" way to unwrap a variant is to apply a static visitor, but this method carries a high syntactic burden because it needs the user to define a class (probably somewhere far away) just so they can "switch" on the type of the object stored in the variant. I came up with a solution where the handler functions can be specified inline with C++11 lambdas. Here's an example: boost::variant< int, std::string > u("hello world"); int result = match(u, [](int i) -> int { return i; }, [](const std::string & str) -> int { return str.length(); }); The `match` function accepts the variant followed by the handler functions. The functions can be specified in any order. It will fail to compile if the functions do not match the types of the variant, if the return types are not all the same, or if a non-unary function is supplied. This is C++11 only because it's quite pointless without lambda functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, which can't handle the variadic templates. Here's the code: https://github.com/exclipy/inline_variant_visitor What do you think? This started out for me as an exercise to learn template metaprogramming and C++11, but hopefully, it can actually evolve into something useful.

7 8

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[TypeErasure] references
by Chapman, Alec 10 May '13

10 May '13

Hi Steven, I have a somewhat-generic type erasure class that I would like to switch to yours. The main difficulty I can see is in the way capturing by reference is handled. The approach I take in my class is to pass a boost::reference_wrapper to the constructor: typedef mpl::vector<copy_constructible<>, type_id_<>, incrementable<> > requirements; int i = 0; any<requirements> x(boost::ref(i)); // capture i by reference ++x; // i == 1 any<requirements> y(x); // makes a copy of i ++y; // i == 1, any_cast<int>(y) == 2 My motivation is that I have a bunch of template functions already written that I often call directly, but in other cases I need to compile them separately by instantiating them with any<...>: ---------------------- module 1 ------------------------- // some long algorithm that I don't want to modify to be aware of any<...> template<class T> void f(T& t) { ++t; T t2 = t; ++t2; // do something with t2 } // make a type-erased version for separate compilation void any_f(any<requirements>& x) { return f(x); } -------------------- module 2 ---------------------------- // provide a thin wrapper that applies type erasure before calling any_f template<class T> void f_fwd(T& t) { any<requirements> x(boost::ref(t)); any_f(x); } // some function that needs to call f void g(int& i) { // do something with i... // then pass it to f f_fwd(i); } Is something like this possible with your method? Are there advantages that I'm not seeing to having the type signature contain information about whether the object is held by reference? Thanks, Alec

3 6

What Should we do About Boost.Test?
by Dave Abrahams 16 Apr '13

16 Apr '13

Hi All, I was just going through Boost.Test to try to figure out how to teach it, and while it looks to have substantial value, it is also in quite a mess. It contains loads of features that are exercised in the examples/ directory but neither included in any of the tests nor documented. There are facilities for command-line argument parsing! There are "decorators" that turn on/off features for test cases. There is support for mock objects! These are cool and sometimes necessary features, but who knew? The third tutorial page (http://www.boost.org/doc/libs/1_51_0/libs/test/doc/html/tutorials/new-year-…) has a glaring typo in the code examples: "BOOST_AUTO_EST_CASE". There's no reference manual at all. There are nearly-identical files in the examples/ directory called "est_example1.cpp" and "test_example1.cpp" (Did the "t" key on someone's keyboard break?) I could go on, but where would I stop? I don't know what to do about this. Because of the lack of redundancy (i.e. tests and documentation), it's hard to tell whether this library is correct or even to define what "correct" should mean. It seems like, as long as the code is incompletely / incorrectly documented and tested, it's just someone's personal coding project that we happen to keep shipping with Boost, and not really a library for general use. This situation reflects poorly on Boost as a whole and the fact that it centers around a _testing_ library, which is concerned with robustness... well, let's just say that the irony isn't lost on me. I don't mean this posting as an attack on Gennadiy in any way, but I think the situation is unacceptable and therefore am opening a discussion about what should happen. As a straw man, I'll make this suggestion: - Boost.Test is officially deprecated in the next release - Its documentation, such as it is, is removed from the release after that - Meanwhile, other tests in Boost that use this library are rewritten to use a different mechanism - The code is removed from Boost thereafter I am not at all attached to removing Boost.Test from Boost, but IMO rescuing it would require a significant new investment of time and energy from people who are committed to bringing the library up to par with the rest of what we do. (I seriously thought about volunteering for this myself, but realistically speaking, I don't have the time, and volunteering for something you can't actually do is worse than not volunteering at all.) Even if volunteers show up, I'd suggest proceeding with the plan above, subject to reversal at any time the work actually gets done. Thoughts? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

34 85

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

[thread] thread_specific_ptr leaks on VS2012 when using std::async()
by Klaim - Joël Lamotte 05 Mar '13

05 Mar '13

Hi, The title says it all. I think I found a memory leak with the help of boost.log author Andrei Semashev. I was using Boost.Log in Visual Studio 2012 (released one) and tried to use Visual Leak Detector because Visual Studio basic leak detector was reporting leaks. I isolated the leaks to usage of log and switched to VLD to check if the basic detector wasn't giving me false positive. I contacted Andrei to see if he could check it but he don't have VS2012 available so I setup some tests to isolate the problem. In the end of our exchange we concluded it was a false positive (it only leak on end of program). However it is still an annoying noise in the leak report logs, so people not understanding the source of this problem might be interested in this email. I attach the whole email exchange to this email, tell me if leak logs are necessary too. The last version of my test is at the end of the email (first program). Basically, the leak appear only when using std::async() in combination of boost::thread_specific_ptr : - using exclusively boost threading libraries (both with dynamic and static linking) result in no leak - using exclusively std threading libraries but not std::async() result in no leak - using std::async() result in a leak The second test program shows that using Intel Threading Building Blocks, I get leaks only if : - I use std::async() in combination with boost::thread_specific_ptr, as before (I mean I use tbb without a leak, then I add a std::async() call to the same task function and there is a leak) - I don't use std::async() but I don't manage the lifetime of tbb task scheduler We think the threads spawned by both tbb (that is supposed to be a superset of ppl) and std::async() (that is supposed to use ppl/concrt task scheduler) are not ended yet when the program reach the end of main (which seems logical as the task scheduler is then managed as a static global), making boost::thread_specific_ptr not release some data on thread destruction, as it is notified too late and any leak detection tool willl generate noise due to this. A way to fix this is to explicitely end the task scheduler, being tbb or ppl/concrt. I will use tbb task scheduler explicitely initialized/terminated in my project so it will solve the problem on my side. Joel Lamotte ------------------------------------ // this program was used to see the memory leak #define TEST_ASYNC // comment this to make it linear and not leak //#define WITH_BOOST_THREADS #define WITH_STD_ASYNC // uncomment this to leak //#define WITH_BOOST_LOG // boost log also leak if std::async is used #include <boost/thread.hpp> #ifdef WITH_BOOST_THREADS # include <boost/thread/future.hpp> # include <boost/chrono.hpp> # define THIS_THREAD boost::this_thread # define THREAD_LIB boost::thread # define CHRONO_LIB boost::chrono # define MY_FUTURE boost::future #else # include <future> # include <thread> # include <chrono> # define THIS_THREAD std::this_thread # define THREAD_LIB std::thread # define CHRONO_LIB std::chrono # define MY_FUTURE std::future #endif #ifdef WITH_BOOST_LOG # include <boost/log/trivial.hpp> # define MY_LOG BOOST_LOG_TRIVIAL(info) #else # include <iostream> # define MY_LOG std::cout << '\n' #endif #define BASIC_VS_LEAK_DETECTOR 0 #define VISUAL_LEAK_DETECTOR 1 #define LEAK_DETECTOR VISUAL_LEAK_DETECTOR #if LEAK_DETECTOR == BASIC_VS_LEAK_DETECTOR # define _CRTDBG_MAP_ALLOC # include <stdlib.h> # include <crtdbg.h> #else # include "vld.h" #endif struct my_data { char data[1024]; my_data() { MY_LOG << "CONSTRUCTOR my_data - " << THIS_THREAD::get_id(); } ~my_data() { MY_LOG << "DESTRUCTOR my_data - " << THIS_THREAD::get_id(); } }; boost::thread_specific_ptr< my_data > ts_ptr; void my_thread_foo() { ts_ptr.reset(new my_data()); } int work() { for( int i = 0; i < 42; ++i ) { MY_LOG << "THIS IS A MESSAGE - I = " << i; MY_LOG << "ts_ptr = " << ts_ptr.get(); my_thread_foo(); THIS_THREAD::sleep_for( CHRONO_LIB::milliseconds(10) ); } return 0; } int main(int argc, char *argv[]) { #if LEAK_DETECTOR == BASIC_VS_LEAK_DETECTOR // First simple memory leak detection for Visual Studio // use _crtBreakAlloc to put a breakpoint on the provided memory leak id allocation //_crtBreakAlloc = 1149; _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); #endif //int* k = new int[42]; // to check that memory leak detection does work MY_LOG << "Hello, World!"; #ifdef TEST_ASYNC # ifndef WITH_BOOST_THREADS std::vector< std::future<int> > work_in_progress(2); # ifdef WITH_STD_ASYNC for( auto& ftr : work_in_progress ) { ftr = std::async( work ); } # else for( auto& ftr : work_in_progress ) { std::packaged_task< int() > task(work); ftr = task.get_future(); std::thread thread( std::move(task) ); thread.detach(); } # endif for( auto& ftr : work_in_progress ) { ftr.get(); } # else std::vector< boost::unique_future<int> > work_in_progress(42); for( auto& ftr : work_in_progress ) { boost::packaged_task<int> task(work); // boost's packaged_task don't take the full signature as parameter, it takes the return type only ftr = task.get_future(); boost::thread thread( boost::move(task) ); thread.detach(); } for( auto& ftr : work_in_progress ) { ftr.get(); } # endif #else for( int i = 0; i < 42; ++i ) { work(); } #endif MY_LOG << "END"; return EXIT_SUCCESS; } -------------------------------------- // this program tests if the memory leaks appear with Threading Building Blocks #define BASIC_VS_LEAK_DETECTOR 0 #define VISUAL_LEAK_DETECTOR 1 #define LEAK_DETECTOR VISUAL_LEAK_DETECTOR #define WITH_ROOT_TASK //#define WITH_BOOST_LOG //#define WITH_STD_ASYNC // uncomment to leak #ifdef WITH_STD_ASYNC # include <future> #endif #include <thread> #include <atomic> #include <boost/thread.hpp> #include <tbb/tbb.h> #include <tbb/task_scheduler_init.h> #ifdef WITH_BOOST_LOG # include <boost/log/trivial.hpp> # define MY_LOG BOOST_LOG_TRIVIAL(info) #else # include <iostream> # define MY_LOG std::cout << '\n' #endif #if LEAK_DETECTOR == BASIC_VS_LEAK_DETECTOR # define _CRTDBG_MAP_ALLOC # include <stdlib.h> # include <crtdbg.h> #else # include "vld.h" #endif namespace test { struct my_data { char data[1024]; }; boost::thread_specific_ptr< my_data > ts_ptr; void my_thread_foo() { ts_ptr.reset(new my_data()); } class UpdateTask : public tbb::task { public: UpdateTask() : idx( s_idx++ ) { MY_LOG << "[UpdateTask " << idx << " ] " << std::endl; } ~UpdateTask() { MY_LOG << "[/UpdateTask " << idx << " ]" << std::endl; } tbb::task* execute() { MY_LOG << "[" << std::this_thread::get_id() << "] Tick "<< m_count <<std::endl; my_thread_foo(); ++m_count; if( m_count < 100 ) { // make sure this is re-executed this->increment_ref_count(); this->recycle_as_safe_continuation(); } return nullptr; } private: static std::atomic<int> s_idx; std::atomic<int> m_count; const int idx; }; std::atomic<int> UpdateTask::s_idx = 0; class TaskScheduler // using TBB { public: #ifdef WITH_ROOT_TASK TaskScheduler() : m_root_task( *new (tbb::task::allocate_root()) tbb::empty_task ) { m_root_task.increment_ref_count(); } ~TaskScheduler() { m_root_task.destroy(m_root_task); } #endif void register_update_task() { #ifdef WITH_ROOT_TASK m_root_task.increment_ref_count(); UpdateTask& updater = *new(m_root_task.allocate_child()) UpdateTask(); #else UpdateTask& updater = *new(tbb::task::allocate_root()) UpdateTask(); #endif m_task_list.push_back( updater ); } void run_and_wait() { #ifdef WITH_ROOT_TASK m_root_task.spawn( m_task_list ); m_root_task.wait_for_all(); #else tbb::task::spawn_root_and_wait( m_task_list ); #endif } private: tbb::task_list m_task_list; // uncomment the following line to not leak tbb //tbb::task_scheduler_init m_engine_instance; // We explicitly create and destroy the TBB task scheduler to avoid memory leak warning noises. #ifdef WITH_ROOT_TASK tbb::task& m_root_task; #endif }; void tbb_test() { TaskScheduler task_scheduler; for( int i = 0; i < 50; ++i ) { task_scheduler.register_update_task(); } task_scheduler.run_and_wait(); } } int main(int argc, char *argv[]) { #if LEAK_DETECTOR == BASIC_VS_LEAK_DETECTOR // First simple memory leak detection for Visual Studio // use _crtBreakAlloc to put a breakpoint on the provided memory leak id allocation //_crtBreakAlloc = 148; _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); #endif #ifdef WITH_STD_ASYNC std::atomic<bool> finished = false; std::async( [&]{ while( !finished ) { MY_LOG << "POP"; test::my_thread_foo(); std::this_thread::sleep_for( std::chrono::milliseconds(500) ); } } ); #endif test::tbb_test(); #ifdef WITH_STD_ASYNC finished = true; #endif MY_LOG << "\nEND"; std::this_thread::sleep_for( std::chrono::seconds(4) ); return 0; }

3 5

[thread] boost::thread and thread safety annotations
by Wladimir 04 Mar '13

04 Mar '13

Hello, The Clang C++ compiler project is currently working on a thread safety analyzer. By making use of so-called thread safety annotations within the source code, several problems with synchronization primitives can be found statically. For example: usage of a data structure without acquiring its guarding lock. See here for an overview of the available attributes: http://clang.llvm.org/docs/LanguageExtensions.html#threadsafety It is customary to use these attributes by defining macros, for compatibility: http://www.mail-archive.com/linuxkernelnewbies@googlegroups.com/msg01455.ht… At one time, it was also supposed to end up in G++, but this was abandoned in favor of clang (see http://gcc.gnu.org/wiki/ThreadSafetyAnnotation) But at least the annotations are fairly standardized. I think it would be useful to add these annotations to boost::thread, so that projects using that library can make use of the static checking. As I understand it, is only a matter of marking data structures that serve as lock/scoped_lock (such as boost::mutex, boost::recursive_mutex, ...), and methods that act upon the lock with the appropriate attributes. Any interest in this? Regards, Wladimir

2 1

Fwd: [Thread] Solution to conflict with MFC?
by Thorsten Ottosen 28 Feb '13

28 Feb '13

Hi Thread maintainers, Anthony speaks about a patch to make this work. Does anyone know where it is? And could it be applied? Thanks -Thorsten -------- Original Meddelelse -------- Subject: [Thread] Solution to conflict with MFC? Date: Tue, 26 Apr 2011 13:28:56 +0200 From: Christian Larsen <contact(a)dword.dk> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Newsgroups: gmane.comp.lib.boost.user Hello, I know this has been asked before, but I could not find a good solution. I'm experiencing problems with an application using both MFC and Boost.Thread. Specifically the assertion ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); in AfxCoreInitModule() fails. I link Boost.Thread statically into a DLL in my project. From previous posts to this list and elsewhere, e.g. http://lists.boost.org/boost-users/2009/04/46929.php, I see that the issue is caused by setting _pRawDllMain in tss_pe.cpp. Commenting this line does "solve" the problem, but I would rather not have to hack the Boost source code this way. It seems there is a patch somewhere for this problem (referred to in http://lists.boost.org/boost-users/2009/04/47015.php) but it appears it never made it into the source. Is there any chance of this issue being solved in a better way? Best regards, Christian Larsen

5 9

[Config] N3276 decltype support on VC++ 11
by Michel Morin 28 Feb '13

28 Feb '13

IIRC, Stephan said that VC++ 11 supports N3276 decltype. Shall we "undef" BOOST_NO_CXX11_DECLTYPE_N3276 for VC++ 11? This enables automatic use of decltype-based `boost::result_of`. Trivial patch attached. Regards, Michel

11 79

[multi_index] Move Semantics
by Mark Snelling 27 Feb '13

27 Feb '13

Hi, I've been a user of Boost.MultiIndex for a number of years and think it's a great library. Is there any firm plan to add move semantics? It's been noted under "Future Work" in the docs since Boost 1.32. Regards, Mark

6 10

[Lockfree] ringbuffer
by Rich E 17 Feb '13

17 Feb '13

First off, all Boost.Lockfree tests in trunk are passing for me on clang 4.0 on OS X, hurrah! Thank you Tim for working on this for so long... I'm running through the examples now, only with the outdated documentation as a guide (more than a couple years old). I cannot find the ringbuffer container - was it renamed or removed altogether during the review period? I notice spsc_queue acts awefully like a ringbuffer, and it's implementation contains many

2 6

[fixed_point] Request for interest in a binary fixed point library
by Vicente J. Botet Escriba 02 Feb '13

02 Feb '13

Hi, the recent discussion on the MultiplePrecission Arithmetic library has show that some people has its ow fixed point library. Is there an interest in a Boost library having as base http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html? I have started a prototype http://svn.boost.org/svn/boost/sandbox/fixed_point (there is no doc yet but the basic goal is quite close to the N3352 C++ proposal). This prototype should allow you to play a little bit with. If yes, what would you like to be changed, added or improved in n3352? Next follows some design decisions that IMO need to be decided before hand. * Should integers and reals be represented by separated classes? * Should signed and unsigned be represented by separated classes? * Should the library use a specific representation for signed numbers (separated sign, 2-complement? Let the user choose? * Should the library provide arbitrary range and resolution and allocators? * Should the library be open to overflow and rounding or just implement some of the possible policies? and in this case which ones? * Should fixed_point be convertible to/from integer/float/double? * Could the result of an arithmetic operation have more range and resolution than his arguments? * Is there a need for a specific I/O? * is there a need for radix other than 2 (binary)? * Should the library implement the basic functions, or should it imperatively implement the C++11 math functions? Could a first version just forward to the c++11 math functions? * Should the library support just one of the know ways to name a fixed-point, a U(a,b), nQm, ...? Provide some ways to move from one to another? * Could expect the same/better performances respect to hand written code? * What should be the size used by a fixed_point instance? _fast? _least? Should the user be able to decide which approach is better for his needs? * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp? ... * others you can think of. Please, replay if you are interested, have some experience in the domain, good ideas, .. Best regards, Vicente

6 44

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[config] Proposed BOOST_NOEXCEPT_NOTHROW macro
by Beman Dawes 03 Jan '13

03 Jan '13

The three current BOOST_NOEXCEPT* macro variants miss the case where C++03 code has a "throw()" throw-specifier. Classes that derive from standard library exceptions need this to avoid breaking code on C++03 compilers. I'm not enamored with the BOOST_NOEXCEPT_NOTHROW name, so feel free to offer suggestions for alternate names. Here is the full set of macros: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_NOTHROW throw() <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) # define BOOST_NOEXCEPT_EXPR(Expression) false #else # define BOOST_NOEXCEPT noexcept # define BOOST_NOEXCEPT_NOTHROW noexcept <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) noexcept((Predicate)) # define BOOST_NOEXCEPT_EXPR(Expression) noexcept((Expression)) #endif Unless there are objections, I'll commit the changes Wednesday afternoon Eastern US time. --Beman

7 11

Using c++11 features in clang
by Marshall Clow 10 Dec '12

10 Dec '12

In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html I don't know if this should be a FAQ entry for Boost, or for clang. Suggestions/comments/edits welcome. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 3

Boost.Test updates in trunk: need for (mini) review?
by Gennadiy Rozenal 09 Dec '12

09 Dec '12

Hi, It's been a long while since I merged any changes into boost release and by now there are whole bunch of new features there. Some are small, but some others are big ones such that they can change the way people use the library. I'd like to list them here (excluding bug fixes and removal of deprecated interfaces) and ask what should we do with these. Specifically let me know if you think these require some kind of (mini) review from community, but any other comments are welcome as well. So here we go: I. New testing tool BOOST_CHECKA This tool is based on excellent idea from Kevlin Henney. I chose the name CHECKA for this tool due to the lack of better name, but I am open to suggestions. This testing tool capable of replacing whole bunch of existing other tools like BOOST_CHECK_EQUAL, BOOST_CHECK_GT etc. Usage is the most natural you can wish for: BOOST_CHECKA( var1 - var2 >= 12 ); And the output will include as much information as we can get: error: in "foo": check var1 - var2 >= 12 failed [23-15<12] II. New "data driven test case" subsystem New data driven test case subsystem represent a generalization of parameterized test case and test case template and eventually will replace both. The idea is to allow user to specify an arbitrary (monomorphic or polymorphic) set of samples and run a test case on each of the samples. Samples can have different arity, thus you can have test cases with multiple parameters of different types. For now we support following dataset kinds (aside of generators none of dataset constructions routines performs *any* copying): a) singleton - dataset constructed out of single sample data::make(10) - singleton dataset with integer sample data::make("qwerty") - singleton dataset with string sample b) array - dataset constructed out of C array int a[] = {1,2,3,4,5,6}; data::make(a) - dataset with 6 integer values c) collection - dataset constructed out of C++ forward iterable collection std::vector<double> v{1.2, 2.3, 3.4, 5.6 }; data::make(v) - dataset with 6 double values d) join - dataset constructed by joining 2 datasets of the same type int a[] = {1,2,3}; int b[] = {7,8,9}; data::make(a) + data::make(b) - dataset with 6 integer values e) zip - dataset constructed by zipping 2 datasets of the same size, but not necessarily the same type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd", "zxc"}; data::make(a) ^ data::make(b) dataset with 3 samples which are pairs of int and char*. f) grid - dataset constructed by "multiplying" 2 datasets of the same different sizes and types type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd"}; double c[] = {1.1, 2.2}; data::make(a) * data::make(b) * data::make(c) dataset with 12 samples which are tuples of int and char* and double. g) xrange generator dataset which produes samples in some range data::xrange( 0., 3., 0.4 ) - dataset with 8 double samples data::xrange<int>((data::begin=9, data::end=15)) - dataset with 6 int samples data::xrange( 1., 7.5 ) - dataset with 7 double samples data::xrange( 5, 0, -1 ) - dataset with 5 int samples h) random - generator dataset with unlimited number of random samples data::random(data::distribution = std::normal_distribution<>(5.,2)) dataset with random double numbers following specified distribution data::random(( data::engine = std::minstd_rand(), data::distribution = std::discrete_distribution<>(), data::seed = 20UL )); dataset with random int numbers following specified distribution While all this interfaces can be used by itself to build complex datasets with various purposes, primary use case it was developped for is new data driven test case interface: BOOST_DATA_TEST_CASE( test_name, dataset, parameter_names... ) Here are couple examples: int samples1[] = {1,2,3}; BOOST_DATA_TEST_CASE( t1, samples1, sample ) { BOOST_CHECKA( foo(sample) > 0 ); } Above test case is going to be executed 3 times with different sample values char* strs[] = {"qwe", "asd", "zxc", "mkl" }; BOOST_DATA_TEST_CASE( t1, data::xrange(4) ^ strs ^ data::random(), intval, str, dblval ) { MyObj obj( dblval, str ); BOOST_CHECKA( obj.goo() == intval ); } Above test case will be executed 4 times with different values of parameters intval, str, and dblval. Polymorphic datasets are still being developed, but should appear soon(ish). III. Auto-registered test unit decorators. Previously is was not possible and/or convenient to assign attributes to the automatically registered test units. To alleviate this I've introduced a notion of test unit decorator. These can be "attached" to any test unit similarly to like it is done in other languages Following decorators already implemented: label - adds labels to a test unit expected_failures - set expected failures for a test unit timeout - sets timeout for a test unit description - sets a test unit description depends_on - sets a test unit dependency enable_if/disable_if - facilitates a test unit status change fixture - assigns fixture to a test units Test unit description is new test unit attribute, which is reported by new list_content command line argument described below. Usage of labels covered below as well. enable_if/disable_if allow new, much more flexible test management. By adding enable_if/disable_if decorators to the test unit you can conditionally select which test units to run at construction time based on some compile time or run-time parameters. And we finally we have suite level fixtures which are set by attaching fixture decorator to a test suite (suite level fixtures executed once per test suite). Attachment of decorator is facilitated by using of BOOST_TEST_DECORATOR. Note that you can use any of '+', '-', '*' symbols to attach decorator (and any number of '*'): BOOST_TEST_DECORATOR( + unittest::fixture<suite_fixture>() ) BOOST_AUTO_TEST_SUITE( my_suite1 ) { } BOOST_TEST_DECORATOR( - unittest::timeout( 100 ) - unittest::expected_failures( 1 ) - unittest::enable_if( 100 < 50 ) ) BOOST_AUTO_TEST_CASE( my_test5 ) BOOST_TEST_DECORATOR( **** unittest::label( "L3" ) **** unittest::description( "suite description" ) **** unittest::depends_on( "my_suite2/my_test7" ) ) BOOST_AUTO_TEST_CASE( my_test11 ) IV Support for "run by label" plus more improvements for filtered runs Previously you only had an ability to filter test unit to execute by name. Now you can attach labels to test units and create collections to run which are located in arbitrary positions in test tree. For example you can have special label for performance test cases, which is attached to all test units which are responsible for testing performance of your various components. Or you might want to collect exception safety tests etc. To filter test units by level you still use --run_test CLA. Labels are dented by @prefix: test.exe --run=@performance You can now repeat --run_test argument to specify multiple conditions: test.exe --run=@performance,@exception_safety --run=prod/subsystem2 In addition run by name/label now recognizes dependencies. So if test unit A depends on test unit B and test unit B is disabled/is not part of current run test unit A will not run as well. Finally you now have an ability to specify "negative" conditions, by prefixing name or label with ! test.exe --run=!@performance This will run all test units which are not labeled with "performance". V. Support for failure context In many scenarios it is desirable to specify an additional information to a failure, but you do not need to see it if run is successful. Thus using regular print statements is undesirable. This becomes especially important when you develop common routine, which performs your testing and invoke it from multiple test units. In this case failure location is no help at all. To alleviate this problem two new tools are introduced: BOOST_TEST_INFO BOOST_TEST_CONTEXT BOOST_TEST_INFO attaches context to next assertion which is executed. For example: BOOST_TEST_INFO( "a=" << a ); BOOST_CHECKA( foo(a) == 0 ); BOOST_CHECK_CONTEXT attaches context to all assertions within a scope: BOOST_CHECK_CONTEXT( "Starting test foo from subset " << ss ) { BOOST_CHECKA( foo(ss, a) == 1 ); BOOST_CHECKA( foo(ss, b) == 2 ); } VI. Two new command line arguments: list_context, wait_for_debugger Using list_context you can see a full or partial test tree of your test module. wait_for_debugger allows to force test module to wait till you attach debugger. VII. Colored output. Using new CLA --color_output you can turn on colored output for error and information messages VIII New production testing tools interface introduced This feature was covered in details in my presentation in BoostCon 2010. The gist if this is an ability to use Boost.Test testing tools interfaces in production (nothing to do with testing) code. User supplied implementation is plugged in IX. Number of smaller improvements: * Notion of framework shutdown. Allows to eliminate some fake memory leaks * Added checkpoints at fixture entry points, test case entry point and test case exit point for auto registered test cases * New FPE portable interfaces introduced and FPE handling is separated from system errors handling. You can detect FPE even if catch_system_error is false * Added an ability to erase registered exception translator * execution_monitor: new interface vexecute - to be used to monitor nullary functions with no result values * test_tree_visitor interface extended to facilitate visitors applying the same action to all test units * execution_monitor use typeid to report "real" exception type if possible. * New ability to redirect leaks report into a file Thank you for your time, Gennadiy

21 66

[Numeric Conversion] Documentation Notes/Questions
by Dave Abrahams 25 Nov '12

25 Nov '12

* First thing to note: the documentation makes this library less approachable than it could be. In order to even begin, one has to bury onesself in terminology (the "Definitions" section). A super-quick "hello, world" example and a very short tutorial at the beginning would help a *lot*. numeric_cast is arguably the most generally-useful interface of the whole library and yet it's not even discussed until the end of the docs. * It's not clear what the purpose of abt(x) is. In expressions, "x" usually means its value. When you introduce a mechanism like this, it would be a good idea to explain why it's needed. Most places, the use of "abstract" just seems to complicate things: "A ulp is a quantity whose abstract magnitude" what's wrong with "A ulp is a quantity whose magnitude" ?? The end of the section on "Range and Precision" begins to explain why you want "abstract," but it takes the reader a long time to get to it. * are next() and prev() always well-defined? Seems to me that an unlimited precision rational number type might not have them. Is that type not numeric? * How do size, width, and density relate to unlimited precision rationals? I imagine: size = infinity width = infinity density = ? * This is slightly ambiguous: "This definition allows for a concise definition of subranged as given in the last section." "final section" would be clearer. A link would help too. * This is unclear: "Abstract intervals are easier to compare and overlap since only boundary values need to be considered." an example would help. How can one kind of thing be "easier to overlap" than another? * Precision has a very non-generic description, being different for types with density 1 and other types. It's hard to see what use such a concept has, and as far as Google can tell it is not used anywhere outside the Definitions section * Description of unsigned types, I think, is wrong: Notice that a numeric type, such as a C++ unsigned type, can define that any V does not overflow by always representing not V itself but the abstract value U = [ V % (abt(h)+1) ], which is always in range. Seems to me that the abstract values represented by an unsigned integer type are not the set of whole numbers, but the set of whole numbers modulo whatever-the-max+1-is. That's a well-defined mathematical abstraction, isn't it? Is there a problem with that, such as multiplication not working properly (I don't think so)? * There seems to be a contradiction here: If V >= abt(l) and V <= abt(h), V is representable (can be represented) in the type T ... Given an abstract value V represented in the type T as v, the roundoff error of the representation is the abstract difference: ( abt(v)-V). If V is not representable in type T, can you write formulae using its representation in type T? Given what I read later, maybe you should have just said "exactly representable" in the first phrase. * s/at most/less than/?: Because a correctly rounded representation is always one of adjacents of the abstract value being represented, the roundoff is guaranteed to be at most 1ulp. * s/cannot be represented/cannot be exactly represented/ ?: The integer number -1 can be exactly represented in Int, Real and Whole, but cannot be represented in Cardinal, yielding negative overflow. * Uh-oh: Floating to Floating conversions are defined only if N is representable; if it is not, the conversion has undefined behavior. in many places you've used "representable" to mean "exactly representable," but I can't believe you mean that here; it would imply most double=>float conversions have undefined behavior. What does this mean, anyway? If an abstract value can be "inexactly representable," aren't all abstract values representable if there's at least one abstract value that's exactly representable? Just convert to that and you're done. I think you need to give some serious thought to the definition of "representable." * s/then/so/: R(X) & R(Y) == R(X), then X->Y is not subranged. Thus, all values of type X are representable in the type Y. (b) Y->X: R(Y) & R(X) == R(Y), then Y->X is not subranged. Thus, all * What's the difference between a policy and a "parameter that defines the conversion" in It can optionally take some policies which can be used to customize its behavior. The Traits parameter is not a policy but the parameter that defines the conversion. ?? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 4

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[iterator] [property_map] Enhancement proposals
by Louis Dionne 12 Nov '12

12 Nov '12

Dear boost, First of all, let me quickly introduce myself as this is my first post here: I am a 20 years old programming enthusiast with interest for metaprogramming, functional programming and library design. I also have a strong will to contribute to open source projects since I love the philosophy behind it and it is a great way to develop new skills and to work with talented people. The object of this message is to collect feedback on several enhancement proposals I have prepared for two existing libraries: [boost.iterator] [boost.iterator.accessor_iterator] The accessor_iterator is an iterator adaptor that returns a reference to a member of its pointee when dereferenced. I see it as another step in the direction of easier iterator composition, which has helped me writting less code in the past. [boost.iterator.chained_output_iterator] The chained_output_iterator is an iterator adaptor allowing to apply a functional transformation to a value before outputing it into another output iterator. It is much like a function_output_iterator that would forward its result to another output iterator. It allows for cool stuff like creating a pipeline of operations without having to create temporary storage. [boost.property_map] [boost.property_map.accessor_property_map] The accessor_property_map is a property map returning a reference to a member of the key it is given. It is much like the accessor_iterator for property maps. [boost.property_map.chained_property_map] The chained_property_map is a tool for property map composition. It takes two property maps and uses a value in the first one as a key in the second one to perform its put, get, and operator[] operations. [boost.property_map.property_traits] I feel like the boost/property_map/property_map.hpp header is a little bit bloated and not quite as modular as it could be. For now, I propose that we move the code dealing with property_traits into the boost/property_map/property_traits.hpp header and that we provide metafunctions to check for adherence to property map types. By providing an include in the boost/property_map/property_map.hpp header, backward compatibility is maintained and we simply increase modularity. All the code is available on github: https://github.com/ldionne/boost-submissions To see how each class can be used, you may look at the unit tests for the corresponding class. If anything is accepted, I will be pleased to write documentation and examples for the concerned feature and to integrate it into the existing documentation. Looking forward to your feedback, Louis Dionne

2 11

filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion
by Andrey Upadyshev 10 Nov '12

10 Nov '12

Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564 I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing? Best regards, Andrey Upadyshev P.S. Sorry if this is wrong mailing list. Just let me know and I'll repost the message to boost-users <boost-users(a)lists.boost.org> mailing list.

2 5

Release branch closed
by Marshall Clow 08 Nov '12

08 Nov '12

Boosters, The release branch is now closed for all commits, except by explicit permission of release managers. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus Marshall Clow

4 5

[release][1.52.0] Release Notes
by Daniel James 06 Nov '12

06 Nov '12

Hello everyone, We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ The actual site won't get updated until I run the update script. You can see the release notes so far at: http://www.boost.org/users/history/version_1_52_0.html As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released. thanks, Daniel

9 22

[clang] Windows toolset support?
by Beman Dawes 06 Nov '12

06 Nov '12

Cygwin has been shipping clang for six months or so. Has anyone gotten the cygwin/clang distribution (or any other clang distribution) to build boost? What toolset did you use? What does your user-config.jam file look like? Do you run bjam/b2 from the Windows command line or the bash command line? Thanks, --Beman

7 16

[locale] [filesystem] Windows local 8 bit encoding
by Thiel, Bjoern 06 Nov '12

06 Nov '12

Hi, developing platform independent code I really like the convenience functions conv::to_utf, conv::from_utf, and conv::utf_to_utf from locale. Why not add something like conv::local8bit_to_utf and conv::local8bit_from_utf following the rational from filesystem (path encoding conversions): template < typename CharType > std::basic_string< CharType > local8bit_to_utf ( std::string const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return to_utf< CharType >( text, encoding, how ) ; } template< typename CharType > std::string local8bit_from_utf ( std::basic_string< CharType > const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return from_utf< CharType >( text, encoding, how ) ; } with char const * local8bit_encoding() { #ifdef WIN32 UINT codepage = AreFileApisANSI() ? GetACP() : GetOEMCP() ; return windows_codepage_to_encoding( codepage ) ; #else return "UTF-8" ; #endif } and with (better using a map) char const * windows_codepage_to_encoding( int const codepage ) { switch (codepage) { case 874: return "windows-874" ; case 932: return "Shift_JIS" ; // but should be "Windows-31J" ; case 936: return "GB2312" ; case 949: return "KS_C_5601-1987" ; case 950: return "Big5" ; case 1250: return "windows-1250" ; case 1251: return "windows-1251" ; case 1252: return "windows-1252" ; case 1253: return "windows-1253" ; case 1254: return "windows-1254" ; case 1255: return "windows-1255" ; case 1256: return "windows-1256" ; case 1257: return "windows-1257" ; case 1258: return "windows-1258" ; case 20127: return "US-ASCII" ; case 20866: return "KOI8-R" ; case 20932: return "EUC-JP" ; case 21866: return "KOI8-U" ; case 28591: return "ISO-8859-1" ; case 28592: return "ISO-8859-2" ; case 28593: return "ISO-8859-3" ; case 28594: return "ISO-8859-4" ; case 28595: return "ISO-8859-5" ; case 28596: return "ISO-8859-6" ; case 28597: return "ISO-8859-7" ; case 28598: return "ISO-8859-8" ; case 28599: return "ISO-8859-9" ; case 28603: return "ISO-8859-13" ; case 28605: return "ISO-8859-15" ; case 50220: return "ISO-2022-JP" ; case 50225: return "ISO-2022-KR" ; case 51949: return "EUC-KR" ; case 54936: return "GB18030" ; case 65001: return "UTF-8" ; default: { std::ostringstream message ; message << "Unknown codepage " << codepage ; throw std::invalid_argument( message.str() ) ; } } } Best regards Bjoern.

5 10

[variant] awkward recursion
by Dave Abrahams 03 Nov '12

03 Nov '12

I've been playing around with variant a bit and decided to try to build a data structure for storing json. I came up with several different approaches but none are super-satisfying. I'd like some feedback. (If you need a refresher on what's in json, the front page of http://json.org tells all). In the abstract, json looks like: struct null {}; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value; Naturally, this code isn't legal C++, so I set about making it be. The first thing I tried was to use recursive_wrapper<>, as the documentation implies it is the most flexible way to do this sort of thing. Unfortunately, there's no clean way to reformulate this type in a way that allows recursive_wrapper work, because the type that needs to be wrapped in recursive_wrapper includes "value" in its name, and I can't forward-declare it. The only way to forward-declare a type X, as far as I know, is: struct X; // or class X; So to try to get recursive_wrapper to work, I tried a couple of formulations that started with that, but it turns out that when you do this, you end up not needing recursive_wrapper at all struct value; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value_base; struct value : value_base { value() {}; template <class T> value(T const& x) : base(x) {} // no move; I'm in C++03-land value& operator=(value const& x) { base::operator=(x); return *this; } } }; I don't know if I've missed some things that should be in that "value" class. I know that a recursive variant, in principle, requires a pointer indirection somewhere, so I was wondering if, had I wrapped object and array in recursive_wrapper as below, I would have been adding an unnecessary inefficiency. typedef variant< null, std::string, double, reference_wrapper<object>, reference_wrapper<array>, bool > value_base; I also wondered whether that would give me different results from typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, std::map<std::string, reference_wrapper<value> >, std::vector<reference_wrapper<value> >, bool > value_base; and which one was better. Does anyone know? I think that should be in the docs. Using recursive_variant_ works out quite nicely, except that it doesn't allow me to separately declare "object" and "array" and re-use them in the definition of "value": typedef boost::make_recursive_variant< null , std::string , double , std::map<std::string, boost::recursive_variant_> , std::vector<boost::recursive_variant_> , bool >::type value; I also wonder if I'm getting an unnecessary inefficiency in that case. Lastly, what flexibility am I sacrificing by using this approach? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 28

[Variant] Documentation Questions/Notes
by Dave Abrahams 02 Nov '12

02 Nov '12

- What does this mean? Full value semantics, including adherence to standard overload resolution rules for conversion operations. Seems to me that it's impossible *not* to adhere to any standard rules. Is the part after the comma vacuous? - The "temporary heap backup" technique seems to have a hole: 1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup. What happens in the event of a failure in step 4? - I note the section on motivation doesn't mention the new capabilities of C++11 unions. Now some of the constructs are possible... *if* you do all the bookeeping yourself. - I note that the implementation has at least some support for move semantics and yet the docs require all elements to be "bounded types", which in turn are required to be CopyConstructible. Is that accurate, or outdated? - "completeness at the point of template instantiation" is a rather odd thing to put in a concept. I suggest that that should be just part of the requirements on the variant template rather than on BoundedType. - Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator? - it might be worth making the point that recursive variants offer the ability to define complex linked data structures *as value types* in a type- and memory-safe manner. I.e. no explicit handling of pointers; copy construction and assignment "just work," etc. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 5

[optional] Doc Nit
by Dave Abrahams 01 Nov '12

01 Nov '12

> A typical approach is to consider the existence of a > valid return value as a postcondition, so that if the > function cannot compute the value to return, it has > either undefined behavior (and can use assert in a > debug build) or uses a runtime check and throws an > exception if the postcondition is violated. This is a > reasonable choice for example, for function (A), This is possibly technically correct, but confusing. Undefined behavior results from precondition violations, not postcondition violations. I'd suggest: One approach is to make a non-negative argument a precondition, so when violated the function has undefined behavior (and can use assert in a debug build). Alternatively, one can use a runtime check and specify that an exception is thrown if the postcondition cannot be satisfied. These are a reasonable choice for example, for function (A), I'm not sure the first sentence is quite right for your needs, but I'm out of time to improve it further. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 1

C++ Now 2013 Call for Submissions
by Hartmut Kaiser 31 Oct '12

31 Oct '12

---------------------------------------------------------------------------- C++ NOW CONFERENCE 2013 - Aspen CO, USA, May 13-17, 2013, www.cppnow.org ---------------------------------------------------------------------------- CALL FOR SUBMISSIONS -------------------- We invite you to submit session proposals to the 2nd annual C++ Now Conference (Aspen CO, USA, May 13-17, 2013). Building upon the resounding success of C++ Now 2012 and five years of BoostCon, C++ Now 2013 will present leading speakers from the whole C++ community. The C++ Now Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++ Now have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. At C++ Now 2013 we would like to focus on parallel and distributed computing with C++. However, by no means this is intended to restrict the topics of proposals we hope to see. Any other topic related to C++ as outlined below is perfectly fine for submission. IMPORTANT DATES --------------- New proposal submissions due: December 15th, 2013. Proposals decisions sent (tentative program available): January 30th, 2013. Fully scheduled program available: February 24th, 2013. BEST PRESENTATION AWARDS ------------------------ We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++ Now website for that year and a plaque containing all the C++ Now conference information. SESSION TOPICS -------------- Topics of interest include, but are not restricted to, the following: * Parallelism in the new C++11 standard * Parallel, distributed and GPGPU topics relating to C++ * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standards library, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to C++ users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions Or multiples of 90-minutes. Fractional proposals will be grouped into 90 Minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS ------------------ All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2013. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++ Now website and will be available to attendees. For general information on the C++ Now 2013 paper submission or the scope of technical papers solicited; please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2013(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[chrono][ratio][boost_1_52_0_beta1] warning in user code
by Jeff Flinn 31 Oct '12

31 Oct '12

I've just downloaded boost_1_52_0_beta1 and get the warning below in my user code on VC11(I'm using thread which evidently brings in the above libs). I didn't see mention of this in trac. I'm moving forward from 1.47 and from VC8 so I'm not sure if this is an indication of some project setting[s] of mine, or if it should be corrected in the lib? Thanks, Jeff 6>D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(136): warning C4293: '<<' : shift count negative or too big, undefined behavior 6> D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(282) : see reference to class template instantiation 'boost::ratio_detail::br_mul<X,Y>' being compiled 6> with 6> [ 6> X=0x01, 6> Y=0x01 6> ] 6> D:\boost_1_52_0_beta1\boost/ratio/ratio.hpp(155) : see reference to class template instantiation 'boost::ratio_detail::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(305) : see reference to class template instantiation 'boost::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(784) : see reference to class template instantiation 'boost::chrono::detail::duration_cast<FromDuration,ToDuration>' being compiled 6> with 6> [ 6> FromDuration=boost::chrono::duration<int_least64_t,boost::ratio<0x01,0x0989680>>, 6> ToDuration=boost::chrono::milliseconds 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/ceil.hpp(27) : see reference to function template instantiation 'boost::chrono::duration<Rep,Period> boost::chrono::duration_cast<To,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,boost::ratio<N,D>> &)' being compiled 6> with 6> [ 6> Rep=int_least64_t, 6> Period=boost::milli, 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680 6> ] 6> D:\boost_1_52_0_beta1\boost/thread/win32/basic_timed_mutex.hpp(199) : see reference to function template instantiation 'To boost::chrono::ceil<boost::chrono::milliseconds,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,Period> &)' being compiled 6> with 6> [ 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680, 6> Rep=int_least64_t, 6> Period=boost::ratio<0x01,0x0989680> 6> ]

4 8

[Move] Documentation Notes/Questions
by Dave Abrahams 31 Oct '12

31 Oct '12

1. In the docs, "comes in handful" => "comes in handy" 2. IMO, it's almost irresponsible to advertise move_iterator without saying that it's really *only* safe to use when you know implementation details of the algorithm or function to which you're passing it. In particular, it must not attempt to copy from any given position in the sequence more than once. 3. Why doesn't test_move_inserter use std::copy? 4. This sentence doesn't make any sense to me; it needs clarification. I would make a suggestion, but, well, I don't understand what you're trying to say The last one has the same behaviour as std::uninitialized_copy but since several standand library implementations don't play very well with move_iterators, this version is a portable version for those willing to use move iterators. 5. The section on constructor forwarding seems to imply that constructors are the only thing that will be forwarded, when of course that's not the case. 6. These sentences don't make sense to me together. They have no obvious connection to one another. To which limitations are you referring? Fortunately, most constructors take arguments by value, by const-reference or by rvalue reference. If these limitations are accepted, the forwarding emulation of a N-argument case requires just N overloads. This library makes this emulation easy with the help of BOOST_FWD_REF and boost::forward As far as I can tell from the implementation, BOOST_FWD_REF just generates a const& in emulation mode, which isn't much of an emulation at all. 7. "David Abrahams suggested the use of class rv class": too much class :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 7

problem adding new toolset
by Pavel Heimlich, a.k.a. hajma 30 Oct '12

30 Oct '12

Hi, I'm trying to add support for building Boost on Solaris 11 with Solaris Studio and the Apache stdcxx4 library. While building it manually works well, I have problems with running the regression testsuite, it fails when trying to build process_jam_log. I'm quite lost in the Boost build system so I don't even know how to start debugging this. TIA for any hints hajma my patch: http://pastebin.com/BbuDv5PB build log: http://pastebin.com/h6wBL6ub

2 3

[serialization] how to retreive true_type from an archive ?
by nico 30 Oct '12

30 Oct '12

Hello. Context: ------- I use the boost serialization library to save and load objects of a system. I defined practices around this lib, and so I always serialize from a base class (every class serializable inherits from ISerializable). As a consequence, the true_type (i.e. the most derived type) is different from the this_type (i.e. ISerializable) and the true_type is stored in the archives. My question: ----------- How to retreive this true_type (as the string written in the archive), only from the archive object? I developp just a little bit: ---------------------------- Let's have this class tre: ISerializable <|-- B <|-- D If I do : B* b = new D(); b->SaveToFile(path); // <= this will do the serialization ar & this (this being a ISerializable*) I obtain an archive where it is written the true_type "D" (whatever the type of the archive : txt, bin or xml). With the b object and this code : const boost::serialization::extended_type_info & true_type = * boost::serialization::type_info_implementation<ISerializable>::type ::get_const_instance().get_derived_extended_type_info(*b); I have what I want in true_type.get_key(), i.e : "D". I can verify that "D" is written in every archive storing b. My question again : how, only with an archive object (construct from the archive file without error), car I retrieve this key? Tanks for any help. Nicolas.

2 3

[declval] non-ascii characters in declval.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Vicente, `utility/declval.hpp` contains a non-ascii character. I tried to fix this and make some improvements. Attached a patch that * removes a non-ascii character, * updates references to the C++11 standard, * fixes obvious oversights (e.g. `// common_type.hpp` --> `// declval.hpp`), * cleans up and reformats the comments (to the style you used in `add_rvalue_reference.hpp`), * renames the include guard macro (`BOOST_TYPE_TRAITS_EXT_...` --> `BOOST_UTILITY_`). May I commit it? Regards, Michel

2 2

[algorithm] non-ascii characters in boyer_moore.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Marshall, `boost/algorithm/searching/boyer_moore.hpp` contains a non-ascii character ("–", en dash) at line 37: 36: Explanations: boostinspect:noascii (test tool complains) 37: http://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm Would it be better to URL-encode the dash as "%E2%80%93" rather than relying on `boostinspect:noascii`? Regards, Michel

1 0

Re: [boost] [variant] awkward recursion
by Balazs Arva 29 Oct '12

29 Oct '12

At this moment I'm developing a json library with similar approach. With variant I think the only way this: typedef boost::make_recursive_variant < int, unsigned int, long, unsigned long, float, double, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; typedef std::vector<value> array; typedef std::map<std::string, value> object; I did not find any better solution. However there is still one problem: I do not want to write down every numeric POD in tmpl parameter list. It is a major problem because value a=(unsigned int)5; could not compile. Do you have any advice? I would like do something like this: typedef boost::make_recursive_variant < any_pod_numeric_type, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; Balazs Arva

1 0

Boost.Process 0.5: Minor update
by Boris Schaeling 28 Oct '12

28 Oct '12

I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - search_path() added which was called find_executable_in_path() in previous versions (Windows implementation changed quite a lot) - shell_path() added which returns the absolute path to a shell executable - set_args() added which is an initializer to pass command line arguments as a collection (with automatic escaping) - Minor bug fixes There is one more update planned to somewhat mitigate remaining cross-platform differences. Please keep the feedback coming (here on the mailing list or by email)! Boris

1 0

Interesting article on stack-based TMP
by Julien Nitard 28 Oct '12

28 Oct '12

Hi All, That article came out of reddit C++ section: http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… It looks like TMP made easy (finally !). I am not that sure it is though and was wondering if anybody had any comments on it. Regards, Julien

9 20

[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
by Matthew Chambers 27 Oct '12

27 Oct '12

I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt > (2012/10/17 0:09), Matthew Chambers wrote: >> On 10/15/2012 11:29 PM, Steven Watanabe wrote: >>> AMDG >>> >>> On 10/15/2012 07:54 PM, Kohei Takahashi wrote: >>>> Hi all, >>>> >>>> Can anyone handle following two issues? >>>> >>>> <runtime-debugging>on does nothing for libstdc++... >>>> https://svn.boost.org/trac/boost/ticket/4589 >>>> >>> >>> This is /not/ a trivial issue. It may be easy to do, but: > > I understood about this is not trivial issue and I changed the subject. > > >>> a) _GLIBCXX_DEBUG was broken last time I tried it a few years >>> ago. It won't work with all versions of gcc. >> >> I've used it with 4.1.2 and it helped a lot to track down some >> mysterious failures. > I don't know about old releases but recents seem to work well for me. > Indeed, expects to work well and should work with all versions of gcc > if define it by default. > >>> b) Anything the changes the ABI of the compiled libraries needs >>> careful consideration and must be documented. The libraries that >>> are built need to be ABI compatible with code that isn't >>> compiled using Boost.Build. >> >> Is it really that important that debug builds be ABI compatible >> between disparate builds? I think it's reasonable to EXPECT trouble >> when linking a debug build to precompiled libraries. That is >> certainly the case on Windows. > > <define> is not propagated feature, that means to trigger unexpected > link failure or ABI breaking. I think that using <runtime-debugging> > make safely rather than <define>. > I think it is better that provides propagated feature (as > <runtime-debugging> or another) for such purpose at least. > > >>> c) <runtime-debugging>on is part of <variant>debug, but I don't >>> think _GLIBCXX_DEBUG is a standard part of debug builds with >>> gcc. >> >> What is a "standard" debug build with gcc? Most people would >> probably say -g and -O0 but that doesn't provide any real debugging >> support. >> >> I agree it's not trivial, but having a no-op runtime-debugging >> feature is cringe-worthy. It's as good as admitting that GCC (or >> rather, libstdc++) doesn't provide any "official" runtime debugging >> support which is unfair. >> >> In the spirit of upcoming elections, count this as a vote for >> turning on _GLIBCXX_DEBUG. :)

5 4

Relationship of Boost libraries to TR1 and C++11
by Dave Abrahams 27 Oct '12

27 Oct '12

I don't suppose anyone has written up the specific differences between Boost libraries like regex, bind and shared_ptr and their TR1 and C++11 counterparts? It would be great if the maintainers of libraries that were accepted could add a FAQ about that. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

BoostCon old videos
by Fernando Pelliccioni 27 Oct '12

27 Oct '12

Does anyone know where I can get the videos of previous years BoostCon? In particular I am looking for the following: "Cross-platform development with Qt and Boost" http://blip.tv/boostcon/joao-p-r-abecasis-cross-platform-development-with-q… Thanks and regards, Fernando Pelliccioni.

5 5

Fwd: Re: [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 26 Oct '12

26 Oct '12

-------- Original Message -------- Subject: Re: [system] symbol visibility and GCC vs. Clang Date: Tue, 23 Oct 2012 10:40:42 -0700 From: James Walker <jamesw(a)frameforge3d.com> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org CC: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Newsgroups: gmane.comp.lib.boost.user References: <5085BABE.9030609(a)frameforge3d.com> <50868205.6070508(a)ens-lyon.org> On 10/23/2012 4:39 AM, Mathias Gaunard wrote: > On 22/10/12 23:29, James Walker wrote: >> When trying to link a bunch of libraries on OS X, I got this linker >> warning: >> >> ld: warning: direct access in >> boost::system::system_error::~system_error() to global weak symbol >> vtable for boost::system::system_error means the weak symbol cannot be >> overridden at runtime. This was likely caused by different translation >> units being compiled with different visibility settings. >> >> As far as I can tell, everything is compiled using the flags >> -fvisibility=hidden -fvisibility-inlines-hidden. >> >> I'm wondering whether the problem is that some of the libraries were >> built using gcc and some were built using Clang. In >> boost/system/system_error.hpp, the declaration of >> boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In >> boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be >> __attribute__((visibility("default"))), whereas >> boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. > > This looks like a significant bug, POSIX-style symbol visibility doesn't > work with Clang. > Please file a ticket. OK, thanks. <https://svn.boost.org/trac/boost/ticket/7559> -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 1

[thread] terminating destructor
by Andrzej Krzemienski 26 Oct '12

26 Oct '12

Hi, I can see in the release notes that in Boost 1.52 boost::thread's destructor calls terminate if joinable, in order to conform to C++11 specification. I am not sure if this is the best course of action. My understanding -- form the C++ Committee papers and informal presentations -- is that the reason for introducing a 'terminating destructor' was the lack of thread cancellation/interruption functionality. Thread interruption is supposed to be the preferred behavior for thread's destructor. std::thread does not support interruption (for some reasons), but boost::thread does (this is already a departure from C++11), so shouldn't the latter prefer to interrupt a joinable thread in the destructor? Regards, &rzej

9 41

Re: [boost] [Boost-build] another simple boost build failure
by Jürgen Hunold 25 Oct '12

25 Oct '12

Hi Ronny, On Thursday, 25. October 2012 12:55:10 you wrote: > thanks a lot. I did not know that one has to rebuild everything after > changing the requirements. It seems to work now. Good to hear that everything is up and running. > It is true, I did not read the starting guide thoroughly, I'll do that now > :-). Good, too ;-) > I am a bit confused about the library being a static library. Shouldn't it > be "boost_filesystem-vc90-mt-gds-1_50.lib" instead of > "boost_filesystem-vc90-mt-gd-1_50.lib" then? Or did I get it wrong? Ah, that is the "s" for static runtime. AFAIK the last msvc to provide a static runtime was 7.1. Don't confuse "static library" with "static runtime libraries". The static runtime opens up a new can of worms... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[Program Options] terminate parsing after first positional argument
by Evan Driscoll 25 Oct '12

25 Oct '12

This summer there was some discussion on the boost-users list about whether it is possible to use program_options to write an interface like 'xargs' (or time, or env, or nohup, or ssh, or sudo, or valgrind, or Python, or lots of other tools) where any options (--foo) that appear after the first positional arguments are considered positional arguments. In other words,'xargs foo --help' in real Unix behaves the same as 'xargs -- foo --help', rather than 'xargs --help foo', but you can't get this behavior currently from Boost. I proposed a couple patches, and there was a very small amount of discussion, but it sort of petered out (in part because I went away for a couple weeks at an inopportune time). Is there any interest in adopting them? The bug I filed just got another hit from someone else who wants it. https://svn.boost.org/trac/boost/ticket/6991 The following is a summary of the status: The ideal would be to have an 'allow_interspersed' style option which would be set by default (to give the now-usual behavior of "cmd arg --opt" being the same as "cmd --opt arg") but which a client program could unset if they wanted the xargs-like behavior. However, I don't see how to do this, because > If someone says > style_t style = allow_short | allow_slash_for_short > I can't automatically go and set allow_interspersed for them as well. And so without some ugly and not-worth-it coding tricks (changing style_t to a class), unless I'm missing something you can't pick this ideal without breaking backwards compatibility. So I instead suggested a new 'disallow_interspersed' style option, which would be off by default (keeping backwards compatibility) but you could set it to get xargs-like behavior, but this is inconsistent with all the other style flags which are allow_xxx. So what do you want to do regarding this issue? References: Trac issue: https://svn.boost.org/trac/boost/ticket/6991 (includes a patch for both of those options) The previous messages in this discussion, on boost-users: http://lists.boost.org/boost-users/2012/07/75100.php Evan

1 0

Using libc++ when compiling with clang in c++11 mode
by Marshall Clow 24 Oct '12

24 Oct '12

Has come up again: https://svn.boost.org/trac/boost/ticket/7566#comment I'm thinking that having a clang-c++11 toolset (that includes using libc++) might be a good thing. Any other opinions? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

Is there a way to specialize how a smart_ptr<T> releases the T?
by David Hagood 24 Oct '12

24 Oct '12

I am trying to wrapper around a C library (specifically, libxml2) so that I can use it within a C++ program. (yes, I am aware of libxml++ - but it doesn't play nice with libxslt). If the core libxml2 objects were internally reference counted, I could use an intrusive_ptr, and have the friend intrusive_ptr_release call libxml2's release function, and all would be well - but unfortunately libxml2 does not internally reference count the objects (at least, not in a way I have seen). If there were a way to specialize smart_ptr<T> such that instead of the destructor calling delete(), it called what I wanted, I'd be set, but I see no way to easily specialize smart_ptr<xmlDoc> in that way - or am I missing something?

8 10

Application using boost libraries (commercial)
by Dominic Amann 24 Oct '12

24 Oct '12

Application: EKKO_Project V1 R1 Company: Sensors & Software Inc, Description: EKKO_Project is the all-inclusive software solution for managing, displaying, processing and interpreting GPR data. It provides easy, highly efficient analysis and integration of GPR data. The software is optimized for Windows 7 and later operating systems. Boost Usage: filesystem, multi-array, smart pointer, date time, iterators, optional, program options, property tree, regex, test, tokenizer, type traits, uBlas. These boost libraries were used extensively in the core program functionality to make a cross-platform library that would allow a thin platform specific GUI to control all basic functionality. URL: <http://sensoft.ca/> Product page: <http://sensoft.ca/Products/Software/Details-Features.aspx#EKKOProject> Thank you, Dominic Amann Software Developer Sensors & Software Inc. 1040 Stacey Court, Mississauga ON. L4W 2X8 Toll Free: 1-800-267-6013 ext. <user ext> T: 905-624-8909 F: 905-624-9365 C: 416-270-4587 E: DAmann(a)sensoft.ca www.sensoft.ca<http://www.sensoft.ca/> subsurface imaging solutions

1 0

[atomic] unconditional cmpxchg8b support
by Tim Blechmann 23 Oct '12

23 Oct '12

hi helge & list, using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction. whatever, i wonder if it would be reasonable to enable cmpxchg8b by default on *all* ia32 platforms, not just on i686. advantage: less trouble, as we can be sure that the instruction is generated. boost.lockfree e.g. is not lockfree on ia32 without. disadvantage: the code won't work on i386 and i486 machines. imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines. thoughts? tim

7 16

In case you missed it
by Ioannis Papadopoulos 23 Oct '12

23 Oct '12

http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… A small stack machine using templates.

2 2

[preprocessor] question
by Jorge Lodos Vigil 23 Oct '12

23 Oct '12

This is regarding to BOOST_PP_IS_NULLARY macro. I would like to use it with only 2 types of inputs: 1. Empty parenthesis: () 2. Plain C++ identifier within parenthesis: (identifier) With this input restrictions, is it safe to use BOOST_PP_IS_NULLARY in portable code that must be compiled in different platforms? Thanks in advance. Jorge

2 1

[graph] strange behaviour of relax
by Jan Hudec 23 Oct '12

23 Oct '12

Hello All, Writing special variant of dijkstra's algorithm I wanted to reuse the `relax` function (from boost/graph/relax.hpp) that is used by dijkstra_shortest_paths_no_color_map. And I've notices what I think is mismatch in behaviour between relax and dijkstra_shortest_paths_no_color_map. When the graph is not oriented, the relax function will consider decreasing distance of either target (obiously) or source. However it returns the same true in both cases, so the caller does not know which vertex was updated and the dijkstra_shortest_paths_no_color_map does not expect having to update the source at all. It shouldn't happen, but than why is that condition there? It appears to me that one or the other is wrong. But I don't know the code well enough to tell which. Regards, Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Re: [boost] [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 23 Oct '12

23 Oct '12

On 22/10/12 23:29, James Walker wrote: > When trying to link a bunch of libraries on OS X, I got this linker > warning: > > ld: warning: direct access in > boost::system::system_error::~system_error() to global weak symbol > vtable for boost::system::system_error means the weak symbol cannot be > overridden at runtime. This was likely caused by different translation > units being compiled with different visibility settings. > > As far as I can tell, everything is compiled using the flags > -fvisibility=hidden -fvisibility-inlines-hidden. > > I'm wondering whether the problem is that some of the libraries were > built using gcc and some were built using Clang. In > boost/system/system_error.hpp, the declaration of > boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In > boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be > __attribute__((visibility("default"))), whereas > boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. This looks like a significant bug, POSIX-style symbol visibility doesn't work with Clang. Please file a ticket. Forwarding to developers mailing list.

1 0

[tti] documentation in trunk
by Vicente J. Botet Escriba 23 Oct '12

23 Oct '12

Hi, I would like to read the doc of Boost.TTI but there are a lot of broken link in trunK; I have tried to build the doc but I get the following error bjam warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.04.00 warning: Boost.Build core (at /Users/viboes/boost/trunk/tools/build/v2) is 2011.12-svn Building the tti docs with automatic index generation disabled. Try building with --enable-index. ...patience... don't know how to make <p../../../bin.v2/libs/tti/doc/darwin-4.2.1/debug-object(xinclude-scanner)@1283>tti.xml Could you solve this issue? BTW, when do you plan to go to the release branch? Thanks, Vicente

2 4

[graph] dijkstra_shortest_paths_no_color_map works by accident
by Jan Hudec 22 Oct '12

22 Oct '12

Hello, I've been writing custom version of Dijkstra's shortes path algorithm because of specific constraints and I was using the dijkstra_shortest_paths_no_color_map function as template. And I've notices that it only works by accident: The inner loop (I've had 1.51, but there is no change in trunk) goes like this: BGL_FORALL_OUTEDGES_T(min_vertex, current_edge, graph, Graph) { // [visitor, negative check, not interesting now] // Extract the neighboring vertex and get its distance Vertex neighbor_vertex = target(current_edge, graph); Distance neighbor_vertex_distance = get(distance_map, neighbor_vertex); bool is_neighbor_undiscovered = !distance_compare(neighbor_vertex_distance, distance_infinity); Considering the case when the vertex is not discovered: neighbor_vertex_distance = infinity is_neighbor_undiscovered = true // Attempt to relax the edge bool was_edge_relaxed = relax(current_edge, graph, weight_map, predecessor_map, distance_map, distance_weight_combine, distance_compare); Since any sensible distance is less than infinity, the relax function will return *true*: was_edge_relaxed = true if (was_edge_relaxed) { vertex_queue.update(neighbor_vertex); So this gets executed. But the vertex is not in the queue! OOPS! The code however executes successfuly. This is because the index_in_heap property map given to the d_ary_heap_indirect is initialized to 0. But 0 is correct index pointing to top and updating top is a no-op. Correct "not-in-heap" value would be -1 (and that's what the queue stores in pop()). visitor.edge_relaxed(current_edge, graph); } else { visitor.edge_not_relaxed(current_edge, graph); } if (is_neighbor_undiscovered) { visitor.discover_vertex(neighbor_vertex, graph); vertex_queue.push(neighbor_vertex); Here finally comes the push. Obviously it should have been first. Curiously this visitor callback is called before the queue operations while the edge_relaxed above is called after. Is there any reason for this particular order of operations? (Obviously fixing the code would be easier if the order of callbacks didn't matter) } } // end out edge iteration Should this be fixed? Are there any risks doing so? -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[release][chrono] Permission to disable a broken feature
by Vicente J. Botet Escriba 22 Oct '12

22 Oct '12

Hi, the version 2 of Boost/Chrono/IO introduce a bug on time_point<system_clock,D> i/o. There is an specialization for time_point i/o that I failed to test as the test was commented. When I have uncommented the test I have see that this was not really checked never. I have needed to fix a lot of things in the specific code, but I don't reach to make it work yet. As the release date is close I would prefer to disable the specialization for release 1.52 and take the time to fix the errors for the next release. I have created two tickets on Trac. https://svn.boost.org/trac/boost/ticket/7546 - time_point<system_clock> output version 2 fails to compile https://svn.boost.org/trac/boost/ticket/7547 - time_point<system_clock> input version 2 fails to compile Here you can see some of the modifications that I have since yesterday. The commit I have done today disable the feature. Of course I will need to document the limitation. They are mark as showstoppers, but as the default chrono/io version is yet version 1 the user should not be blocked. Another possibility is to disable the new chrono/io version 2 as a whole. Could I count with the permission to merge the code to disable the feature (https://svn.boost.org/trac/boost/changeset/81045) once the regression tests are run? Thanks, Vicente

2 4

[rfc] Java Binding library
by Felipe Magno de Almeida 21 Oct '12

21 Oct '12

Hello, I'm developing a Java Binding library and would like feedback so that it may in the future become a boost library. I know quite well the luabind library and from reading the documentation and tested a few toy examples the boost.python library. Though they are very high quality libraries, they have one thing in common that doesn't apply to Java: dynamic typing (Lua actually just uses tables). So just using a closed set of types for function prototypes is not enough to convey the information necessary to create the function descriptors for JNI binding, and constructing classes in Java with all Java/Lang/Object as parameters is not at all very useful. So, I thought that allowing the user to actually create classes in C++ that represents these objects in Java would make for these differentiations in function signature, and actually bind Java classes to C++. And for a few simple examples these worked well. For example (the syntax is not at all fixed yet): struct PrintStream_class : jvb::extends<PrintStream_class, FilterOutputStream_class> { PrintStream_class(jvb::environment e) : base_type(e, "java/io/PrintStream") {} }; struct PrintStream : FilterOutputStream { typedef PrintStream_class class_type; typedef jvb::method_overload <void(bool) , void(jvb::char_) , void(jvb::array<jvb::char_>) , void(jvb::double_) , void(jvb::float_) , void(jvb::int_) , void(jvb::long_) , void(jvb::object) , void(jvb::string) > print_overload; PrintStream(jvb::environment e, jobject obj) : FilterOutputStream(e, obj) , println(e, obj, "println") , print(e, obj, "print") , checkError(e, obj, "checkError") {} print_overload println; print_overload print; jvb::method<bool()> checkError; }; which could be used with the definition of System, et al, this way: int main() { jvb::jvm jvm; jvb::environment env = jvm.environment(); System_class system(env); system.out.println(env, "Hello World"); } Which is at https://github.com/felipealmeida/javabind/blob/master/demo/inheritance/inhe… The Hello World example is actually this: int main() { jvb::jvm jvm; jvb::environment env = jvm.environment(); jvb::jcl::java::lang::System::class_type System(env); System.out.println(env, "Hello World"); } This seemed fine, but it actually complicated a bit things when I start to expose classes in C++ to Java. This is the example that I'm trying to make work right now: struct hello_world { hello_world() { std::cout << "hello_world::hello_world" << std::endl; } void print() { std::cout << "hello_world::print Hello World" << std::endl; } }; int main() { jvb::jvm jvm; jvb::environment e = jvm.environment(); using namespace jvb::bind_placeholders; jvb::Class c = jvb::bind_class<hello_world> (e, "HelloWorld" , ( method(public_, "print", &hello_world::print) )); jvb::constructors<void()> constructor(e, c); jvb::Object object = jvb::new_<jvb::Object>(e, constructor); jvb::method<void()> print(e, object.raw(), "print"); print(e); } The problem here is that hello_world actually represents a 'peer class' in the JNI jargon. This peer class is instantiated by a native function and set into a member of the Java class as a long and this is then requested by other native calls (or just passed as parameter to the native function, by a helper java function) which then uses these peer classes as the native state of the Java class. But, this peer class doesn't represent its own class in Java, so, if I'm to use this Java class as parameter to some other function I can't really use this class. And for matters to be worse, jobject references, used for jvb::object, can be of various types and the most used jobject reference can't really be saved, because it would not be valid later, or if I make it valid (global reference) the it would pin the object and leak. Has this problem been dealt with in another language binding? Is it really important not to lose static information? Does another technique would fit better Any input would be greatly appreciated. If you have any examples of how the library should look like syntactically for some use-cases, that would be helpful too. I'm completely rewriting the library right now, so the source code can be a bit confusing right now, also, most things are still hardcoded for the evolution and to test how certain solutions might work together, as a proof-of-concept. The library's source code is available at https://github.com/felipealmeida/javabind. Thanks for the attention, -- Felipe Magno de Almeida

1 0

[thread] request for interest in new c++1y features
by Vicente J. Botet Escriba 21 Oct '12

21 Oct '12

Hi, I would like to include some of the new thread/future proposed features included in N3428: A Standard Programmatic Interface for Asynchronous (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3428.pdf) What do you think? Best, Vicente

3 7

[optional] warning removal
by Vicente J. Botet Escriba 21 Oct '12

21 Oct '12

Hi, can I commit this simple patch Best, Vicente svn diff ../../../boost/optional/ Index: ../../../boost/optional/optional.hpp =================================================================== --- ../../../boost/optional/optional.hpp (revision 81020) +++ ../../../boost/optional/optional.hpp (working copy) @@ -890,12 +890,12 @@ template<class T> inline -bool operator == ( none_t x, optional<T> const& y ) +bool operator == ( none_t , optional<T> const& y ) { return equal_pointees(optional<T>() ,y); } template<class T> inline -bool operator < ( none_t x, optional<T> const& y ) +bool operator < ( none_t , optional<T> const& y ) { return less_pointees(optional<T>() ,y); } template<class T>

3 3

[thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)
by Andrey Semashev 20 Oct '12

20 Oct '12

On Oct 13, 2012 12:10 AM, "Vicente J. Botet Escriba" < vicente.botet(a)wanadoo.fr> wrote: > > Le 12/10/12 21:51, Andrey Semashev a écrit : > >> On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < >> vicente.botet(a)wanadoo.fr> wrote: >>> >>> Hi, >>> Why you don't want to depend on Boost.Chrono? >> >> Because I want to minimize dependencies (especially, binary build >> dependencies). > > Me too, I want to limit dependencies :) Fair enough. Perhaps, we could absract away Boost.Thread from both libraries? Seems like a logical solution for a case like this. For example, Boost.Thread could define an internal interface for integrating with time units from different libraries. Chrono and DateTime would support this interface, and Boost.Thread could also provide the necessary glue for std::chrono integration. I think, Boost.Thread could use its own time units internally and use ADL-found functions to convert from other time units. Boost.Thread will not depend on either timing library then. Does this look viable? >> Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this >> would really be a false dependency. > > If you don't need time related thread facilities you could set BOOST_THREAD_DONT_USE_CHRONO. Would this work for you? Yes, that's what I'm doing now. I'm using DateTime units for timed functions. >> I understand that the dual interface adds more redundancy but does it >> really require active maintenance? The code has been there for quite some >> time, it's well tested and doesn't require additional work. >> >> > Any addition code has its influence on how the library could evolve. I really would prefer to remove these interfaces for Boost 1.56. I think that 1 year and a half is enough time to move to the new interface. Then I think library decoupling is the right way even more.

5 15

Boost.log: set_channel name dynamically for a basic_composite_logger
by syvyi 20 Oct '12

20 Oct '12

Hi, how to set attribute dynamically for a composite logger? lass my_logger_mt : public src::basic_composite_logger< char, my_logger_mt, src::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, src::features< src::severity< severity_levels >, src::exception_handler, src::channel< std::string > > > { BOOST_LOG_FORWARD_LOGGER_CONSTRUCTORS(my_logger_mt) }; -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-log-set-channel-name-dynamically-f… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 34

[thread] deprecating Mutex::scoped_lock and Mutex::scoped_try_lock and boost::condition
by Vicente J. Botet Escriba 20 Oct '12

20 Oct '12

Hi, I would like to deprecate the following features in Boost.Thread: * Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. * condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any. What do you think? Best, Vicente

4 9

boost::python feature request: unique_ptr, interfaces and factory functions
by Maxim Yegorushkin 20 Oct '12

20 Oct '12

Hi Boost, I am using boost::python to expose a C++ API into Python. The class I would like to export is: struct Subscriber { virtual ~Subscriber() = 0; static std::unique_ptr<Subscriber> create(); }; It's an interface with a factory function returning a std::unique_ptr<>. I would like to be able to export it in the following manner: BOOST_PYTHON_MODULE(pub_sub) { boost::python::class_< Subscriber , std::unique_ptr<Subscriber> , boost::noncopyable >("Subscriber") .def(boost::python::init<>, Subscriber::create) ; ; } I.e., the python wrapper would hold a std::unique_ptr<Subscriber> and use Subscriber::create() factory function as a constructor for Python Subscriber class. The above code doesn't compile with boost-1.51.0 for two reasons: * std::unique_ptr<> is not supported by boost::python. On the other hand, std::auto_ptr<> is. * The factory function can't be used used as a Python object constructor. I thought there could be a way to specialize certain boost::python traits/metaclasses to make it work with std::unique_ptr<> and factory functions as constructors, but couldn't figure it out. The workaround I managed to get working is: std::auto_ptr<Subscriber> createSubscriber() { return std::auto_ptr<Subscriber>(Subscriber::create().release()); } BOOST_PYTHON_MODULE(pub_sub) { // Expose the class. boost::python::class_< Subscriber , std::auto_ptr<Subscriber> , boost::noncopyable >("Subscriber_", boost::python::no_init) ; ; // Expose its factory function. boost::python::def("Subscriber", createSubscriber); } I.e., std::unique_ptr<> gets replaced with std::auto_ptr<>, the Python class is renamed to Subscriber_ and the factory function gets exported as Subscriber allowing for Python syntax: import pub_sub s = pub_sub.Subscriber() # however assert isinstance(s, pub_sub.Subscriber) # fails assert isinstance(s, pub_sub.Subscriber_) # succeeds So, I was wondering if there are ways to make my original Python class export syntax work? -- Maxim

1 0

[test] new features use c++11 features
by Jürgen Hunold 19 Oct '12

19 Oct '12

Hi Gennadiy, the new features introduced in revision 81010 and81011 use c++ features unconditionally. This breaks compilation of Boost.Test on all older compilers. Even the recent gcc-4.6 (Ubuntu 12.04). The critical places are: std::tuple std::shared_ptr std::false_type std::remove_cv those can be replaced with std::tr1:: equivalents using boost/tr1. See a quick patch attached. The usage of std::enable_if is critical, as I could not find it in boost::tr1. But this should be available as boost::enable_if and be detected by the appropriate Boost.Config macro. And at least gcc-4.6.3 ist missing the angle bracket hack, so closing ">>" template argument lists are interpreted as operator >>. Also patched. Could you please try your changes with an older compiler first? As I can not use c++11 at the moment (I'm stuck with gcc-4.2) I would like to use the new features with this older compiler. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 4

[iterator] Using zip_iterator with std::pair
by "Claas H. Köhler" 19 Oct '12

19 Oct '12

Hi! I would like to use the boost::zip_iterator with std::pair. Unfortunately this does not work out of the box, but there exists a namespace boost::detail::tuple_impl_specific, which apparently needs to be specialised for each tuple type. I managed to re-implement tuple_meta_transform and tuple_meta_accumulate for std::tuple, which seems to be straightforward. However, there are functions of the form template<typename Tuple, typename Fun> complex_result_type tuple_transform(const Tuple&, Fun) which have to be overloaded as well, if I am not mistaken. However, overloading this with something like template<typename... Args, typename Fun> complex_result_type tuple_transform(const std::tuple<Args...>&, Fun) is probably not going to work, since this would be a partial template specialisation of a function. What is the recommended way of proceeding here? Or am I making things to complicated and there exists a simpler solution to using the zip iterator with std::pair / std::tuple. Any support would be appreciated. Regards Claas P.S: I am using boost 1.50 with gcc-4.6 and the C++11 standard.

3 11

[graph] dijkstra_shortest_paths solution stability
by Jan Hudec 18 Oct '12

18 Oct '12

Hello All, I need to implement an algorithm, that uses dijkstra's algorithm as key component. However it has two additional requirements on it: 1. If for any two vertices u, v there is an edge and a path of the same length through additional vertices, the direct edge is always selected and 2. If for any two vertices u, v there is more than one shortest path, all calculates shortest path trees that include path u, v contain the same path between those vertices. Now the article that describes the algorithm uses additional property with random values to disambiguate the paths, but I am sure the following two simple rules will achieve the effect more easily: 1. When u is reached at the same distance through two vertices, v and w, the one with lower distance from start will be used in the shortest path tree. 2. When u is reached at the same distance through two vertices, v and w, that both have the same distance from start, the one that comes first in some arbitrary fixed total ordering will be used inthe shortest path tree. These rules are trivially implementable by: 1. Not updating the parent map if the new distance is not strictly less. 2. Using additional criterion in the heap comparing the vertices by index or descriptor if they have the same tentative distance. Now I suspect rule 1 is already satisfied though it's not documented. And if rule 2 is not satisfied, would it be more generally useful and worth, possibly optionally, implementing in the library? -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Fix some "unused variable" warnings
by Martin Martin 18 Oct '12

18 Oct '12

Hi, I'm using boost with clang++, with some style-related warnings turned on, and got a few warnings for unused variables. Here's the patch; are you interested in these changes? If so, is there a better way to get them to you? Thanks, Martin --- boost_1_51_0/boost/date_time/dst_rules.hpp 2008-02-27 15:00:24.000000000 -0500 +++ boost_1_51_0-fixed/boost/date_time/dst_rules.hpp 2012-10-18 09:31:08.433591299 -0400 @@ -369,11 +369,11 @@ const time_duration_type&) { return is_not_in_dst; } - static bool is_dst_boundary_day(date_type d) + static bool is_dst_boundary_day(date_type) { return false; } static time_duration_type dst_offset() diff '--unified=5' -r boost_1_51_0/boost/optional/optional.hpp boost_1_51_0-fixed/boost/optional/optional.hpp --- boost_1_51_0/boost/optional/optional.hpp 2010-12-18 16:29:39.000000000 -0500 +++ boost_1_51_0-fixed/boost/optional/optional.hpp 2012-10-18 09:31:50.737591130 -0400 @@ -888,16 +888,16 @@ // none vs optional<T> cases // template<class T> inline -bool operator == ( none_t x, optional<T> const& y ) +bool operator == ( none_t, optional<T> const& y ) { return equal_pointees(optional<T>() ,y); } template<class T> inline -bool operator < ( none_t x, optional<T> const& y ) +bool operator < ( none_t, optional<T> const& y ) { return less_pointees(optional<T>() ,y); } template<class T> inline bool operator != ( none_t x, optional<T> const& y )

2 1

[container] #7531 shadowing warnings under gcc
by Jeffrey Lee Hellrung, Jr. 18 Oct '12

18 Oct '12

Ion: I just wanted to make sure you see this. I can identify and make the necessary changes to trunk then release if you want me to. https://svn.boost.org/trac/boost/ticket/7531 Thanks, - Jeff

1 0

[graph] Efficiency of index map in dijkstra_shortest_paths
by Jan Hudec 18 Oct '12

18 Oct '12

Hello, The dijkstra_shortest_paths function requires an index map that maps vertices to index in range [0, num_vertices(g)). However there are several practially important algorithms that requite calculating shortest path trees with many times from each vertex, but each tree only spanning small fraction of an otherwise huge graph. I am somewhat concerned about allocating arrays of the size of the graph (that has millions of vertices) over and over (hundred million or more times) when many scans will stop after hundreds of vertices. Note that filtering the graph is not an option, because the stopping condition is given by radius or number of scanned vertices, but you obviously don't know which vertices will be scanned. Is there an option to use associative container for the queue indices? Or would it be useful to add it? Thanks Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 5

[pool2] Requests for comment
by DUPUIS Etienne 18 Oct '12

18 Oct '12

Greetings, I am currently working on a replacement for boost ::pool. I have a few questions regarding what would be an ideal implementation. Hopefully some members of the Boost mailing list will be able to help me answering these questions. The first question requires to look at the source code; my other questions are more general. First question : I have started by defining a pool object which manage fixed size buffers of a given object type. Documented code is found here : http://svn.boost.org/svn/boost/sandbox/pool2/boost/pool/pool.hpp. The code is short and hopefully well documented. Note that the 'ThreadSafe' template parameter is currently ignored; I have not implemented thread safety yet. My question is about the "pool growth policy". This policy defines how the pool grows when it needs to allocate more memory. This policy is given as a parameter to the pool constructor. Should this policy be a template argument instead ? Moreover, if the policy is a template argument, I could add a constant 'MaximumNumberOfTimesThePoolWillBeGrown' into the policy class. This constant would allow me to replace the std::vector() which holds allocated pointers with a static array. Is this the right solution ? Other questions : - I have defined a pool class which manage fixed sized buffers of some object T. Do we also need a pool class that can manage variable sized buffers of some object T ? - From a pool, I can implement a pool_allocator which inherits from std::allocator, exactly like it was done in the original boost::pool. Do we need something else ? Thank you for your valuable insights, Etienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

9 20

[coroutine] final version?
by Oliver Kowalke 17 Oct '12

17 Oct '12

a final (?) version of boost.coroutine is available at http://ok73.ok.funpic.de/boost-coroutine.zip In contrast to the original concept coroutine<> is not similar to a function/functor. 1.) the coroutine-fn is started at construction of coroutine<> - helps to solve some problems related to the last 'yield'-operation - similar to the behaviour of boost::thread - arguments which have to be the first arguments of coroutine-fn must be applied to coroutine<>-ctor (arguments()) 2.) coroutine<>::operator() returns a reference to the coroutine instead the return-value 3.) return-values must be accessed via coroutine<>::get() regards, Oliver

2 2

[smart_ptr] [shared_ptr] BOOST_NOEXCEPT patch
by Antony Polukhin 17 Oct '12

17 Oct '12

Hi, There is a trivial patch in ticket #7523 that marks some functions of Boost.SmartPtr library as noexcept. I'll test the patch for some more time and if there will be no objections, I'll commit it to trunk after boost_1_52_0 release. Any suggestions and comments are welcomed. -- Best regards, Antony Polukhin

1 0

[lexical_cast] cast of int8_t
by Jochen Wilhelmy 16 Oct '12

16 Oct '12

Hi! In a previous message I asked if lexical_cast could throw boost::numeric::positive_overflow when the parsing is ok but the value too large for the target type. this turned out to be difficult because it breaks existing code, alternatively there could be another exception derived from bad_lexical_cast that indicates the overflow but this seems to be a lot of work. another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char. in my code I use only char for characters and signed/unsigned char as numbers. I know that the standard stream operator << treats signed/unsigned char as char but I know no explanation for this (I consider it a bug ;-) -Jochen

5 4

[type_erasure] any and shared_ptr
by Christophe Henry 16 Oct '12

16 Oct '12

Hi Steven, I need to use the associated types but don't get them to do what I need. Consider struct Pointee : public boost::enable_shared_from_this<Pointee> { void foo() { std::cout << "Pointee::foo called" << std::endl; //shared_from_this(); std::cout << "Pointee::foo end" << std::endl; } }; Pointee needs to be enable_shared_from_this for some reason, which forces me to use it in a shared_ptr. I reused your pointee / pointer structures: template<class T> struct pointee { typedef typename mpl::eval_if< boost::type_erasure::is_placeholder<T>, mpl::identity<void>, boost::pointee<T> >::type type; }; template<class T = _self> struct pointer : mpl::vector< copy_constructible<T>, dereferenceable<deduced<pointee<T> >&, T> > { typedef deduced<pointee<T> > element_type; }; I (naively) tried to define a pointee concept: typedef mpl::vector< pointer<>, same_type<pointer<>::element_type,_a >, relaxed_match, has_foo<void()> > PointeeConcept; // will not compile, shared_ptr<Pointee> has no foo... boost::shared_ptr<Pointee> p (new Pointee) ; any<PointeeConcept> ap (p); ap.foo(); So in the end I had to resort to a wrapper: struct PointeeWrap { PointeeWrap(boost::shared_ptr<Pointee>p):myPointee(p){} void foo() { std::cout << "PointeeWrap::foo called" << std::endl; myPointee->foo(); } boost::shared_ptr<Pointee> myPointee; }; BOOST_TYPE_ERASURE_MEMBER((has_foo), foo, 0); typedef any< mpl::vector< relaxed_match, copy_constructible<>, has_foo<void()> > > AnyPointee; boost::shared_ptr<Pointee> p (new Pointee); PointeeWrap wrap(p); AnyPointee ap(wrap); ap.foo(); But this will become tedious with an increasing number of members. Is there a better way? Thanks, Christophe

2 2

[mpl] Nested BOOST_MPL_ASSERT fails on VC11
by Steven Watanabe 15 Oct '12

15 Oct '12

AMDG I just ran into the following bug: template<class T> struct test : T { BOOST_MPL_ASSERT((T)); }; BOOST_MPL_ASSERT((test<T>)); I've reworked BOOST_MPL_ASSERT to avoid the problem in the attached patch. Okay to commit? In Christ, Steven Watanabe

3 4

[GIL] default_color_converter from float to integer should clamp
by Fabien Castan 15 Oct '12

15 Oct '12

Hi, The conversion from floating point image to 8 bits or 16 bits image should clamp instead of writing arbitrary values... // a floating point image, with some pixel values < 0.0 and > 1.0 boost::gil::rgba32f_view_t HDR; // use default_color_converter to convert this HDR image to 8 bits boost::gil::png_write_view( "LDR.png", boost::gil::color_converted_view<boost::gil::rgba8_pixel_t>( HDR ) ); The 8 bits LDR image contains arbitrary cast conversion values, that are not very nice. The conversion from floating point to integer values has no other valid solution than clamping. So I suggest this patch, for the file "boost/gil/channel_algorithm.hpp": @@ -272,7 +272,13 @@ template <typename DstChannelV> struct channel_converter_unsigned<bits32f,DstChannelV> : public std::unary_function<bits32f,DstChannelV> { DstChannelV operator()(bits32f x) const { typedef typename detail::unsigned_integral_max_value< DstChannelV >::value_type dst_integer_t; - return DstChannelV( static_cast< dst_integer_t >(x*channel_traits<DstChannelV>::max_value()+0.5f )); + + const bits32f convertedValue = x * channel_traits<DstChannelV>::max_value() + 0.5f; + const bits32f clampedValue = std::min( + (bits32f)channel_traits<DstChannelV>::max_value(), + std::max( (bits32f)channel_traits<DstChannelV>::min_value(), convertedValue ) ); + + return DstChannelV( static_cast< dst_integer_t >(clampedValue) ); } }; Regards, Fabien Castan

3 2

[asio::ssl] TLS support
by ToBeKi＠gmx.de 15 Oct '12

15 Oct '12

Hello all, in asio::ssl context/context_base i couldn't find any TLS 1.1/1.2 method implementations. Is it missing/not supported yet? If so is there a roadmap supporting versions 1.1/1.2? Best, kito

1 0

[config] call to destructor of temporary
by Vicente J. Botet Escriba 15 Oct '12

15 Oct '12

Hi, I have had some trouble debugging some code with clang-2.9 c++0x. The reason was a known bug on the compiler as it doesn't call the destructor of temporaries at the end of the expression. Is there a macro stating this missing feature? Best, Vicente

4 4

maybe a bug in boost.iostreams
by leiming2006 15 Oct '12

15 Oct '12

Hello, I'm using boost 1.5.1 in windows 7 with vc 2010 express. today I'm trying using boost.iostreams with audio samples, whose char_type is not char or wchar_t. thought I failed at the end, but I guess that I found a bug in the library. In the file boost\iostreams\chain.hpp, line 136, I wonder if it's typedef linked_streambuf<Ch, Tr> streambuf_type; not typedef linked_streambuf<Ch> streambuf_type; Regards, LeiMing

1 0

[program options] Support for storage to 'optional' objects
by Chris Glover 15 Oct '12

15 Oct '12

Hi, Recently when using the Boost Program options library, I was surprised to find that I was unable to pass a boost.optional object to store supplied options in. For example; namespace bpo = boost::program_options; boost::optional<std::string> opt_str; bpo::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("opt", bpo::value(&opt_str), "Something optional") // Store value of 'opt' in 'opt_str' ; What I expected to happen would be that 'opt_str' would be valid if 'opt' is supplied by the user, and not valid otherwise. However, the above code causes a compile error deep within lexical_cast because, of course, performing such an operation on a boost.optional doesn't make sense. The attached patch to Program Options rectifies the issue by filtering out optional objects within before calling lexical_cast, but to be honest, I'm not sure if this is the correct approach or if this is even a desirable feature. I like the idea of setting an optional object this way instead of testing the variables_map later on, but perhaps there's something I am missing or a better way to accomplish the same thing. Please have a look and let me know your thoughts. Thanks, -- chris

1 0

[contract] concepts: pseudo-signatures vs. usage patterns
by Lorenzo Caminiti 14 Oct '12

14 Oct '12

On Tue, Oct 9, 2012 at 7:16 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote: >> >> I made a first attempt to sketch how N3351-like concepts will look >> into Boost.Contract (just for the find algorithm and its concepts for >> now): >> [...] >> Please tell me what you think now > > Since you asked what I think, > > "pseudo-signatures > usage patterns" Hello all, Can we write down pros and cons for concepts implemented via pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns (N3351 and Boost.Contract)? Who wants to start? Matt, Dave, Andrzej, ... I can compile a qbk table with what we discuss. Thanks. --Lorenzo

10 68

[quickbook] Cross-Referencing Source-Snippets
by Matt Calabrese 14 Oct '12

14 Oct '12

I'm currently documenting the Generic library and the documentation itself imports a lot of code from the source files directly (the best documentation for a concept generally involves showing the concept definition itself, and importing it means the code won't be out of sync with the documentation). This imported source code references other concepts and I'd like to be able to have each one of these referenced concepts be a clickable link that brings the person to the documentation for that concept (I.E. in http://generic.nfshost.com/generic/standard_concepts/concepts/equivalencere… the user should be able to click on "Predicate" in the imported source code to see the documentation for the Predicate concept). So, I tried the simplest solution -- make a quickbook macro called Predicate that results in a link to the corresponding Predicate documentation. After a quick test, everything worked fine with one exception -- the name of the section linked to is also "Predicate" and that seems to be causing the link in the generated table of contents to no longer work properly, pointing to a page that doesn't exist even though it displays the link with the proper name (note that the cross-reference links still seem to work fine, it's just the links in the table of contents that break). I realize that I'm doing something hacky here, so if anyone has a better solution, let me know. If this is the best approach, is there a way that I can keep the name of the section the same as the macro name? I.E. Is there some trick I can use to prevent the macro from being expanded when I use it in the section declaration? Keep in mind that I can't simply use templates here instead of macros because the macros are expanded from within imported, working code snippets. I also can't postpone defining the macro until after the section is declared since sections are presented in alphabetical order, meaning that an earlier section's code may reference a later section's code based on dependencies. -- -Matt Calabrese

2 2

[pointee] partially specialize for pointer types?
by Jeffrey Lee Hellrung, Jr. 14 Oct '12

14 Oct '12

Right now, boost::pointee<T*> is evaluated to T via evaluation of boost::detail::is_incrementable<T*>. Unfortunately, this causes a hard error when T is incomplete. See [1] for motivation on why this might be undesirable. It seems there's no loss in partially specializing boost::pointee for pointer types to allow it to be used for incomplete types. Ditto for boost::indirect_reference. Are there issues with this that I might be missing? As both pointee and indirect_reference seem to fall under the purview of Boost.Iterator, I would take responsibility of making this change and adding appropriate unit tests for the incomplete type case. - Jeff [1] https://svn.boost.org/trac/boost/ticket/5965

1 0

Terminology check.
by Larisse Voufo 14 Oct '12

14 Oct '12

Hello -- What would happen to be the C++ word for: name lookup + overload resolution? I would have thought it was "name resolution", but the standard seems to be suggesting otherwise. Thanks, -- Larisse.

2 1

[iterator] [documentation] need help generating
by Jeffrey Lee Hellrung, Jr. 13 Oct '12

13 Oct '12

I'm a n00b regarding Boost's documentation generation. I've gone through https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted to set up my system (Windows 7, MSVC9, try to do everything from the Windows command line). I then navigate to trunk\libs\iterator\doc and run b2 (the b2 I have from the 1.51.0 release; would that matter?). I get -------- don't know how to make <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml ...found 37 targets... ...updating 5 targets... ...can't find 1 target... ...can't make 2 targets... common.mkdir ..\..\..\bin.v2\libs\iterator\doc common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0 common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml Generating Output File: ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml quickbook\iterator.qbk:24: warning: Quickbook version undefined. Version 1.1 is assumed quickbook\concepts.qbk:159: warning: line breaks generate invalid boostbook (will only note first occurrence). quickbook\facade.qbk:491: warning: in column:6, unexpected character: ` [...lots more warnings of this nature...] quickbook\facade.qbk:612: warning: in column:52, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:44, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:12, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:15, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:46, unexpected character: ` ...skipped <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook... ...skipped 2 targets... ...updated 6 targets... -------- Then I run it again: -------- ...found 37 targets... ...updating 2 targets... xslt-xsltproc.windows ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading -multi\iterator.docbook xslt-xsltproc-dir.windows html\standalone_HTML.manifest Error: no ID for constraint linkend: indirecct. ...updated 2 targets... -------- This seems to throw everything into trunk\libs\iterator\doc\html. However, these generated html documents don't seem to be the same as those in the Boost releases. For example, the table of contents is deeper in the generated index.html than the 1.51.0 release one (which looks be identical to trunk/libs/iterator/doc/index.html), and it lacks documentation for function_input_iterator. It seems like I'm doing something wrong, and I'm not really sure what to make of the various errors and warnings I'm getting. Would anyone be kind of enough to help me out here? Oh, my user-config.jam file, located in "C:/Users/Jeffrey/", looks like -------- using xsltproc : C:/Users/Jeffrey/boost-tools/libxslt-1.1.26.win32/bin/xsltproc.exe ; using boostbook : C:/Users/Jeffrey/boost-tools/xml/docbook-xsl-1.77.1 : C:/Users/Jeffrey/boost-tools/xml/docbook-xml-4.2 ; using quickbook : %BOOST_ROOT%/dist/bin/quickbook ; -------- BOOST_ROOT refers to my Boost 1.51.0 installation, and C:/Users/Jeffrey/boost-tools/bin is part of my path. Let me know if other information is needed. TIA, - Jeff

2 3

[addressof] Intel C++ 13 Warning (Cannot be suppressed)
by Joshua Boyce 13 Oct '12

13 Oct '12

addressof.hpp causes a warning under Intel C++ 13 when using the highest warning level, which cannot be suppressed using the regular #pragma directives. This causes problems when compiling user code with warnings as errors, as the header causes an error which cannot be disabled. The root of the issue seems to be that ICC thinks that an rvalue is being passed to a function which takes a non-const ref, however in this case I think it's a false positive (ICC apparently isn't smart enough to notice and analyze the implicit conversion operator). My simple workaround is to turn the temporary into an lvalue and pass that instead. After making this change I tested under MSVC 12, GCC 4.7, ICC 13, and Clang 3.1 (all under Windows) and recorded no changes in number of failed compiles or tests. Is this an acceptable change that could be merged into trunk? Thanks.

1 1

[contract] toward N3351 concepts
by Lorenzo Caminiti 13 Oct '12

13 Oct '12

Hello all, I'm reading N3351: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf It's a bottom-up approach to define concepts starting from what's needed by STL algorithms. So far so good--I like it probably more than C++0x concept proposals--N331 is simpler :) However, N3351 STL design is not fully compatible with the current STL specifications--maybe N3351 is better, more mathematically sound? In N3351, concepts are boolean constants: ``We can define concepts as simple (constant) Boolean expressions. This is useful when building constraints predicated on non-syntactic and non-semantics properties of types.`` So I can implement concepts in C++11 as boolean meta-functions using expression SFINAE to check the requirements and enable_if to disable generic algorithms when the instantiated types don't model the concepts (i.e., the concept's boolean meta-function is false). For example, that's the case for the bool{a== b} and bool{a!=b} expressions of the EqualityComparable concept below. However, N3351 says that axioms should not be checked by the compiler... ``Axioms express the semantics of a concept’s required syntax; they are assumed to be true and must not be checked by the compiler beyond conformance to the C++ syntax. Any additional checking is beyond the scope of the compiler’s translation requirements. The compiler must not generate code that evaluates axioms as preconditions, either. This could lead to program errors if the evaluated assertions have side effects. For example, asserting that distance(first, last) > 1 when the type of those iterators is istream_iterator will consume the first element of the range, causing the assertion to pass, but the algorithm to have undefined behavior.'' So what am I supposed to do with axioms? Do nothing? Axioms are just "comments" that document the semantic? For example: `` concept EqualityComparable<typename T> = requires (T a, T b, T c) { bool { a == b }; bool { a != b }; axiom { a == b <=> eq(a, b); } // true equality axiom { a == a; // reflexive a == b => b == a; // symmetric a == b && b == c => a == c; // transitive } axiom { a != b <=> !(a == b); } // complement }; So, EqualityComparable<T> is true if T 1. has == and != with result types that can be converted to bool 2. == compares for true equality 3. == is reflexive, symmetric, and transitive 4. != is the complement of == However, the compiler can only check the first of these conditions. The rest must be verified through other means (i.e. manually). '' Thanks, --Lorenzo

16 82

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 13 Oct '12

13 Oct '12

On Sat, Mar 10, 2012 at 2:06 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: >> I can look at it once I've finished my new setup. >> >> I had to reset my computer after a partial crash years ago. I never >> got around to recreating my programming setup. My computer had been >> at its maximum Operating System level back then, which is now 3 >> versions behind. For the past few months, I've had my sister's old >> laptop, with Windows Vista, and am trying to add a programming setup >> to it now. > > Hi Daryle, > > Any updates on these two? > > https://svn.boost.org/trac/boost/ticket/3030 > https://svn.boost.org/trac/boost/ticket/5970 Mr Walker? Have you gone missing in action again? :( -- Olaf

1 0

[1.52] compile errors with xcode / apple llvm 4.1
by Jochen Wilhelmy 13 Oct '12

13 Oct '12

Hi! Had anybody success in compiling an own project that uses boost with xcode 4.5.1 / apple llvm 4.1? I get this error: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits.hpp:35: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_operator.hpp:42: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_post_decrement.hpp:34: .../boost/type_traits/detail/has_postfix_operator.hpp:143:109: error: expected expression BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); ^ .../boost/config/suffix.hpp:392:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ -Jochen

1 0

build err Boost 1.51.0 for PPC64 - is this a real error?
by david.hagood＠gmail.com 12 Oct '12

12 Oct '12

I have a reproducible error attempting to build Boost 1.51.0 for a PPC64 system: libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: junk at end of line: `@plt' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: junk at end of line: `@plt' I've seen one other person report this online, but I've seen no follow-ups. 1) Is this a known issue in 1.51.0? 2) Is there a patch? 3) Should I try the 1.52.0 Beta instead? I'd rather not spend all the time building it to find there is an issue. I have 1.51.0 for PPC32, i686, X86_64, and ARM - it's just the PPC64 that fails.

2 2

Augmented trees
by Phil Endecott 12 Oct '12

12 Oct '12

Dear Experts, I find myself in need of an augmented tree. My problem is something like [but not exactly] this: - Say I have a line of text, i.e. a sequence of characters, in a variable-width font; each character stores its width in pixels. - I need to efficiently insert and remove characters. - I need to efficiently find the range of characters that spans a given range of pixels. It seems to me that an augmented tree lets me do all of those operations in log(N) time - and no other data structure offers the same performance. I'm aware of two augmented trees that have been proposed here. Francisco Jose Tapia has proposed "Countertree", but this only stores the count of elements not the sum of a property of the elements (i.e. the widths in my example). Vadim Stadnik has proposed stl_ext_adv, which is a doubly-augmented B+ tree. Has anyone looked at Vadim's code since it was proposed last year? I have a couple of concerns about Vadim's proposal: 1. It uses B+ trees, and in the discussion it was suggested that these are inferior to red-black trees in some way. 2. In order to get the property to be accumulated (i.e. the widths in my case) it requires that arithmetic can be done on the stored type itself; this is fine for e.g. a sequence of ints, but if the stored type is a struct it is necessary to add various "unnatural" operator overloads. I think I would prefer it to have some sort of user-supplied accessor to get the property to be accumulated. Is there any other work that I've overlooked? Is there a "friendly" red-black tree implementation somewhere that could be augmented relatively easily? Regards, Phil.

8 9

[1.52.0] Beta1 release available
by Daniel James 11 Oct '12

11 Oct '12

Boost release 1.52.0 beta 1 is now available from SourceForge See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8

[thread] call_once doesn't call even once
by Kim Barrett 11 Oct '12

11 Oct '12

In boost 1.52.0 beta1 In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet: #ifdef SIG_ATOMIC_MAX typedef sig_atomic_t uintmax_atomic_t; ... #else ... #endif Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.] POSIX says "Possibly volatile-qualified integer type ...". This led to boost::call_once never calling the function, because there is a comparison in call_once (epoch<this_thread_epoch) where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type. I bet there are other places that get confused by this being an unexpectedly signed type. I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause. The relevant code is new code, introduced since boost 1.51. This is a serious regression that should be a blocker for the 1.52 release. I've filed a bug for this: https://svn.boost.org/trac/boost/ticket/7499

2 1

[coroutine] new versions
by Oliver Kowalke 11 Oct '12

11 Oct '12

I've uploaded two re-factored versions - I think most of the suggestions from the review are implemented (namespace is not corrected and documentation not updated yet). 1.) http://ok73.ok.funpic.de/boost-coroutine-self.zip 2.) http://ok73.ok.funpic.de/boost-coroutine-coro.zip Version 1) requires that coroutine-fn has only one argument == coroutine<>::self_t. Other arguments are accessed via coroutine<>::self_t::get< int >() and results via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coro_t::self_t & c) { int x = c.get< 0 >(); int y = c.get< 1 >(); c.yield( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Version 2) requires that coroutine-fn has only one argument too == coroutine<> with inverted signature. Other arguments are access via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coroutine< tuple< int, int >( int) & c) { int x = c.get().get< 0 >(); int y = c.get().get< 1 >(); c( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Both implementations are not optimized - I think we should get a small and clean interface first. Comments? regards, Oliver

5 19

[preprocessor] Variadics suggestion
by Kitten, Nicholas 11 Oct '12

11 Oct '12

Hi Folks, First of all, I'd like to say "thank you" to Edward Diener and Paul Mensonides for incorporating variadics support into Boost.Preprocessor, which has been on my wishlist for a long time. In fact, I wanted it badly enough that I've been using my own slightly modified version of the library assuming variadics for a while now, and I was interested to see what a cross-platform version would look like (mine was only tested on MSVC). I think the chosen approach of converting variadics to non-variadics is probably superior to the breaking algorithm changes I made in my own version, and I would humbly suggest a few more additions in the same spirit. The reason I chose to use variadics in the first place was to simplify the user interface for the common case of manipulating what I'll call a "variadic sequence," (a series of concatenated tuples), which I wanted to look similar to the following: #define FILTER_PARAMETERS (A, int, 3)\ (B, float, 2.0f)\ (C, const char*, "Howdy!") Of course, without variadics you need either a set of macros for each tuple size, or else double parenthesis around each tuple, which becomes even more burdensome when users are also required to parenthesize inner arguments, leading to gems like this one: #define FILTER_PARAMETERS ((A, (TypeConverter<double, float>), (TypeConverter<double,float>())) My solution admitting the preferred format was to replace most private SEQ_*(X) macros with SEQ_*(...), which also required modifying SEQ_ELEM() and SEQ_HEAD() to return (X) instead of X. However, it occurs to me now that a conversion function to go from variadic to regular sequences would've been easier to implement and backwards compatible; see the attached file, which I've tested in basic cases on MSVC 10 and gcc-4.3.4. The usage would be: #define SEQ (a,b,c)(1,2,3,4) BOOST_PP_VARIADIC_SEQ_TO_SEQ( SEQ ) // expands to ((a,b,c))((1,2,3,4)) I'm submitting this because I couldn't find a way to use some combination of TUPLE/VARIADICS and SEQ transformations to do the same thing succinctly, but if I'm just missing something, please let me know. Next, I would suggest having a documented IS_EMPTY(...) function for detecting an empty variadic list. Since is_empty.hpp already exists for single arguments (though undocumented), I would guess the variadic version would look quite similar. My own (MSVC) version is attached. Finally, I would suggest using the preceding IS_EMPTY(...) function to allow VARIADIC_SIZE(...) to return 0, i.e. something along the lines of: # define BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_IIF( BOOST_PP_IS_EMPTY(__VA_ARGS__), 0, BOOST_PP_VARIADIC_SIZE_I( __VA_ARGS__ ) ) where BOOST_PP_VARIADIC_SIZE_I is the current definition of BOOST_PP_VARIADIC_SIZE. Thanks, -Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

9 29

[GIL] interleaved_ptr as part of API?
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, I wonder, why the definitions of interleaved_ptr [1] and and interleaved_ref [2] are provided as examples, instead of included as part of the Boost.GIL API? IMO, these make useful general-purpose utility and it could be easily copied into <boost/gil/utilities.hpp>, couldn't it? Or, into official set of Boost.GIL extensions, at least. [1] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ptr.hpp [2] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ref.hpp Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[GIL] interleaved_ptr not advances correctly
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, Recently, I suggested [1] to include interleaved_ptr as part of Boost.GIL API. Unfortunately, I have been experienced problems while using interleaved_ptr. I posted Christian with a small code example and brief testing suggests interleaved_ptr does not advance correctly, what leads to images corruption. I assumed using interleaved_ptr would be a nice way to avoid reinterpret_cast when attaching raw bytes buffer into image views. Despite the cast is perfectly fine, it potentially raises red alert questions (not uncommon already, here or on StackOverflow). The simple test is to iterate over pixels and rewrite from input array (vector bitmap) to output array (vector bitmapOut) using views created in two ways: 1) cast to pixel type pointer 2) using interleaved_ptr Here are two images of what I get generated into bitmapOut array: Case 1) gives correct output http://www.flickr.com/photos/mloskot/8074130396/ Case 2) gives incorrect output http://www.flickr.com/photos/mloskot/8074130218/ Here is code [2] of the sample test: (there is no load_image() provided as it would bloat the example with too specific details) /// BEGIN /////////////////////////////////////////////////////////////////////////////////////////////////// // How to use Boost.GIL views attached to bytes array with interleaved_ptr, // versus view constructed with cast to pixel type ////////////////////////////////////////////////////////////////////////////////////////////////////// std::size_t w = 512; std::size_t h = 256; std::size_t sizeRow = 1536; // 24 bits per pixel, Windows DIB std::size_t sizeImage = sizeRow * h; std::vector<unsigned char> bitmap(sizeImage); std::vector<unsigned char> bitmapOut(sizeImage); // here bitmap is filled with data (e.g. read from file, generated in memory, etc.) // bitmap = load_image() // 1) //////////////////////////////////////////////////////////////////////////////////////////////// auto src = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t const*>(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t*>(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Simple rgb8_pixel_t to rgb8_pixel_t assignment dstIt[x] = srcIt[x]; } } assert( boost::gil::equal_pixels(src, dst) ); // 2) //////////////////////////////////////////////////////////////////////////////////////////////// typedef interleaved_ptr<unsigned char*, rgb_layout_t> rgb8_interleaved_ptr; typedef interleaved_ptr<const unsigned char*, rgb_layout_t> rgb8c_interleaved_ptr auto src = boost::gil::interleaved_view(w, h, gil::rgb8c_interleaved_ptr(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, gil::rgb8_interleaved_ptr(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Interleaved_ref points to first channel of current pixel, right? // Is this access and assignment of colour components incorrect? dstIt[x][0] = srcIt[x][0]; // R dstIt[x][1] = srcIt[x][1]; // G dstIt[x][2] = srcIt[x][2]; // B } } assert( boost::gil::equal_pixels(src, dst) ); // This assertion fails! // 1/2 to 1/3 of bitmapOut is black (pixels with value 0) /// END ////////////////////////////////////////////////////////////////////////////////////////////////////// Perhaps the access to pixels and colour components should be realised with srcIt[x * num_channels]; My e-mail is not a request for help, in fact, but a kind of bug report or warning. Because the interleaved_ptr is not part of Boost.GIL but provided as an example, I don't think it's worth a ticket on Trac. I just thought it may be worth to archive this issue in the list and make the interleaved_ptr authors and other users aware of the problem. [1] http://lists.boost.org/Archives/boost/2012/10/197199.php [2] https://gist.github.com/3866213 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Windows 8 Apps]
by Johannes Sartisohn 11 Oct '12

11 Oct '12

Hello everyone, I've searched the boost website and the mailing list archives back to january and didn't find any helpful information on my subject. My question is whether there are plans to support compiling the boost library for Windows 8 using only the WinRT APIs. That is, to support boost for Windows Store/Metro Style apps in Windows 8. Or is there already a way (e.g. via preprocessor direcitve) that I didn't find, to disable the unsupported Win32 API calls when compiling on Windows? Cheers Johannes

3 3

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[boost-python, boost-build] building "hello" boost-python tutorial sample with python 3.2 on Archlinux
by Roland Puntaier 10 Oct '12

10 Oct '12

Hello! Today I have tried boost-python tutorial with Arch Linux and Python3.2. In case somebody else tries this, here are the problems that I've encounter: - I've created ~/user-config.jam with this line using python : 3.2 : /usr/bin/python ; - the current boost-build of arch is 2.0_m12-3 This still uses "print" without "(" in boost-build/tools/python.jam The nightly build of boost-build has it corrected: local full-cmd = $(python-cmd)" -c \"from sys import *; print('"$(format:J=\\n)"' % ("$(exprs:J=,)"))\"" ; - Arch has python3.2 includes in /usr/include/python3.2mu (I wonder why!) This is not detected by b2 / bjam. I worked around this by changing boost-build/tools/python.jam: includes ?= $(prefix)/include/python$(version)mu ; - the sample jamroot file in the tutorial http://www.boost.org/doc/libs/1_51_0/libs/python/example/tutorial/Jamroot assumes a boost root folder. Since boost include and lib are separate with the arch boost installation, I've commented out "use-project". Then I had to give a direct reference to libboost_python3.so. diff -u Jamroot.org Jamroot =========================== --- Jamroot.org 2012-10-10 22:21:32.928426203 +0200 +++ Jamroot 2012-10-10 22:23:15.318762363 +0200 @@ -13,14 +13,13 @@ # Specify the path to the Boost project. If you move this project, # adjust this path to refer to the Boost root directory. -use-project boost - : ../../../.. ; +#use-project boost : ../../../.. ; # Set up the project-wide requirements that everything uses the # boost_python library from the project whose global ID is # /boost/python. project - : requirements <library>/boost/python//boost_python ; + : requirements <library>/usr/lib/libboost_python3.so ; # Declare the three extension modules. You can specify multiple # source files after the colon separated by spaces. It would be great to have comments pointing to the right solution for python 3.2 and an installed boost directly in the tutorial's sample jamroot file. - Roland

1 0

[graph] Bug in metric_tsp_approx_tour?
by Morten Strandberg 10 Oct '12

10 Oct '12

Hello, I have an application where I need to approximately solve the traveling salesman problem. I tried metric_tsp_approx_tour_from_vertex, just following the boost test code. The function works as long as the provided start vertex is zero, but given any other vertex I get rubbish back. For example, given a graph with ten vertices, the returned tour can be of length 4. I am using the following graph type: typedef adjacency_matrix<undirectedS, no_property, property<edge_weight_t, double> > Graph; and the following call: metric_tsp_approx_tour_from_vertex(graph, start_v, back_inserter(tour)); Am I doing something wrong, or is this a bug? Regards, /Morten

2 1

Gauging interest in time code for broadcasters...
by Joseph Van Riper 10 Oct '12

10 Oct '12

I'd like to know if anyone might take interest in a header library that supports working with time code (as in, 01:00:00:00 which is 107892 drop-frames, or 108000 frames at 30 fps). The library would simply convert between frames (as a long) and boost::posix_time::time_duration types according to the kind of time code, and would parse or output strings according to the kind of time code. From there, you'd just leverage boost::posix_time::time_duration for any calculations you need. I realize this is kind of a special-interest library, but the broadcasting field seems so wide that something like this might be useful to quite a few people, so I thought I'd ask. - Trey

3 7

[contract] first attempt to N3351 concepts
by Lorenzo Caminiti 10 Oct '12

10 Oct '12

Hello all, I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now): http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concep… This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues. Thanks a lot! --Lorenzo

4 9

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[1.52] error on WinCE
by Jochen Wilhelmy 10 Oct '12

10 Oct '12

Hi! on WinCE I get errors of this type: boost/smart_ptr/detail/sp_counted_base_w32.hpp(73) : error C3861: 'InterlockedIncrement': identifier not found BOOST_USE_WINDOWS_H is not defined _WIN32_WCE is 0x600 therefore there is only _InterlockedIncrement (with leading underscore) in boost/detail/interlocked.hpp -Jochen

2 1

[math] build failure with BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS
by Kim Barrett 10 Oct '12

10 Oct '12

I'm attempting to upgrade from boost 1.49 to boost 1.52 beta1, and have run into a problem building the math libraries. It seems that defining BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS no longer works, leading to build failures if it is defined. This worked in boost 1.49, where I was defining it in $BOOST_ROOT/boost/math/tools/user.hpp as described in the comments therein. I've filed a ticket for this problem: https://svn.boost.org/trac/boost/ticket/7485

2 1

[1.52] release branch reopened for bug fixes ONLY
by Eric Niebler 09 Oct '12

09 Oct '12

Now that we have released the first beta, the release branch is open for bug fixes. Only bug fixes, please.[*] No new features. No new libraries. You do not need a release manager's approval to merge a bug fix. The earlier you can merge your bug fixes, the better. The branch will close again for final release preparations on Oct 29. As usual, you can see the release calendar here: http://www.boost.org/development/index.html [*] Changes to documentation are always allowed. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[config] Handle upcoming XP-target toolset of VC11
by Lars Viklund 09 Oct '12

09 Oct '12

Hi list. Microsoft are testing their update system for Visual Studio 2012 [1], which includes a v110_xp toolset [2] for "restoring" support for building software that may run on Windows XP. In essence, it uses a repurposed Windows 7 SDK with the VS 2012 compiler, instead of the Windows 8 SDK used in the normal v110 toolset. What implications do you think this has for Boost.Config and all the things predicated on MSC_VER, as this decorrelates the compiler version from the Windows SDK it uses. Has anyone installed these pre-release bits and given it a shot? (I've mailed boost-build@ about the Boost.Build implications.) [1] http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/08/visual-studio-20… [2] http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx -- Lars Viklund | zao(a)acc.umu.se

3 2

[GIL] Small docs update suggestion on cached_location_t
by Mateusz Loskot 09 Oct '12

09 Oct '12

Hi, I've stumbled upon old thread on "locator and cached_location_t" [1] There are some interesting explanations which I believe is worth to add to Boost.GIL docs. Particularly, I believe the following Lubomir's clarification should be added as first paragraph documenting cached location: "Cached location is meant to be used as a quick way to get to neighborhood pixels if you need to read or write a neighboring location frequently relative to a given locator." Currently, notion of cached location is documented in the GIL design guide [1] but it makes users to deduce answer to "What the cached locator is for?". BTW, I wanted to provide patch, but I'm not sure where this update should be put or if I should submit a ticket. [1] http://lists.boost.org/Archives/boost/2010/12/174157.php [2] http://www.boost.org/doc/libs/1_51_0/libs/gil/doc/html/gildesignguide.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

[graph] msvc compile failure with filtered_graph and dijkstra
by Jürgen Hunold 09 Oct '12

09 Oct '12

Hi, some of our old graph algorithm seems to have broken using msvc with 1.51. The failure can be reproduced with the attached testcase on trunk and 1.51. The error starts with E:\Home\hunold\src\devel\boost\boost/graph/properties.hpp(222) : error C2039: 'type' : is not a member of 'boost::vertex_property_type<G>' which point in the direction of the last changes to properties.hpp. The test code break with msvc-9.0 (full error included) and msvc-11.0. Everything compiles with gcc-4.6.2 on Kubuntu 12.04 and mingw-w64. Any ideas what msvc does not grok here? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 5

[contract] concept error messages
by Lorenzo Caminiti 09 Oct '12

09 Oct '12

Hello all, Main purposes of concepts are to (a) document the type requirements and (b) generate useful error messages when a type does not met the requirements. I'd like to discuss how the ideal error messages should look like when a given type does not model the specified concepts. One point of discussion is: In case a type doesn't model a concept, should the compiler generate an hard error or the function/class template should simply be removed from the overload/specialization set? For example, consider: template< typename T> requires EqualityComparable<T> bool equal ( T a, T b ) // #1 { return a == b; // #3 } ... struct x { explicit x(char const*); }; x abc("abc"); equal(abc, abc); // #2 Let's assume we want an hard error then I think ideally the compiler should generate two errors: 1) An error at line #1 indicating that the concept EqualityComparable<T> is not modeled. Ideally this error will read: line #1: failed to model concept EqualityComparable<T> 2) An error at line #2 indicating that the call equal(abc, abc) cannot be resolved. Ideally this error will read: line #2: no matching call for function equal 3) Note that no error should be generated from within the equal function implementation (line #3, etc) because the concept is not modeled so the function definition should not be compiled. Now, this is what I was able to actually implement. === Option A) Using enable_if === template< typename T > typename std::enable_if< AlwaysTrue<T>::value && contract::std::EqualityComparable<T>::value, bool>::type equal1 ( T const& a, T const& b ) { return a == b; } ... equal1(abc, abc); // 08.cpp:44 08.cpp:44:5: error: no matching function for call to 'equal1' equal1(abc, abc); ^~~~~~ [...] This error is not ideal because it only satisfies 2) and 3) but not 1). It does not give information about which concept was not modeled -- you don't see EqualityComparable or "concept failed" anywhere in the error. (Clang actually mentions EqualityComparable in a "note" following the error (see below) but that's not a message that can be relied on across different compilers.) Users can use this approach if they don't want an hard error but they only want to remove the function from the overload set on concept failure. === Option B) Using concept_check === template< typename T > typename contract::concept_check< AlwaysTrue<T>::value, contract::std::EqualityComparable<T>::value, bool>::type equal2 ( T const& a, T const& b ) { return a == b; } ... equal2(abc, abc); // 08.cpp:45 In file included from 08.cpp:5: include/contract/concept_check.hpp:61:5: error: static_assert failed "model concept number 2" static_assert(Concept2, "model concept number 2"); ^ ~~~~~~~~ [...] 08.cpp:45:5: error: no matching function for call to 'equal2' equal2(abc, abc); ^~~~~~ This also satisfies 2) and 3) however it only partially satisfies 1). The error mentions the number of the concept "2" but not its name EqualityComparable (that's probably OK) but the error line number refers to the file implementing concept_check and not to the point of declaration of equal2. In other words, the error for 1) does not indicate line #1 (that's probably acceptable but not ideal). Note that the error for 1) is generate using a static_assert so it is portable. === Option C) Using CONCEPT_CHECK macro === CONTRACT_CONCEPT_CHECK( // 08.cpp:26 (template< typename T >), (AlwaysTrue<T>) (contract::std::EqualityComparable<T>), bool, equal3 ) ( T const& a, T const& b ) { return a == b; } ... equal3(abc, abc); // 08.cpp:45 08.cpp:26:1: error: static_assert failed "model concept number 2: contract::std::EqualityComparable<T>" CONTRACT_CONCEPT_CHECK( ^~~~~~~~~~~~~~~~~~~~~~~ [...] 08.cpp:46:5: error: no matching function for call to 'equal3' equal3(abc, abc); ^~~~~~ [...] These errors satisfy all 1), 2), and 3) however the use of macros makes clang generate lots of "notes" to backtrace the macro expansion (there's probably a way to disable these notes, plus they are not actual errors and can be ignored). Note that the concept name EqualityComparable appears in the static assertion error message so it is guaranteed to be printed portably among compilers. I'm thinking that these are all valid ways to check concepts. Eventually, Boost.Contract macros will use B) (given that the lib already uses macros to declare functions). However, if users want to use Boost.Contract macros to declare a concept but they want to use enable_if or contract::concept_check to check it, they can do so (in case they don't want to use the lib macros to declare their functions). Complete error messages (including "notes"): 08.cpp:44:5: error: no matching function for call to 'equal1' equal1(abc, abc); ^~~~~~ 08.cpp:12:5: note: candidate template ignored: disabled by 'enable_if' [with T = x] AlwaysTrue<T>::value && contract::std::EqualityComparable<T>::value, ^ In file included from 08.cpp:5: include/contract/concept_check.hpp:61:5: error: static_assert failed "model concept number 2" static_assert(Concept2, "model concept number 2"); ^ ~~~~~~~~ 08.cpp:19:20: note: in instantiation of template class 'contract::concept_check<true, false, bool>' requested here typename contract::concept_check< ^ 08.cpp:21:13: note: while substituting deduced template arguments into function template 'equal2' [with T = x] bool>::type equal2 ( T const& a, T const& b ) ^ 08.cpp:45:5: error: no matching function for call to 'equal2' equal2(abc, abc); ^~~~~~ 08.cpp:21:13: note: candidate template ignored: substitution failure [with T = x] bool>::type equal2 ( T const& a, T const& b ) ^ 08.cpp:26:1: error: static_assert failed "model concept number 2: contract::std::EqualityComparable<T>" CONTRACT_CONCEPT_CHECK( ^~~~~~~~~~~~~~~~~~~~~~~ include/contract/concept_check.hpp:40:33: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' BOOST_PP_SEQ_FOR_EACH_I(CONTRACT_CONCEPT_CHECK_ASSERT_, ~, concepts) \ ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:27:69: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I' # define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_FOR((macro, data, seq (nil), 0), BOOST_PP_SEQ_FOR_EACH_I_P, BOOST_PP_SEQ_FOR_EACH_I_O, BOOST_PP_SEQ_FOR_EACH_I_M) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/repetition/detail/for.hpp:22:78: note: expanded from macro 'BOOST_PP_FOR_1' # define BOOST_PP_FOR_1(s, p, o, m) BOOST_PP_FOR_1_C(BOOST_PP_BOOL(p(2, s)), s, p, o, m) ^ note: (skipping 7 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:45:80: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_M_IM' # define BOOST_PP_SEQ_FOR_EACH_I_M_IM(r, im) BOOST_PP_SEQ_FOR_EACH_I_M_I(r, im) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/for_each_i.hpp:50:62: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_M_I' # define BOOST_PP_SEQ_FOR_EACH_I_M_I(r, macro, data, seq, i) macro(r, data, i, BOOST_PP_SEQ_HEAD(seq)) ^ include/contract/concept_check.hpp:23:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK_ASSERT_' static_assert(CONTRACT_CONCEPT_CHECK_COND_(i), "model concept number " \ ^ 08.cpp:26:1: note: in instantiation of template class 'contractXconceptXcheckXequal3X30<true, false>' requested here CONTRACT_CONCEPT_CHECK( ^ include/contract/concept_check.hpp:50:14: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' typename CONTRACT_CONCEPT_CHECK_CLASS_(func_name)< \ ^ include/contract/concept_check.hpp:11:23: note: expanded from macro 'CONTRACT_CONCEPT_CHECK_CLASS_' BOOST_PP_SEQ_CAT((contractXconceptXcheckX)(func_name)(X)(__LINE__)) ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/cat.hpp:30:7: note: expanded from macro 'BOOST_PP_SEQ_CAT' )(seq) \ ^ note: (skipping 18 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ../../../boost_1_50_0.cyg/boost/preprocessor/seq/cat.hpp:35:37: note: expanded from macro 'BOOST_PP_SEQ_CAT_O_I' # define BOOST_PP_SEQ_CAT_O_I(a, b) a ## b ^ <scratch space>:91:1: note: expanded from macro 'contractXconceptXcheckXequal3X' contractXconceptXcheckXequal3X30 ^ ../../../boost_1_50_0.cyg/boost/preprocessor/seq/fold_left.hpp:295:51: note: expanded from macro 'BOOST_PP_SEQ_FOLD_LEFT_F' # define BOOST_PP_SEQ_FOLD_LEFT_F(op, st, ss, sz) st ^ 08.cpp:29:11: note: while substituting deduced template arguments into function template 'equal3' [with T = x] bool, equal3 ^ include/contract/concept_check.hpp:53:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' func_name ^ 08.cpp:46:5: error: no matching function for call to 'equal3' equal3(abc, abc); ^~~~~~ 08.cpp:29:11: note: candidate template ignored: substitution failure [with T = x] bool, equal3 ^ include/contract/concept_check.hpp:53:5: note: expanded from macro 'CONTRACT_CONCEPT_CHECK' func_name ^ 5 errors generated. --Lorenzo

5 20

[result_of] BOOST_RESULT_OF_USE_DECLTYPE in a C++03 mode with libc++
by Michel Morin 08 Oct '12

08 Oct '12

This is just a small note related to boost::result_of. When BOOST_RESULT_OF_USE_DECLTYPE is defined, boost::result_of tries to use decltype-based implementation (regardless of the compiler's decltype support). Surprisingly, in a C++03 mode, libc++ defines `decltype` using `__typeof__`: Bug 12488 (WONTFIX): decltype can be used in C++03 with no errors, no warnings http://llvm.org/bugs/show_bug.cgi?id=12488 So, when used with libc++, boost::result_of can be used with BOOST_RESULT_OF_USE_DECLTYPE even in a C++03 mode. Regards, Michel

2 3

[config] libs not supporting std::u16string and std::u32string.
by Vicente J. Botet Escriba 08 Oct '12

08 Oct '12

Hi, compiling Boost.Ratio/io Boost.Chrono/io with compilers supporting |char16_t and |char32_t fails if the library don't provides std::u16string and std::u32string. Could we add a macro |BOOST_NO_CXX11_HDR_STRING||| (c++11 is not completely provided) or the two more specific |||BOOST_NO_CXX11_U16STRING||| and |||BOOST_NO_CXX11_U32STRING||| for these cases? Best, Vicente || ||

4 7

Is Boost Broken?
by Robert Ramey 08 Oct '12

08 Oct '12

At Boost Con 2010 I made a presentation in which I suggested changes in boost to permit it to continue to prosper. This presentation was titled: "Is Boost Broken?" Here's the video link - but it doesn't seem to work any more http://blip.tv/boostcon/robert-ramey-is-boost-broken-4166775 And the slides http://www.rrsd.com/software_development/boost/BoostCon2010/boost_con_2010.… And a thread of the discussion in the aftermath. http://boost.2283326.n4.nabble.com/quot-Is-Boost-Broken-quot-post-script-td… The response was encouraging but sorry to say that note much concrete has come of it ... until now. I've implemented most of these ideas as a website - Boost Library Incubator - www.blincubator.com which is intended to help library authors and provide a place where libraries can be developed prior to the review process. This touches on just about all of Boost workflow and initiatives in one way or another. This includes Modularization, Documentation standards and preperation, Testing and Test Reporting, Deployment. Probably the main underlying ideas here are: a) Decoupling and Modularization of libraries in general and boost in particular. b) Workflow to improve code quality b) leverage on "free" tools, technologies, and facilities to get most bang for the buck. As a "teaser", I've included a new library "safe numerics" which addresses a long running sore in the C language. It's a serious proposal for a library, but my main interest is to have a prototype to develope the next concept. I'm very much tempted to comment on the current state of development of web technologies - the that would take me waaaay of topic and we'll leavel that for another time. Looking forward to feedback from boost enthusiasts. Robert Ramey

3 3

[type_traits] common_type and SFINAE
by Lorenzo Caminiti 08 Oct '12

08 Oct '12

Hello all, common_type<T, U>::type is defined in a way that gives a hard compiler error if T and U do not have a common type (this is also how common_type is implemented in C++11). An alternative design (I'm not sure if implementable) would have been to not define the type member in case T and U have no common type. This way I could use SFINAE to detect if common_type<T, U>::type does not exist and therefore if T and U have not common type -- so to implement N3351's concept Common<T, U>. Is there a way to implement this alternative design? Thanks. --Lorenzo

8 22

[graph] kick out or replace transitive_reduction()?
by Johannes Lorenz 08 Oct '12

08 Oct '12

Hi, shall the transitive_reduction function (transitive_reduction.hpp) of boost_graph ever be used? I ask because * I can find no docs about it * It is unhandy to use, since the nodes are permuted (in opposite to transitive_closure(), which offers a version with *constant* permutation) * I've found bugs in the header, which were stated to be bugs by the original author (asked him via email) If this function should not be used, I'd write a very simple one, using the formula from [1]. Note that this will only work for DAGs, but that's better than nothing. What do you think? Regards, Johannes [1] http://en.wikipedia.org/wiki/Transitive_reduction#Graph_algorithms_for_tran…

1 0

[1.52.0] Beta release candidates available
by Marshall Clow 08 Oct '12

08 Oct '12

Release candidate files for 1.52.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 61a852c923c7e27d84fd2e6336d787f2 *boost_1_52_0_beta1_rc1.tar.gz 956fb476326ee634225c683612493fdd *boost_1_52_0_beta1_rc1.tar.bz2 703663eca3122152031c5555e26845c0 *boost_1_52_0_beta1_rc1.zip b277b6f36ead9df9a0754c868956f30c *boost_1_52_0_beta1_rc1.7z Thanks, --The release managers

5 6

[TTI] library now status?
by osyo manga 07 Oct '12

07 Oct '12

Hi. What is the state of Boost.TTI ? I seem to have not changed for more than one year in boost-svn. Thanks.

2 1

[exception] boost::throw_exception vs deriving from boost::exception
by John Salmon 07 Oct '12

07 Oct '12

I'd like to use Boost.Exception's error_info capabilities in an existing code base. It seems to me that I have two choices: 1 - find all the 'throw my_except(...)' in the code base and replace them with boost::throw_exception(my_except(...)). 2 - find all the struct my_except{...} definitions in the current code base and replace them with: struct my_except: virtual boost::exception {...} I find #2 more appealing for the following practical reasons: - there are fewer locations to change. Exceptions are defined less often and in fewer places than they are used. - there is less to remember. Developers who write new throw expressions need to remember nothing. Developers who define new exceptions must remember to derive them from boost::exception, but this is much less common. Are there reasons I should prefer boost::throw_exception instead? I can only think of one: boost::throw_exception also adds N2179 support via enable_current_exception. This isn't a current concern, but our compilers (gcc and clang) already support N2179 directly, so we can use std::current_exception rather than boost::current_exception if the need arises. Are there other reasons to prefer boost::throw_exception? Thanks John Salmon

3 2

[Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE
by Michel Morin 07 Oct '12

07 Oct '12

First, thanks Eric for fixing incompatibility between Phoenix and decltype-based result_of. This is really a great fix! I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1 The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support? P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it? Regards, Michel

2 4

[lexical_cast] exception type for overflow
by Jochen Wilhelmy 06 Oct '12

06 Oct '12

Hi! i would expect that lexical_cast<uint16_t>("65536") and numeric_cast<uint16_t>(lexical_cast<int>("65536")) would throw the same exception boost::numeric::positive_overflow. but lexical_cast throws a bad_lexical_cast. is it possible to change lexical_cast so that it also throws positive_overflow if the error comes from the overflow and not from the lexical parsing? -Jochen

3 2

[countertree] Formal Review Request
by Francisco José Tapia 05 Oct '12

05 Oct '12

Hi all, I would like to request a formal review of the library “Countertree + Suballocator” [countertree] Project location ( zip file with code and documentation) : https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip Quick view of documentation with code download : https://dl.dropbox.com/u/8437476/works/countertree/index.html For the people who don't know this project, this is a description : *COUNTERTREE* This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . Based on this tree we have : - With unordered information we have vectors (countertree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. - With ordered information, we have in the countertree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) *SUBALLOCATOR* In the allocation of equal size elements ( as in STL list, set, multiset,map and multimap), when the number of elements grows, many allocators begin to have speed problems. For to improve the speed, many allocators request to the Operating System big chucks of memory ( pool allocators). With this, the allocator don't need request memory to the operating system for each allocation. But many allocators don't return well the unused chucks of memory to the Operating System and the memory used by the allocator is the maximum used, never decrease . The *suballocator is a solution to these problems*, and others memory problems described in the suballocator page. The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator request memory to the allocator, and return to it when unused. The suballocator replace to the allocator in the allocation of equal size elements With the suballocator a) *We have a very fast allocation* *(around 2 times faster than the std::allocator of GCC 4.7, CLANG 3.0 and 3 times than Visual Studio 10 *See details in the *Suballocator Benchmark*)* b) *Return the suballocator return memory to the allocator, this can use in the allocation of others types of data or for return to the *Operating System, decreasing the memory used by the program, *( as you can see in the *Suballocator Benchmark *)* c) *You can use with any allocator if it is according with the STL definition*. The suballocator provides speed and memory management to any allocator. d) Even the time of the allocation is a small part of the time spent in the insertion in a std::set, the suballocator obtain time reductions over over the 30% respect the std::allocator. The secret is the cache performance due to the data locality improvement. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace countertree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance for big number of elements It is fast, useful and easy to understand and use,. They are the like the STL classes with a few additional functions. This library is designed thinking in programmers with a basic knowledge of C++. As I say in the documentation, if you know the STL classes vector, set , multiset, map , multimap and allocator, you know more than 95% needed for to use this library. I showed the library to several friends and colleagues, and one of them said me “If your potential users are not experts, and they need more than 5 minutes to understand what's the goal of the library and what they can do with it, many of them leave the page.... , and the library”. The first page of the documentation explain the library, the reasons and what can do. And in the next pages show the details and how can do in a a easy way. I had checked this code with GCC 4.7 , CLANG/LLVM 3.0 and Visual C++ 10 ( all with 32 and 64bits.). In code of the project is composed by the code of the classes, the test programs, the benchmarks programs used and mentioned in the documentation, and several examples of the code I had checked all the requirements for to request the review. But I am not sure if all is OK. If you miss something or something is wrong , please , mail me and I will correct as soon as possible Sincerely yours Francisco Tapia fjtapia(a)gmail.com

4 9

[graph][heap][coroutine] interruptable dijkstra shortest path function
by Alex Hagen-Zanker 05 Oct '12

05 Oct '12

[apologies for double posting, send it to wrong list before] Hi, A few months ago I posted here to gauge interest for an interruptable and resumable version of the dijkstra_shortest_path algorithm. The initial response was positive, but Jeremiah considered the proposed solution lacking compared to an algorithm object model that inverts the control over the algorithm, Additional to my original solution, I now have two implementations of the algorithm object model. 1. Visitor based interruption. This is my original approach. It separates the algorithm into an init and main function. The main function asks the visitor if it should be halted afer each iteration. After halting, the main function can be used to resume the calculation. auto dijkstra = make_dijkstra_object(graph, named_parameters); dijkstra.init_from_sources(sources); dijkstra.expand( interruptor); dijkstra.expand( other_interruptor); auto distance_map = dijkstra.get<vertex_distance_t>(); auto color_map = dijkstra.get<vertex_color_t>(); 2. Algorithm object implementation. This was suggested by Jeremiah. The algorithm object iterates from control point to control point in the algorithm. Giving at each stop access to the intermediate results of the algorithm. The two implementations are: a) Using the [Coroutine] library that is currently under review to step in and out of the function. b) Fragmenting the function into many subfunctions that are chained together and the other works by fragmenting the original algorithm into a number of small interlinked functions starting at one control point and returning at the next. The interface of a and b is exactly the same and it works like this: auto dijkstra = make_dijkstra_object(graph, sources, named_parameters); while(dijkstra.next() ) { control_point cp = dijkstra.get_control_point(); vertex u = dijkstra.get_u(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(cp == cp_finish_vertex && get(distance_map, u) > 42) { cout << "far enough" << endl; break; } } auto distance_map = dijkstra.get<vertex_distance_t>(); The algorithm object offers most flexibility for interweaving multiple searches. The visitor based solution on the other hand is more efficient. The latter has no loss in performance compared to the existing dijkstra functions. The coroutine algorithm object was extremely easy to implement but it is not very efficient. Does anybody have a suggestion how that can improve? Besides these interruptable and resumable shortest path searches, there are a few more advantages to the implementation. a. All dijkstra parameters are bundled in a light-weight dijkstra_state object that is returned by algorithms, giving direct access to all results of the algorithm, for instance: auto dijkstra_state = dijkstra_shortest_paths(graph, sources, no_named_parameters() ); auto distance_map = dijkstra_state.get<vertex_distance_t>(); b. Named parameters (old style) are also used for the priority queue and the color map c. Boost.Heap mutable queues can be used with Boost.Graph via the named parameter interface. It doesn't help performance now, but may be a good base for experimentation. d. Separation of the dijkstra shortest path algorithm in init and main function makes it easier to provide custom initialization. For instance: multiple sources or only re-initializing changed vertices Can anybody use this? The latest version is here: http://people.pwf.cam.ac.uk/ahh34/dijkstra.zip Kind regards, Alex p.s. below are timings for a large graph: bimba_6M.obj... 2090 ms. Boost Graph Library 2121 ms. With interruption visitor 5601 ms. With Coroutine(*) 2621 ms. With fragmented functions (*) 2840 ms. With Boost.Heap (*) halting at all control points of the dijkstra visitor

8 21

[chrono] bad use of constexpr (was: [1.52.0] Beta release candidates available)
by Eric Niebler 05 Oct '12

05 Oct '12

On 10/5/2012 8:56 AM, Lemay.Steve wrote: > Here's the first problem that pops up for me... QNXNTO gcc 4.7.1 > > qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o > In file included from ./boost/chrono/chrono.hpp:11:0, > from ./boost/chrono/detail/inlined/chrono.hpp:13, > from libs\chrono\src\chrono.cpp:14: > ./boost/chrono/duration.hpp: In static member function 'static constexpr float boost::chrono::detail::chrono_numeric_limits<float, true>::lowest()': > ./boost/chrono/duration.hpp:355:56: error: call to non-constexpr function 'static std::numeric_limits<float>::_Ty std::numeric_limits<float>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr double boost::chrono::detail::chrono_numeric_limits<double, true>::lowest()': > ./boost/chrono/duration.hpp:363:57: error: call to non-constexpr function 'static std::numeric_limits<double>::_Ty std::numeric_limits<double>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr long double boost::chrono::detail::chrono_numeric_limits<long double, true>::lowest()': > ./boost/chrono/duration.hpp:371:61: error: call to non-constexpr function 'static std::numeric_limits<long double>::_Ty std::numeric_limits<long double>::max()' > cc: d:/qnxsdk/qnxsdk6.5-001/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.7.1/cc1plus caught signal 1 > > "QCC" -Wc,-ftemplate-depth-128 -DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x -O3 -Wc,-finline-functions -Wc,-Wno-inline -Wc,-Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o" "libs\chrono\src\chrono.cpp" > > ...failed qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\chrono.o... > common.copy D:\boost\include\boost\checked_delete.hpp > D:\boost_1_52_0_beta1\boost\checked_delete.hpp > 1 file(s) copied. > common.copy D:\boost\include\boost\chrono.hpp > D:\boost_1_52_0_beta1\boost\chrono.hpp > 1 file(s) copied. > qcc.compile.c++ D:\boostBuild_QCC_1_52_0_beta1\boost\bin.v2\libs\chrono\build\qcc\release\link-static\target-os-qnxnto\threadapi-pthread\threading-multi\process_cpu_clocks.o > In file included from ./boost/chrono/process_cpu_clocks.hpp:18:0, > from ./boost/chrono/detail/inlined/process_cpu_clocks.hpp:19, > from libs\chrono\src\process_cpu_clocks.cpp:17: > ./boost/chrono/duration.hpp: In static member function 'static constexpr float boost::chrono::detail::chrono_numeric_limits<float, true>::lowest()': > ./boost/chrono/duration.hpp:355:56: error: call to non-constexpr function 'static std::numeric_limits<float>::_Ty std::numeric_limits<float>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr double boost::chrono::detail::chrono_numeric_limits<double, true>::lowest()': > ./boost/chrono/duration.hpp:363:57: error: call to non-constexpr function 'static std::numeric_limits<double>::_Ty std::numeric_limits<double>::max()' > ./boost/chrono/duration.hpp: In static member function 'static constexpr long double boost::chrono::detail::chrono_numeric_limits<long double, true>::lowest()': > ./boost/chrono/duration.hpp:371:61: error: call to non-constexpr function 'static std::numeric_limits<long double>::_Ty std::numeric_limits<long double>::max()' > cc: d:/qnxsdk/qnxsdk6.5-001/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.7.1/cc1plus caught signal 1 For the record, I hit the same thing recently. In my case, it was a recently built clang that picked up an older libstdc++. The trouble is, just because a compiler supports constexpr doesn't mean the standard library does. Chrono doesn't seem to be making that distinction. It would be great to get this fixed for final release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Boost.Generic, C++0x Concepts, and C++1y Concepts
by Matt Calabrese 05 Oct '12

05 Oct '12

Hey everyone, It's been a while since I've made an appearance on this list, but I was contacted regarding the recent discussion of concepts here and Lorenzo's taking the reins of a concept library, and decided to poke my head in. First, I apologize to the community for not getting Boost.Generic on the sandbox earlier (if you are unfamiliar with Boost.Generic, see my 2011 BoostCon talk http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 and/or the corresponding slides https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic… ). I've gotten numerous emails about it since 2011 and I decided to commit the current state of Boost.Generic to the sandbox today. It is still based on the "old" concepts of C++0x with pseudo-signatures. You can find it in the "generic" subdirectory of the sandbox. That said, I'm not sure anyone even cares about Boost.Generic anymore given that the standard seems to be diverging from how it originally was approaching concepts, but here it is anyway. Similarly, I'm not sure there is any interest from people for me to continue developing Boost.Generic, so I guess this is a check for interest again. And, very briefly, without getting too political here (not that my opinion has any bearing) but I personally do not agree with some of the recent design changes for what may turn out to be C++1y concepts -- specifically I think pseudo-signatures were better overall and the C++0x form of associated types was much more useful than what is currently described, especially concerning associated type deduction, which no longer appears to be possible. But I don't think this discussion is suitable for the Boost mailing list and I don't want to ruffle too many feathers beyond that, so I'll take that elsewhere. For this reason, though, I [currently] do not have a desire to support that form of concepts in my library, though I do plan to resume work on Boost.Generic. A recap of what's gone on since my Boostcon talk, for anyone who even remembers it -- I haven't been actively developing Boost.Generic for over a year as I have been busy with other things, but coincidentally in the past couple of weeks I've gone back to it and decided to update some things due to a trick I realized I could use to get full compatibility with the C++0x working paper for explicit concept map templates (N2914's 14.10.3.2 paragraph 3 highlights why it's non-trivial, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf) Since then, I've had renewed interest in the project and have updated various facilities. Stuff that changed since my presentation back in 2011 -- it now supports variadic concepts using the syntax ,,, (see line 28 of boost/generic/std_concept/concepts/predicate.hpp for a simple example). All 135 of the concepts from N2914 are now implemented, though not all are working, especially ones that are not auto and use refinement (I'm still in the process of making the concept map backend changes). All of the std_concepts/concepts tests should be working, and same with std_concept/support_concepts tests, with GCC and Clang only failing on FreeStoreAllocatable (in slightly different ways). I'm updating some of the implementation to use the new Boost.Preprocessor variadic macro support that didn't exist when I started development, and Boost.Generic now also is starting to use Edward Diener's variadic_macro_data_library that's in the sandbox. I've only recently test on GCC 4.7 and Clang 3.1, both with libstdc++ on Windows. I don't think any other compilers will be able to handle it because of the amount of C++11 features currently in use... Visual C++ in particular will likely have no chance of compiling ANY of it, even if you use the fully preprocessed form of the library that I provided on the sandbox. Specifically, I currently require the updated C++11 SFINAE support, variadic templates, and template aliases, among other features which I don't believe Visual C++ yet supports. If you want to see how to use the library, for now you'll have to watch the talk, look at the slides, and/or go into generic/test/libs/generic/test/std_concept and examine the tests that are there (the latter will probably be the most enlightening in terms of using the predefined concepts). As for the tests, the ones you should look at if you want to understand how to use the predefined concepts are in the test directory's std_concept/concepts and std_concept/support_concepts subdirectories. If you want to see the syntax for creating your own concepts, the ones in std_concept/concepts are the best choice to look at, as they are simple and most do not require compiler intrinsics, unlike the support_concepts which rely on C++11 type_traits and the C++0x std::True concept. I also recently integrated Boost.Wave support to easily generate preprocessed versions of all of the concepts in the library. You can use the preprocessed headers, including Dave's suggested #line support, without having to run Boost.Wave yourself. To do this you just define a couple of macros when you build the tests. This decreases build times by over 50% on both Clang and GCC -- the tests for me in Clang go from over 7 minutes to just over 3 minutes if I use the preprocessed headers. To activate this support you need the two defines in the following format (easiest to just define them via the command-line) // NOTE: Do not use quotes around the path -- also realize that the path ends in the middle of the word generic, This is necessary. #define BOOST_GENERIC_PREPROCESSED_ROOT put_your_COMPLETE_path_to_boost_sandbox_here/generic/include/boost/gen // Also #define BOOST_GENERIC_USE_PREPROCESSED_HEADERS This will use completely preprocessed concepts, with errors properly pointing to the non-preprocessed headers, and effectively gets rid of all of the "from macro invocation" notes you'd see in clang and gcc 4.8 whenever you hit one of the Boost.Generic generated static_asserts in the non-preprocessed form. It is recommended that you use the preprocessed form unless you are making changes to the library-provided concepts, since compile-times are greatly reduced by using them and error messages are improved. Anyway, as I said, I do not personally like the direction that concepts seem to be going and so I do not currently have much of an interest in implementing what is currently proposed, however, buried somewhere in the source of Boost.Generic I believe is an early implementation of the library that was more similar to how concepts are specified in N3351, though I stopped maintaining it a long time ago -- it allowed for the specification of givens and arbitrary expression matching similar to the current design, with a brief demonstration given in my 2011 Boostcon talk (slide 20: https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic…) It might be useful to revive this now that standard concepts may be going in that direction, but again, I do not think this is a good idea and was why I was convinced by others to switch development to pseudo-signatures to begin with. -- -Matt Calabrese

3 16

[Review Report] ODEInt accepted
by Steven Watanabe 04 Oct '12

04 Oct '12

AMDG The review of the ODEInt library submitted by Mario Mulansky and Karsten Ahnert ended last Friday. Many thanks to everyone who participated in this review. The library is ACCEPTED into Boost unconditionally. Summary: 7 ACCEPT 1 ABSTAIN Reviews: http://lists.boost.org/Archives/boost/2012/09/196733.php http://lists.boost.org/Archives/boost/2012/09/196882.php http://lists.boost.org/Archives/boost/2012/09/196883.php http://lists.boost.org/Archives/boost/2012/10/196966.php http://lists.boost.org/Archives/boost/2012/10/196965.php http://lists.boost.org/boost-users/2012/09/76089.php http://lists.boost.org/boost-users/2012/09/76058.php http://lists.boost.org/boost-users/2012/09/76069.php Other comments: http://lists.boost.org/Archives/boost/2012/09/196756.php The reviews were overwhelmingly positive. Most reviewers were satisfied with the library documentation and interfaces. Issues: These were points brought up by reviewers. The authors are free to accept or reject any of these at their discretion. - A number of minor documentation corrections. - Automatically deduce the correct algebra from the state type. - Use a default initial step size. - Allow breaking out of the algorithms In Christ, Steven Watanabe

2 1

Who maintains boost MPI?
by Ralf Grosse-Kunstleve 04 Oct '12

04 Oct '12

Hi, we're looking for someone to merge a simple patch: https://svn.boost.org/trac/boost/ticket/6123 Ralf

4 4

[release] permission to merge proto fix to release?
by Eric Niebler 04 Oct '12

04 Oct '12

I would like to merge the following changeset to release: https://svn.boost.org/trac/boost/changeset/80820 It's a bug fix for Proto that fixes a failing Phoenix test. The change is only 1 day old, but many of the Sandia testers have cycled already. OK to merge? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[contract] SFINAE question for concepts
by Lorenzo Caminiti 04 Oct '12

04 Oct '12

Hello all, I have a SFINAE question. The following correctly returns false for eq1<x>::value when x has no operator== template< typename T > struct eq1 { T a; T b; template< typename TX > static char check ( TX a, TX b, char(*)[sizeof (std::is_convertible<decltype(a == b), bool>) ]); template< typename TX > static long check ( ... ); static const bool value = sizeof(char) == sizeof check<T>(a, b, 0); }; However, the following implementation that uses bool{a == b} incorrectly returns true for eq2<x>::value even if x has no operator==... why? BTW, if I just use (a == b) instead of bool{a == b} then it works... template< typename T > struct eq2 { T a; T b; template< typename TX > static char check ( TX a, TX b, char(*)[sizeof bool{a == b} ]); template< typename TX > static long check ( ... ); static const bool value = sizeof(char) == sizeof check<T>(a, b, 0); }; A complete example is attached. I'm using clang++ 3.2 with -std=c++0x. Thanks, --Lorenzo

2 3

[uuid] Merge changes to release
by Andrey Semashev 03 Oct '12

03 Oct '12

Hi, I've noticed that changeset https://svn.boost.org/trac/boost/changeset/80501 was not merged to release branch. The changeset removes a few warnings (including the ones about uninitialized variables) and fix tickets 7375 and 6118. The tests look good. Are these changes planned for 1.52?

3 2

[contract] static if instead of assertion requirements
by Lorenzo Caminiti 03 Oct '12

03 Oct '12

Hello all, I was reading the proposal to add "static if" to C++1x and I will use such a syntax for assertion requirements: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf Current syntax for assertion requirements: postcondition( back() == value, requires boost::has_equal<T>::value ) Will be replaced with static if: postcondition( static if(boost::has_equal<T>::value) ( back() == value ) // optional else ( ... ) ) If there were interested, I could even provide a separate BOOST_STATIC_IF(const_condition, then_code, else_code)... however, such a macro could only be used at namespace and class scope, not a function scope :( --Lorenzo

2 2

Boost.Thread does not compile from trunk
by Jeremiah Willcock 02 Oct '12

02 Oct '12

It seems like <boost/thread/future.hpp> is missing an #include of <iostream> and produces errors about missing definitions of cout, etc. because of that. It looks like that is debugging code that may not have been intended to be committed. -- Jeremiah Willcock

2 1

Re: [boost] Fwd: ODEInt review
by Karsten Ahnert 02 Oct '12

02 Oct '12

Hi Greg On 10/02/2012 09:11 PM, Karsten Ahnert wrote: > Hi Freg, Sorry for misspelling!

1 0

Fwd: ODEInt review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: ODEInt review Date: Wed, 26 Sep 2012 11:48:18 -0400 From: Reese, Greg Dr. <greg.reese(a)miamioh.edu> To: watanabesj(a)gmail.com <watanabesj(a)gmail.com> CC: Reese, Greg Dr. <greg.reese(a)miamioh.edu> Please always state in your review, whether you think the library should be accepted as a Boost library! Absolutely! - What is your evaluation of the design? Good. Good use of policies Is it necessary to set an initial step size on the adaptive integrators? Shouldn't they be able to figure this out on their own? If the size is needed, maybe it could have a default value so the user doesn't have to pass the argument. - What is your evaluation of the implementation? Appears to be good but I didn't look at code in detail. - What is your evaluation of the documentation? Excellent! Probably the best documentation of any Boost library. Suggestions: 1) Add general explanation of "observers", e.g., what they do, sample uses. 2) In documentation of example programs, add plots of outputs. These help users decide if the program ran correctly and if they're interpreting the outputs correctly - What is your evaluation of the potential usefulness of the library? Extremely useful to C++ programmers who want to incorporate ODE solutions into their code - Did you try to use the library? With what compiler? Did you have any problems? Used Microsoft Visual C++ 2012. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2-3 hours. Read through documentation, ran a number of sample programs - Are you knowledgeable about the problem domain? Yes Suggestion for future (not current!) version - add capability for user routines to stop the Integration process. This is useful for breaking out of periodic solutions, for stopping the computations if the solution attains meaningless values, and for limiting the amount of running time. See, for example, "Event Location" at http://www.mathworks.com/help/matlab/math/ordinary-differential-equations.h… Perhaps this capability can be incorporated into the observers. Greg Reese

3 3

Fwd: [Review] ODEint review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: [Review] ODEint review Date: Fri, 28 Sep 2012 22:56:56 +0200 From: André Bergner <andre.bergner.0(a)gmail.com> To: boost(a)lists.boost.org CC: watanabesj(a)gmail.com === ODEINT REVIEW === I vote for 'YES'. The library ODEint should be accepted and integrated into boost. Boost features many scientific/numeric applications already. Differential equations are fundamental enough to be added to boost's math/numeric category and enhance the scientific use cases of boost. _____________________________________________ What is your evaluation of the design? ODEint features a modern C++ (concept based as opposed to of polymorphism) which improves performance and flexibility tremendously. It demonstrates very well the power of a functional programming style - algorithms and containers are separated strictly. In particular parallelization comes almost for free by 'just' changing the container type. This is one very nice feature I like a lot. The design allows inter-portability to a great extend. Pretty much everything can be exchanged and adapted to specific needs. _____________________________________________ What is your evaluation of the implementation? I did not dive into all the internals deeply. But from what I've seen ODEint is well implemented and its internal structure make sense. Here the well designed interface helps the internals to be structured clearly as well. _____________________________________________ What is your evaluation of the documentation? The documentation is pretty good. It is covering many use-cases in detail and demonstrates the high flexibility of ODEint (CUDE/thrust, etc.) with many examples (missing a lot in some other boost libs). It becomes clear how it is used and what can be done with it. Nevertheless, for somebody not familiar with the topic of differential equations the purpose of the library is unclear from a quick glance into the overview. I would extend the overview with a short introduction (one or two paragraphs, links to wikipedia) of the topic, especially with some demonstrative example in words (e.g. physics engine in computer games or something similar). Concerning a more technical detail of the lib, I would like to have one large html file instead of many linked small ones. This would improve reading and in particular searching a lot. Btw., this is also true for many other boost libraries. I miss some notes about ODEint and C++11 (e.g. some obvious such as lambda should be mentioned, what about literals as units). Further, from a mathematical point of view also some comments about the application to partial differential equations would be useful. For somebody with experience in the field this might be obvious but for a beginner this would be helpful. _____________________________________________ What is your evaluation of the potential usefulness of the library? ODEint has many applications in a huge amount of scientific and engineering fields. It has the potential to become the de-facto standard for solving ODEs and high performance computing. Further, some less obvious use-cases might be: particle systems (quite popular in entertainment apps these days), network layout algorithm, etc... Within its field of application this library is very feature complete and can compete with many standard libs (matlab, python, ...) with ease. I think that ODEint makes the best compromise between simplicity in use and computational performance while not giving up general flexibility. It also features many things (error correction, symplectic methods, ...) not present in many competing libraries. _____________________________________________ Did you try to use the library? With what compiler? Did you have any problems? I was using the library for quite some time with several compilers (gnu, clang, intel). _____________________________________________ How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I was using the library one year age intensively. However, within this year I was not using it due to a different working field of mine. But I was following its improvements. _____________________________________________ Are you knowledgeable about the problem domain? Yes, I used the library extensively. I was successfully combining it with boost::graph to integrate network of coupled differential equations. Best regards, --- André Bergner

1 0

[1.52.0] Release branch closed except by permission, beta next week
by Marshall Clow 02 Oct '12

02 Oct '12

Hello everyone, The release branch is now closed for all changes except by permission from one of the release managers. The beta release is planned for next Monday. Please can you write your entries for the release notes soon. As always you can edit them directly using subversion at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ Or you can email them to Daniel James <dnljms(a)gmail.com>. The release notes are linked from the main page soon after the beta is released, so it would be complete by then. Thanks, -- Marshall

1 2

[iterator] Minor comment typo in iterator_facade.hpp
by Team OSS 02 Oct '12

02 Oct '12

Hi! Patch attached for fixing it. It's our first contribution to the open-source community ;) Best regards, NINJA

2 1

Boost Range Joined Range
by Ali Nakipoglu 02 Oct '12

02 Oct '12

How can i create copy a joined_range type and it contents? Any alternatives to make this? For example typedef std::vector<int> VectorT; typedef joined_range< VectorT, VectorT> JoinedRangeT; VectorT vector0, vector1; JoinedRangeT joinedRange0( vector0, vector1 ) // I need this JoinedRangeT joinedRange1 = copyAnyRangeOrContainer( joinedRange0 ); Im planning to use your advices to design copyAnyRangeOrContainer function, so that it can create deep copies from given range or containers that are can be vector,map, joined_range<T1,T2> or even joined_range<joined_range<T1,T2>, joined_range<T1, T2> > Thank you! -- Ali Nakipoglu

3 2

[BGL] graph/properties.hpp (vertex_property) [PATCH]
by Shaun Jackman 01 Oct '12

01 Oct '12

Hi, vertex_property and edge_property should inherit publicly from vertex_property_type and edge_property_type. A patch follows. ./ContigGraph.h:55:39: error: 'type' is a private member of 'boost::mpl::eval_if<boost::detail::has_vertex_property_type<DirectedGraph<ContigProperties, Distance>, mpl_::bool_<false>>, boost::detail::get_vertex_property_type<DirectedGraph<ContigProperties, Distance>>, boost::no_property>' typedef typename vertex_property<G>::type vertex_property_type; ^ /usr/local/include/boost/graph/properties.hpp:251:49: note: constrained by implicitly private inheritance here template <class Graph> class vertex_property: vertex_property_type<Graph> {}; ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Cheers, Shaun --- graph/properties.hpp.orig 2012-09-27 11:37:48.000000000 -0700 +++ graph/properties.hpp 2012-10-01 10:43:34.000000000 -0700 @@ -248,8 +248,8 @@ >::type type; }; - template <class Graph> class vertex_property: vertex_property_type<Graph> {}; - template <class Graph> class edge_property: edge_property_type<Graph> {}; + template <class Graph> class vertex_property: public vertex_property_type<Graph> {}; + template <class Graph> class edge_property: public edge_property_type<Graph> {}; template <typename Graph> class degree_property_map

2 2

[coroutine review] late review + comments
by Jeffrey Lee Hellrung, Jr. 01 Oct '12

01 Oct '12

Apologies to Hartmut, Oliver, and the community for my late presence regarding the recently reviewed Coroutine library. I finally had a good block of time this afternoon/evening to look through the documentation [1], so I figured, even if Hartmut doesn't count this as a formal review, at least Oliver can use these comments to improve the documentation. First, if I were to vote on whether Coroutine should be accepted, it would be CONDITIONAL ACCEPTANCE just based on present documentation issues. At a minimum, the documentation needs some fixing up, but I also think Oliver should address the design and interface suggestions Vicente, Eugene, and others (I myself haven't yet gone through the entire discussion yet, though I've been meaning to) have had, which mostly seem to have merit, and then present an updated. Unfortunately, I can't come up with a specific list of said suggestions, but I trust Oliver can pick through the discussion as well as I can :/ Second, I would really like to see some form of this library in Boost :) One thing that benefits the documentation of a library with a seemingly nontrivial design space (like Coroutine) is a comparison with past and present solutions. A quick google search of "c++ coroutine" found 3 libraries that ostensibly implement coroutines or an approximation thereof [2-4]. I haven't gone through these quite yet, but I'd like to see why one should use the proposed Coroutine library over these alternatives (even a 1-line justification, like "Library X lacks critical feature Y, by design" or "Library X does not work on platform Z" would be sufficient.) I think some documented research to justify the existence of this library is warranted. My specific comments on the documentation follow (I just copy/pasted from a Google document, so I hope this doesn't format badly...). I'm pretty sure some of what's below repeats what someone else has said, but, for completeness, I just included everything that initially came to mind as I was reading the documentation. - Rename namespace boost::coro to (e.g.) boost::coroutine or something similarly spelled out and not (arguably cryptically) abbreviated. - "Executing a coroutine" - s/it can migrated/it can be migrated/ - The first example uses “coro_t c( boost::bind( f, _1 ) );”; I’m confused as f is a binary function, but the boost::bind expression only works for unary functions. - “The coroutine-function, as well as its arguments, if any, are copied into the coroutine's state.” Can you elaborate on what you mean by “its arguments...are copied into the coroutine’s state”? You must mean when you call the coroutine, i.e., the copying of the coroutine-function and the copying of the coroutine-function’s arguments occur at different times, right? - The example with output uses ctx when (I believe) you mean c. Also, it implies that coroutine<>::is_complete actually executes the coroutine-function, which seems non-intuitive to me; I would expect it to be non-modifying and only indicate whether the coroutine-function has completed or not. - s/preemtive/preemptive - “Calling coroutine<>::operator()() from inside the same coroutine results in undefined behaviour.” Can you give an example of how one could possibly mistakenly do this? - s/allways/always - “The arguments passed to coroutine<>::operator()(), in one coroutine, is returned by coroutine<>::self_t::yield() in the other coroutine or, if it is the first call to coroutine<>::operator()() ( coroutine was not started), the coroutine-function will be entered and the arguments are passed to coroutine-function on entry.” I think I know what you’re trying to say here, but talking about 2 coroutines when your examples only have one coroutine object is ripe for confusion. Either clarify your terminology, clarify this explanation of the signature, or both. - The fact that self_t::yield() must package its return value into a boost::tuple (when the coroutine-function has more than one argument beyond self) suggests to me that we should strive for more uniformity between how the coroutine-function is initially entered (now with explicitly separate arguments) and subsequently continued (now with a packaged set of arguments). A couple of suggestions: - Force all coroutine-functions to be nullary or unary (sans the self argument); one can manually address more than one argument via boost::tuple packaging, and maybe boost::coro::coroutine could automatically package >1 argument up into a boost::tuple to convenience. You may also want to provide a macro (named, e.g., BOOST_TUPLE_UNPACK) that can can unpack a tuple into variables, e.g., something that looks like BOOST_TUPLE_UNPACK( ( int x ) ( int y ), tuple ); - Use a coroutine-function signature that looks something like void f(coro_t::self_t & self) { BOOST_TUPLE_UNPACK( ( int x0 ) ( int y0 ), self.arguments() ); // … BOOST_TUPLE_UNPACK( ( int x1 ) ( int y1 ), self.yield() ); } Perhaps equivalently, one can always call self.arguments() to get the most recently passed set of arguments. - “coroutine-function with multiple arguments” - Isn’t the boost::bind in this example superfluous? - “Exit a coroutine-function” - yield_break or yield_return? You mention both. - There are 2 “Important” notes on forced_unwind exceptions that appear to say the same thing. - “Stack unwinding” - I’m starting to get really confused by your uses of boost::bind; “boost::bind( fn, _1 )” when fn is a nullary function??? I guess you forgot the self_t argument? If so, again, why is boost::bind even necessary? Did you check that these examples actually compile? - The default behavior of the destructor of always unwinding the stack seems entirely reasonable, but the preconditions you list seem entirely unreasonable and unsafe! Basically, I’m reading that { coro::coroutine< void ( ) > c; } results in undefined behavior, as the preconditions for the destructor are not met. This almost has to be a documentation error. Further: “After unwinding, a coroutine is complete.” I was under the impression that unwinding only occurs in the destructor of the coroutine, at which point the coroutine object does not exist anymore, so what coroutine are you referring to, and even if you’re referring to the recently destructed coroutine, in what way is it complete? - “Executing a generator” - s/The default StackAllocator concept/The default StackAllocator/ - Be consistent on when you use StackAllocator, stack-allocator, etc. I.e., what do you mean by each? - “The first argument of generator-function...”: You mean the *only* argument? - s/The generator-function executed/The generator-function is executed/ - Same notes as at the bottom of “Executing a coroutine”. - “Exit a generator-function” - Again, yield_break or yield_return? - “boost::bind( fn, _1, _2 )” ??? Huh? How is “a” bound within fn, then??? - s/self_yield/self.yield/ - It’s unclear to me why a separate generator class is provided in addition to the coroutine class. Can you explain what the differences are? E.g., I don’t see why coroutine can’t also have an operator unspecified-bool-type () rather than is_complete. - “Performance” - 10 doesn’t seem like a very convincing sample size. If you can’t nail down the CPU cycles and time exactly via theoretical analysis of the assembly code, then I don’t see what’s preventing you from using a sample size several orders of magnitude larger than 10! Okay, now time to go through the second half of the recent Coroutine discussion... - Jeff [1] http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html [2] http://code.mozy.com/projects/mordor/ [3] http://www.akira.ruc.dk/~keld/research/COROUTINE/ [4] http://dunkels.com/adam/pt/

2 1

[spirit] Symbols parser with overlapping symbols
by Andrey Semashev 01 Oct '12

01 Oct '12

Hi, I wonder how qi::symbols parser behaves when it contains partially overlapping symbols. For example: qi::symbols< char, int > syms; syms.add("a", 1); syms.add("aaa", 2); What will this parser return when "aaa" is passed as input? I couldn't find it in the docs.

2 1