February 2013 - 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

boost::optional -- updates for C++11 move semantics
by Diggory Hardy 10 Apr '14

10 Apr '14

Dear list, I wanted something like boost::optional, but with support for move- construction/assignment, so I went ahead and had a go at patching it. Attached is based on boost 1.49 (Ubuntu package). Could someone please review? I've not contributed to boost before. The changes at least aren't too complicated, but: 1) I'm not entirely sure if the move constructor (line 636) and swap function (line 1046) are implemented in the best way (also see line 279), 2) and I have no idea how is_[not_]reference_tag (line 486) works. 3) There should maybe also be a unit test. Of course, I am happy for my contributions to be published under the boost licence. Regards, Diggory

6 8

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

[tweener] Doxygen documentation issues
by Julien Jorge 05 Nov '13

05 Nov '13

Hi, I am writing the documentation of Boost.Tweener and I encounter various difficulties. One of them is the generation of the class documentation with doxygen. It seems that it cannot extract the class and member documentation from .ipp files. I like to document the methods of my classes near the implementation. In Boost.Tweener, most of the class documentation is then in the .ipp files and I have written the following lines in the Jamfile.v2: import quickbook ; using boostbook ; using doxygen ; doxygen reference : [ glob ../../../boost/tweener/*.hpp ] [ glob ../../../boost/tweener/detail/*.hpp ] [ glob ../../../boost/tweener/detail/impl/*.ipp ] [ glob ../../../boost/tweener/detail/impl/easing/*.ipp ] [ glob ../../../boost/tweener/easing/*.hpp ] But when I try to build the documentation, I have the following error: boost_1_52_0/tools/build/v2/build/generators.jam:1085: in ensure-type from module generators error: target { ../../../boost/tweener/detail/impl/tweener_group.ipp. } has no type Moreover, if I remove the ipp files, the generation of the documentation does not fail but the doxygen documentation is not extracted, except for the private members. So, how can I also disable the extraction of the private members in the documentation? You can check the Jamfile.v2 in the git repository of the project: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a… Regards, Julien

2 3

[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

[thread] synchronized_value: value and move semantics
by Vicente J. Botet Escriba 24 Sep '13

24 Sep '13

Hi, boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface. Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container. Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context? Best, Vicente [1] https://svn.boost.org/svn/boost/trunk/boost/thread/synchronized_value.hpp [2] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_valu… [3] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_pers… [4] "Enforcing Correct Mutex Usage with Synchronized Values" by Anthony Williams http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002… ------------- [section The Problem with Mutexes] The key problem with protecting shared data with a mutex is that there is no easy way to associate the mutex with the data. It is thus relatively easy to accidentally write code that fails to lock the right mutex - or even locks the wrong mutex - and the compiler will not help you. std::mutex m1; int value1; std::mutex m2; int value2; int readValue1() { boost::lock_guard<boost::mutex> lk(m1); return value1; } int readValue2() { boost::lock_guard<boost::mutex> lk(m1); // oops: wrong mutex return value2; } Moreover, managing the mutex lock also clutters the source code, making it harder to see what is really going on. The use of synchronized_value solves both these problems - the mutex is intimately tied to the value, so you cannot access it without a lock, and yet access semantics are still straightforward. For simple accesses, synchronized_value behaves like a pointer-to-T; for example: boost::synchronized_value<std::string> value3; std::string readValue3() { return *value3; } void setValue3(std::string const& newVal) { *value3=newVal; } void appendToValue3(std::string const& extra) { value3->append(extra); } Both forms of pointer dereference return a proxy object rather than a real reference, to ensure that the lock on the mutex is held across the assignment or method call, but this is transparent to the user. [endsect] [/The Problem with Mutexes] [section Beyond Simple Accesses] The pointer-like semantics work very well for simple accesses such as assignment and calls to member functions. However, sometimes you need to perform an operation that requires multiple accesses under protection of the same lock, and that's what the synchronize() method provides. By calling synchronize() you obtain an strict_lock_ptr object that holds a lock on the mutex protecting the data, and which can be used to access the protected data. The lock is held until the strict_lock_ptr object is destroyed, so you can safely perform multi-part operations. The strict_lock_ptr object also acts as a pointer-to-T, just like synchronized_value does, but this time the lock is already held. For example, the following function adds a trailing slash to a path held in a synchronized_value. The use of the strict_lock_ptr object ensures that the string hasn't changed in between the query and the update. void addTrailingSlashIfMissing(boost::synchronized_value<std::string> & path) { boost::strict_lock_ptr<std::string> u=path.synchronize(); if(u->empty() || (*u->rbegin()!='/')) { *u+='/'; } } [endsect] [/Beyond Simple Accesses] [section Operations Across Multiple Objects] Though synchronized_value works very well for protecting a single object of type T, nothing that we've seen so far solves the problem of operations that require atomic access to multiple objects unless those objects can be combined within a single structure protected by a single mutex. One way to protect access to two synchronized_value objects is to construct a strict_lock_ptr for each object and use those to access the respective protected values; for instance: synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { strict_lock_ptr<std::queue<MessageType> > u1 = q1.synchronize(); strict_lock_ptr<std::queue<MessageType> > u2 = q2.synchronize(); if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } This works well in some scenarios, but not all - if the same two objects are updated together in different sections of code then you need to take care to ensure that the strict_lock_ptr objects are constructed in the same sequence in all cases, otherwise you have the potential for deadlock. This is just the same as when acquiring any two mutexes. In order to be able to use the dead-lock free lock algorithms we need to use instead unique_lock_ptr, which is Lockable. synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { unique_lock_ptr<std::queue<MessageType> > u1 = q1.unique_synchronize(boost::defer_lock); unique_lock_ptr<std::queue<MessageType> > u2 = q2.unique_synchronize(boost::defer_lock); boost::lock(u1,u2); // dead-lock free algorithm if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } [endsect] [/Operations Across Multiple Objects]

1 0

[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

Static initialization of boost shared objects question
by Juan Carlos Franzoy 02 Jul '13

02 Jul '13

Hello. Thanks for reading my question. I fell into a deadlock in static initialization of boost shared objects. The deadlock occurs in a reentrant call to a function which contains a definition of a static variable. Apparenlty gcc protects the initialization of such variables with a condition variable. Looking at the c++ code nothing at all make anybody suspect about reentrancy. My "interpretation of the fact" may be titled 'something in gcc, ld, ld.so, c++language made the call to be reentrant' - There is a function boost::system::generic_category() that has a static variable V - V type is boost::system::annonymous-namespace::generic_error_category - boost::system::annonymous-namespace::generic_error_category is subclass of boost::system::error_category. - boost::system::annonymous-namespace::generic_error_category has no declared/defined constructor as well as all its superclasses - The compilation process generate the constructor boost::system::error_category::error_category() as a weak symbol inside every shared object that uses it. - There is a static variable boost::system::posix_category in one of the shared objects that is initialized calling boost::system::generic_category(). - when the static initialization of a shared object boost::system::posix_category get initialized - which calls boost::system::generic_category() - Inside boost::system::generic_category() starts the initialization of V which calls boost::system::error_category::error_category() - It may happend that the runtime calls an instance of boost::system::error_category::error_category() that resides in a shared object that is still not loaded - So that .so get loaded and it is called its own static initialization - which can call boost::system::generic_category() - BOOM I would love if you can confirm of refute my humble "interpretation". Details follows ------------------- boost version: 1-52-0 Operating system: uname -a SunOS bcpp-solaris10 5.10 Generic_147441-25 i86pc i386 i86pc $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/local/gcc-4.6.2/libexec/gcc/i386-pc-solaris2.10/4.6.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../src/gcc-4.6.2/configure --prefix=/export/home/local/gcc-4.6.2 --with-gmp=/export/home/local/gcc-4.6.2/gmp-4.3.2 --with-mpfr=/export/home/local/gcc-4.6.2/mpfr-3.0.0 --with-mpc=/export/home/local/gcc-4.6.2/mpc-0.8.2 --with-libelf=/export/home/local/gcc-4.6.2/libelf-0.8.12 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-plugin --enable-multilib --enable-version-specific-runtime-libs --enable-bootstrap --enable-ssp --enable-libssp --with-included-gettext --enable-lto --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.2 (GCC) Callstack backtrace (lines begining with = are my comments): = = deadlock here: the threads is waiting itself = #0 0xfd459019 in __lwp_park () from /lib/libc.so.1 #1 0xfd45365e in cond_sleep_queue () from /lib/libc.so.1 #2 0xfd453817 in cond_wait_queue () from /lib/libc.so.1 #3 0xfd453b94 in cond_wait_common () from /lib/libc.so.1 #4 0xfd453d02 in _cond_wait () from /lib/libc.so.1 #5 0xfd453d2d in cond_wait () from /lib/libc.so.1 #6 0xfd453d66 in pthread_cond_wait () from /lib/libc.so.1 #7 0xfd632898 in __gthread_cond_wait (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:846 #8 __gthread_cond_wait_recursive (g=0xfd822ea8) at ...work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:860 #9 __gnu_cxx::__cond::wait_recursive (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/ext/concurrence.h:377 #10 __cxa_guard_acquire (g=0xfd822ea8) at .../src/gcc-4.6.2/libstdc++-v3/libsupc++/guard.cc:289 = = Reentrant call to boost::system::generic_category() = #11 0xfd812313 in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #12 0xfe85cd38 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #13 0xfe85d05f in _GLOBAL__sub_I_instantiate_re2c_lexer_str.cpp () at libs/wave/src/instantiate_re2c_lexer_str.cpp:56 = = static initization of boost.wave library = #14 0xfe8868fd in __do_global_ctors_aux () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #15 0xfe88692a in _init () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #16 0xfefce37e in call_init () from /usr/lib/ld.so.1 #17 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #18 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #19 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #20 0xfee60688 in ?? () #21 0xfee0c8f6 in boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() at ./boost/exception/detail/exception_ptr.hpp:119 #22 0xfee0c0d2 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/exception/detail/exception_ptr.hpp:138 #23 0xfee0c271 in _GLOBAL__sub_I_future.cpp () at libs/thread/src/future.cpp:60 = = static initization of boost.thread library = #24 0xfee0d98d in __do_global_ctors_aux () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #25 0xfee0d9ba in _init () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #26 0xfefce37e in call_init () from /usr/lib/ld.so.1 #27 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #28 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #29 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #30 0xfdce0688 in ?? () = = First calll to boost::system::generic_category() = #31 0xfd81232a in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #32 0xfd812386 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #33 0xfd8123ed in _GLOBAL__sub_I_error_code.cpp () at libs/system/src/error_code.cpp:430 = = static initialization of boost.system = #34 0xfd8126ed in __do_global_ctors_aux () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #35 0xfd81271a in _init () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #36 0xfefce37e in call_init () from /usr/lib/ld.so.1 #37 0xfefcd7d5 in setup () from /usr/lib/ld.so.1 #38 0xfefdba3e in _setup () from /usr/lib/ld.so.1 #39 0xfefc299c in _rt_boot () from /usr/lib/ld.so.1 #40 0x08047540 in ?? () #41 0x08047670 in ?? () More thanks for reading all.

3 4

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

[GSOC] Are we going to participate?
by Antony Polukhin 02 May '13

02 May '13

Hi all, Today starts Google Summer of Code. Is Boost community will become one of the mentoring organizations? What project ideas are we proposing? (As for me, I'd love to see unique_ptr+unique_array implemented using Boost.Move; C++11 features support for MPL, Fusion, Graph, Bind, Optional; BTree library; library for getting system info) -- Best regards, Antony Polukhin

16 24

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

future<>::then() Error returning future<void> (on trunk)
by Fernando Pelliccioni 07 Apr '13

07 Apr '13

Hi Vicente, hi all, I noticed that in the trunk there is a implementation of future<>::then(). Thank you very much for your efforts to implement it! The following example, compiles OK boost::future<int> f1 = boost::async([]() { return 123; }); f1.then([](boost::future<int> const& f) { return std::string(""); }); But this one fails to compile: boost::future<int> f1 = boost::async([]() { return 123; }); f1.then([](boost::future<int> const& f) { }); Here future<>::then() have to returns future<void> like ... boost::async([]() { }); Am I right? On the other hand, have you taken into account the following paper? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3451.pdf Regards, Fernando Pelliccioni.

3 5

Review managers wanted for augmented data structures
by Vadim Stadnik 06 Apr '13

06 Apr '13

Hi all, At present, neither Boost library nor STL provides containers using augmented data structures. I suggest that the Boost community consider solving the challenging problem – how to extend STL by integrating advanced data structures. Is there an alternative of not integrating advanced data structures into STL? IMO, no, since it is equivalent to “STL must go”. C++ cannot ignore performance benefits provided by these data structures. On the other hand, advanced data structures can be implemented in many programming languages and this will make C++ less competitive. Augmented red-black trees could have been included in the very first version of STL. Why is it difficult and has not been done yet? The major obstacle for the integration is the C++ standard specification of computational complexities of single operations for containers and iterators. Augmented trees are non-standard due to different performance guarantees. At the same these data structures are beneficial for complex algorithms, since they offer a wider set of more efficient operations compared to standard containers. The typical performance improvement for one operation is O(log N) against O(N). For less efficient operations these trees normally provide running time O(log N) against O(1), which is good enough for many applications. The C++ STL will be under pressure as long as there are new data structures that offer better running time for user algorithms. Asymptotically, the main parameter that determines the running time of an algorithm is the total computational cost (to simplify the discussion we omit the effect of locality of reference). By definition, the total computational cost is the sum of costs of single operations multiplied by their frequencies. For a general purpose library, such as STL, it is impossible at the design stage to know frequencies of all container and iterator operations required in all possible user algorithms. A more reasonable and practical approach to STL would be to provide a wide set of interchangeable containers and data structures with different performance guarantees and allow programmers to make decisions about the most suitable containers for specific applications. Relatively small frequencies of inefficient operations do not have significant effect on the total computational cost of an algorithm. Thus, in principle, containers and iterators can provide even inefficient operation in order to support more unified interfaces and to improve the generality. The replacement of interchangeable containers offers the advantage of low development cost solutions to performance bottlenecks that arise due to enhancement requests and/or an increase in the number of elements processed by a user algorithm. Also, I’d like to note that the representation of sequences using augmented trees is a frequent point of confusion and probably the fact that was overlooked in the development of previous versions of STL. The general description of the method of augmenting data structures is given in the section 14.2 of this book T.H. Cormen, C.E. Leiserson, R.L. Rivest and C. Stein, Introduction to Algorithms, 2nd Edition, MIT Press and McGraw-Hill, 2001. The specific application of this method is provided for order statistic trees and interval trees. Unfortunately, there is no example of a sequence that stores unordered elements. Probably for this reason augmented red-black trees are often considered to be an improvement of search trees only. The efficient representation of sequences by the described red-black trees follows from the fact that augmenting by the counter of children nodes supports efficient mapping from non-negative integers into container elements. It works both for ordered and unordered containers with unique and multiple elements or keys. There are two libraries in the Boost review schedule: http://www.boost.org/community/review_schedule.html "STL Extensions" and "Countertree". None of them has as yet a review manager. The order of the reviews may not be significant. It is more important that at least one library pass the review. This would help integrating other advanced data structures. Are there Boost experts who could volunteer to take responsibility of review manager for any of these two libraries? Regards, Vadim Stadnik

2 4

[fusion] What do we do with nil ?
by Joel de Guzman 31 Mar '13

31 Mar '13

Hello, This is a constantly nagging issue. There are a couple of places where nil is a PP define especially on the Mac: - objc.h #ifndef nil #define nil __DARWIN_NULL #endif and - MacTypes.h #ifndef nil #define nil NULL #endif So people complain because fusion uses nil as: namespace boost { namespace fusion { struct nil; }} So, nil is a reserved word in Objective-C. But this is C++! And that define is SUCH A BAD PRACTICE in C++! Some folks, like Paul Mensonides maintains a strong stance against this: I would just use #define nil nil as a sanity check and call it done. If the symbol is already defined, compilation error (or at least warning on overly permissive compilers). The symbol will be need to be undefined in between the inclusion of the two libraries. Workarounds like nil_ and (min)(...) just perpetuate the problem. Fix the root problem rather than treating the symptom indefinitely. Otherwise, where is the line drawn? Even if you can't provide a transparent fix (such as defining nil as a constant and min/max as functions), the backwards compatibility argument fails in the long run. The amount of effort required to make the necessary changes to existing code will eventually be outweighed by the effort to implement workarounds put into new code (as well as educate everyone that they are necessary)--especially in cases like these which can mostly be emulated in a way that causes most existing code to work. As I said over and over again, I'm listening and I would want to "fix" this issue if someone comes up with a reasonable (tested) patch that: 1) Detects the platform 2) Renames fusion::nil to something else (only for the affected platform) Yet, no-one wants to do this. Instead we get nasty remarks such as those found here: https://svn.boost.org/trac/boost/ticket/5010#comment:16 What do we do? I'm seeking for a resolution. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

4 5

[exception] uncaught_exception_count, scope(failure), scope(success)
by Evgeny Panasyuk 31 Mar '13

31 Mar '13

Hello All, There is implementation of uncaught_exception_count - https://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/u… . 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. uncaught_exception_count allow us to implement scope(failure) and scope(success) features from D language in C++. ( previous discussion is at http://boost.2283326.n4.nabble.com/scope-exit-D-style-scope-failure-and-sco… ) Implementation of uncaught_exception_count is tested on {Clang 3.2, GCC 3.4.6, GCC 4.1.2, GCC 4.4.6, GCC 4.4.7, MSVC2005SP1, MSVC2008SP1, MSVC2010SP1, MSVC2012} x {x32, x64}. There are also live stress tests - detection of 500 simultaneous uncaught exceptions: GCC 4.6.3: http://liveworkspace.org/code/2qmSso%240 GCC 4.7.2: http://liveworkspace.org/code/dY0VD%240 Clang 3.2: http://liveworkspace.org/code/49MaPk%240 I think that uncaught_exception_count (and uncaught_exception_count_latch primitive) can be added into Boost.Exception library, at least into "detail" section. After that scope(failure) and scope(success) features can be implemented in Boost.ScopeExit library. Note, approximately 14 of 16 Boost.ScopeExit examples in manual are in fact emulations of scope(failure)/scope(success). So, looks like in first place Boost.ScopeExit was introduced to simplify emulation of scope(failure) and scope(success) features. What do you think? Thank you. Best Regards, Evgeny Panasyuk

5 11

GSOC 2013
by David Bellot 22 Mar '13

22 Mar '13

Only 2 projects have been proposed so far for GSOC 2013: wake up Boost ! https://svn.boost.org/trac/boost/wiki/SoC2013 :-D

7 7

[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

[math] Support for libquadmath/ __float128
by Claas 19 Mar '13

19 Mar '13

I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems. - typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided. Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double? Regards Claas

6 19

[gil] What is the status of the Gil extension numeric?
by Krzysztof Czainski 18 Mar '13

18 Mar '13

Hello, During my first steps wit Boost.Gil I bumped onto an example [1], that uses the numeric extension. For this extension, the the example [1] and a ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil extensions to download. Most Google links pointed to the same page, but I finally found [3]. So my questions are: a) Is there a plan to add the extension numeric to Boost? b) Is [3] the newest version? And could the Boost.Gil docs be updated to point to the right place? c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension? Regards, Kris [1] http://www.boost.org/doc/libs/1_53_0/libs/gil/example/resize.cpp [2] http://opensource.adobe.com/gil [3] http://code.google.com/p/gil-contributions/ [4] http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/index.html

1 0

Help in setupping regression tests on ARM
by Antony Polukhin 16 Mar '13

16 Mar '13

I've successfully run nests on x86, but on ARM I've got the following message: # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in <module> runner(root) File "/home/pi/boost_maintain/run_trunk/tools_regression_src/regression.py", line 205, in __init__ self.main() File "/home/pi/boost_maintain/run_trunk/tools_regression_src/regression.py", line 566, in main getattr(self,action_m)() File "/home/pi/boost_maintain/run_trunk/tools_regression_src/regression.py", line 531, in command_regression self.command_test() File "/home/pi/boost_maintain/run_trunk/tools_regression_src/regression.py", line 329, in command_test self.command_test_boost_build() File "/home/pi/boost_maintain/run_trunk/tools_regression_src/regression.py", line 369, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/pi/boost_maintain/run_trunk/results/boost/bin.v2/libs/any/test/any_test.test' I try to run tests on RaspberryPi, it is armhf. Compilller is GCC-4.6.3, 25Gb of free space on SD card. It looks strange, that I see only a few folders in /home/pi/boost_maintain/run_trunk/results/boost/bin.v2/libs/ (there are only 6 folders) -- Best regards, Antony Polukhin

2 7

[type_traits] Some traits are missing
by Antony Polukhin 15 Mar '13

15 Mar '13

Hi all, Equivalents of following traits are in C++11 Standard, but missing in Boost.TypeTraits library: has_nothrow_move_assign has_nothrow_move_constructor has_trivial_move_assign has_trivial_move_constructor Extremely naive implementation of those functions exist in Boost.Variant, so as a start we can use them. Or am I missing something and there is a reason, why those traits are not included in Boost.TypeTraits? -- Best regards, Antony Polukhin

3 6

[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] C++11 once_flag enabled when constexpr is not available
by Andrey Semashev 05 Mar '13

05 Mar '13

Hi, Vicente! I see you applied my patch for call_once but you seem to forgot to disable the C++11 call_once interface when the compiler does not support constexpr. Was that intentional or you just missed it? Anyway, please find the patch attached.

3 3

[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

[thread] barrier::wait() not marked as interruption_point
by Oliver Kowalke 04 Mar '13

04 Mar '13

In the documentation (1.53 beta) barrier::wait() is not marked as interruption-point nor that it will throw thread_interrupted if thread blocked inside barrier::wait() if it gets interrupted. Because barrier::wait() calls condition_variable::wait() and condition_variable::wait() is a interruption-point barrier::wait() should it be too - or do I miss something? Oliver

2 1

[persistent] Library preview: Persistent
by Stefan Strasser 04 Mar '13

04 Mar '13

Hi everyone, I'm thinking about finishing a library that was proposed a couple of years ago. It was pretty far along, and there is documentation available in the sandbox (somewhat outdated): https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html… It is a library with the goal of storing C++ objects on disk, with an interface that is as close as possible to accessing regular C++ objects in memory. A very simple example could look like this: shared_loc<person> p=...; { transaction tx; p->name="..."; p->address="..."; tx.commit(); } It is based on Boost.Serialization, but automatically maintains a consistent state on disk (ACID transactions), which can be updated incrementally. Part of its code was moved to a library named Transact to work alongside other transactional resources (like memory) and is available in the sandbox: https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/ I'd like to know whether the boost community is still interested in such a library, and I suppose there are quite a few new people here so your comments are welcome as well. Thank You!

6 9

[type traits] is_literal_type ?
by Robert Ramey 02 Mar '13

02 Mar '13

Any chance of a boost implementation for is_literal_type? Robert Ramey

4 6

Git Conversion Schedule
by Sebastian Redl 02 Mar '13

02 Mar '13

Hi, According to the timeline linked from the svn.boost.org frontpage, we're already using Git: https://svn.boost.org/trac/boost/wiki/ModCvtSchedule But I'm pretty sure that's not the case, right? What is the current schedule? Sebastian

3 2

[tweener] How to copy image files in documentation
by Julien Jorge 01 Mar '13

01 Mar '13

Hi, I wrote the documentation of Boost.Tweener in boostbook format. I have references to some images in the documentation but they are not copied in the target html directory when I type bjam html How can I make the image directory to be automatically copied in the target directory of the generated documentation? Since I am not familiar with the build process of Boost yet, I would accept a reason not to do this as an answer :) Regards, Julien Jorge

2 2

[type_erasure] overloading macro
by Christophe Henry 28 Feb '13

28 Feb '13

Hi all, I played a bit more with overloading and it started being annoying and error-prone to add more overloads of concept_map (with more arguments) so I wrote a small macro to 1) generate my overloads and 2) save myself the time reading compiler errors when I use BOOST_TYPE_ERASURE_MEMBER and make a mistake in the number of arguments. It's for C++11 (argument pack) as it's all I need at the moment but I suppose that with Boost.Preprocessor, it'd be for C++03 doable. Well, in case it'd be of any use to someone, here it is, with a small test (tested with g+ 4.5 with -std=c++0x). #include <boost/type_erasure/concept_interface.hpp> #include <boost/type_erasure/rebind_any.hpp> #include <boost/type_erasure/derived.hpp> #include <boost/type_erasure/is_placeholder.hpp> #include <boost/type_erasure/constructible.hpp> #include <boost/type_erasure/relaxed_match.hpp> #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/builtin.hpp> #include <boost/type_erasure/any_cast.hpp> #include <boost/type_erasure/detail/macro.hpp> #include <boost/mpl/vector.hpp> #include <iostream> #ifndef BOOST_NO_CXX11_VARIADIC_TEMPLATES #define BOOST_TYPE_ERASURE_MEMBER_VARIADIC_I(qualname,concept_name,member) \ BOOST_TYPE_ERASURE_OPEN_NAMESPACE(qualname) \ template <typename T, typename... Args> \ struct concept_name{ \ static void apply(const T& t, const Args... a) { t.member(a...); } }; \ BOOST_TYPE_ERASURE_CLOSE_NAMESPACE(qualname) \ namespace boost { namespace type_erasure { \ template<class T, typename... U, class Base, class Enable> \ struct concept_interface< BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U... >, Base, T, Enable> : Base { \ typedef void _fun_defined; \ void member(typename rebind_any<Base, U>::type... arg)const \ {call(BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>(), *this, arg...);} }; \ template<class T, typename... U, class Base> \ struct concept_interface< BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>, Base, T, typename Base::_fun_defined> : Base{ \ using Base::member; void member(typename rebind_any<Base, U >::type... arg)const \ {call(BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>(), *this, arg...);} }; \ }} #endif #define BOOST_TYPE_ERASURE_MEMBER_VARIADIC(qualified_name,member) \ BOOST_TYPE_ERASURE_MEMBER_VARIADIC_I( \ qualified_name, \ BOOST_PP_SEQ_ELEM(BOOST_PP_DEC(BOOST_PP_SEQ_SIZE(qualified_name)), qualified_name), \ member) // supports overloading, does not require any number of arguments BOOST_TYPE_ERASURE_MEMBER_VARIADIC((n1)(n2)(foo),foo) namespace mpl = boost::mpl; using namespace boost::type_erasure; struct Test { void foo()const { std::cout << "foo() called" << std::endl; } void foo(int i)const { std::cout << "foo(int) called with: " << i << std::endl; } void foo(int i,char c)const { std::cout << "foo(int,char) called with: " << i << "," << c << std::endl; } void foo(double d)const { std::cout << "foo(double) called with: " << d << std::endl; } void foo(int i,double d)const { std::cout << "foo(int,double) called with: " << i << "," << d << std::endl; } void foo(int i,double d,char c)const { std::cout << "foo(int,double,char) called with: " <, n1::n2::foo<_self, int>, n1::n2::foo<_self, double>, n1::n2::foo<_self, int, double>, n1::n2::foo<_self, int, char>, n1::n2::foo<_self, int, double, char>, copy_constructible<> > > x (t); x.foo(); // calls foo() x.foo(1); // calls foo(int) x.foo(1.0); // calls foo(double) x.foo(1,1.0); // calls foo(int, double) x.foo(1,'a'); // calls foo(int, char) x.foo(1,1.0,'a'); // calls foo(int, double,char) return 0; }

2 21

[ptr_container, crc, format] Open tickets - code patches available
by Joachim Faulhaber 28 Feb '13

28 Feb '13

Hi, there are open tickets: https://svn.boost.org/trac/boost/ticket/7430 (ptr_container: warning fixes) https://svn.boost.org/trac/boost/ticket/7433 (crc: runtime check issue) https://svn.boost.org/trac/boost/ticket/7435 (format: crash) that we have submitted 5 months ago. Along with the bug reports there are code patches for the reported issues, that have been tested and used in production code on different platforms. We would kindly ask the maintainers to look at these issues and to apply the patches to the library code, so they can be integrated in the next release. In case the maintainers do not have time to fix these issues within say the next 2 weeks, I (Joachim) would like to ask for permission to apply the patches. Fixing the issues would be very helpful for us, so we don't have to patch the code locally for every new version. Thanks a lot, Joachim & Franz -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 6

Releasing gil::io
by Christian Henning 28 Feb '13

28 Feb '13

Hi all, I have taken a look at the requirements to release a new library. There is some points I like to discuss. Technically speaking gil::io is a replacement of the older gil io extension. So, it's not really a new library. But of course, I don't mind fulfilling all the requirements. Here are the requirements before merging: * root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. Should I add a gil::io entry? * root/libs/maintainers.txt entry is OK. Should I add a gil::io entry? * The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs. Done * The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past. I'm using boostbook and the default templates. * Trunk inspection report is clean. I would need some help here to hook up gil::io test with general boost testing. * Trunk regression tests are reasonably clean or marked up. TODO Thanks, Christian

2 3

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

Proposed interface change to boost::algorithm::copy_while
by Marshall Clow 26 Feb '13

26 Feb '13

In 1.50, I introduced: template<typename InputIterator, typename OutputIterator, typename Predicate> OutputIterator copy_while ( InputIterator first, InputIterator last, OutputIterator result, Predicate p ); (and copy_until), which do pretty much what you would expect: copy items from the input to the output as long as the predicate holds. Sean Parent has convinced me that this is wrong; that I have to return the modified input iterator as well. When I wrote these, I was thinking (if I actually was thinking) of actual input iterators, and since they're all the same, so the caller can pick up on the input sequence after the call returns. However, if you're processing (say) a list, it would be kind of useful to know how far in the list the call advanced. I'm proposing to change the interface to: template<typename InputIterator, typename OutputIterator, typename Predicate> std::pair<InputIterator, OutputIterator> copy_while ( InputIterator first, InputIterator last, OutputIterator result, Predicate p ); i.e, changing the return type to return both iterators. What this means: * If you're not calling copy_while (or copy_until), then this change won't affect you. * If you're not using the return value, then this change won't affect you. * If you are using the return value, then you will have to change your code thus: Old foo = copy_while ( first, last, out, p ); New: foo = copy_while ( first, last, out, p ).second; * if you were not using these calls because they didn't return the input iterator, now you can. Questions? Comments? (Except for the "How could you miss that when you wrote those routines?" - I've already asked myself that) Improvements? -- 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

7 10

[context][iostreams] Cygwin Boost 1.53 error building some libraries.
by Mostafa 26 Feb '13

26 Feb '13

On Windows 7, cygwin 2.7, trying to build Boost 1.53 with the following options fails: ./b2.exe --layout=system --variant=release --link=static,shared --threading=single,multi install -j4 with the following errors: gcc.compile.asm bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/make_i386_sysv_elf_gas.o libs/context/src/asm/make_i386_sysv_elf_gas.S: Assembler messages: libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Warning: .type pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Error: junk at end of line, first unrecognized character is `m' libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Warning: .size pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Error: junk at end of line, first unrecognized character is `m' gcc.archive bin.v2/libs/atomic/build/gcc-4.5.3/release/link-static/threading-multi/libboost_atomic.a "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/make_i386_sysv_elf_gas.o" "libs/context/src/asm/make_i386_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/make_i386_sysv_elf_gas.o... common.copy /home/HPC/boost/v1_53_0/lib/libboost_atomic.a gcc.archive bin.v2/libs/system/build/gcc-4.5.3/release/link-static/threading-multi/libboost_system.a ... common.mkdir bin.v2/libs/date_time/build/gcc-4.5.3/release/link-static gcc.compile.asm bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/jump_i386_sysv_elf_gas.o libs/context/src/asm/jump_i386_sysv_elf_gas.S: Assembler messages: libs/context/src/asm/jump_i386_sysv_elf_gas.S:37: Warning: .type pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/jump_i386_sysv_elf_gas.S:37: Error: junk at end of line, first unrecognized character is `j' libs/context/src/asm/jump_i386_sysv_elf_gas.S:72: Warning: .size pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/jump_i386_sysv_elf_gas.S:72: Error: junk at end of line, first unrecognized character is `j' "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/jump_i386_sysv_elf_gas.o" "libs/context/src/asm/jump_i386_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi/asm/jump_i386_sysv_elf_gas.o... ...skipped <pbin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi>libboost_context.a(clean) for lack of <pbin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi>asm/make_i386_sysv_elf_gas.o... ...skipped <pbin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi>libboost_context.a for lack of <pbin.v2/libs/context/build/gcc-4.5.3/release/link-static/threading-multi>asm/make_i386_sysv_elf_gas.o... ... common.mkdir bin.v2/libs/locale/build/gcc-4.5.3/release/link-static common.mkdir bin.v2/libs/locale/build/gcc-4.5.3/release/link-static/threading-multi gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi/bzip2.o libs\iostreams\src\bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2\libs\iostreams\build\gcc-4.5.3\release\link-static\threading-multi\bzip2.o" "libs\iostreams\src\bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi>libboost_iostreams.a(clean) for lack of <pbin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi>bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.5.3/release/link-static/threading-multi>bzip2.o... ... ...failed updating 6 targets... ...skipped 14 targets... ...updated 3818 targets...

2 2

bjam compiler error
by Christian Henning 26 Feb '13

26 Feb '13

Hi, I'm getting an compiler error when I try to build gil::io documentation. ...patience... ...patience... ...found 1737 targets... ...updating 5 targets... compile-c-c++ ..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj values.cpp C:\boost\tools\quickbook\src\values.cpp(444) : error C2593: 'operator ==' is ambiguous ..\..\..\..\boost/utility/string_ref.hpp(275): could be 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(270): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(265): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] while trying to match the argument list '(boost::string_ref, boost::string_ref)' C:\boost\tools\quickbook\src\values.cpp(499) : error C2593: 'operator ==' is ambiguous ..\..\..\..\boost/utility/string_ref.hpp(275): could be 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(270): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(265): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] while trying to match the argument list '(boost::string_ref, boost::string_ref)' call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj.rsp" ...failed compile-c-c++ ..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj... ...skipped <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>quickbook.exe for lack of <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>values.obj... ...skipped <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.xml for lack of <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>quickbook.exe... ...skipped <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.docbook for lack of <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi-object(xinclude-scanner)@1505>io.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.docbook... ...failed updating 1 target... ...skipped 4 targets... Regards, Christian

5 5

[type_erasure] Some issues
by Fabio Fracassi 25 Feb '13

25 Feb '13

Hi Steven, I recently gave a presentation about type erasure in general, and your library in particular, at our local C++ UG (see here http://prezi.com/kg6d82f-_yky/type-erasure/ or the examples at https://github.com/CppUGBerlin/Talks/tree/master/2013_02_19_TypeErasure if you are interested). During the preparation I discovered some issues I'd like to ask you about. First I think I discovered a bug either in your lib or in clang(with libc++) when compiling one of the documentation examples in C++11 mode. #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/any_cast.hpp> #include <boost/type_erasure/builtin.hpp> #include <boost/type_erasure/operators.hpp> #include <boost/type_erasure/tuple.hpp> #include <iostream> namespace bte = boost::type_erasure; namespace mpl = boost::mpl; int main() { typedef bte::any< mpl::vector< bte::copy_constructible<>, bte::typeid_<>, bte::addable<>, bte::ostreamable<> > > any_type; any_type x(10); any_type y(7); any_type z(x + y); std::cout << z << std::endl; } Compiling this in C++03 mode is fine, in C++11 mode it fails with this error: In file included from te_multi03.cpp:5: ../../Staging/type_erasure/boost/type_erasure/operators.hpp:187:1: error: no matching function for call to 'call' BOOST_TYPE_ERASURE_BINARY_OPERATOR(addable, +) see [1] below for full error. The next are some things which I didn't get to work, and the documentation is silent on any pitfalls. I tried to implement Sean Parent's example from his Value Semantics talk and failed to write a concept that calls free functions instead of members. Here is what I tried (full code and error at [2] below): template<class OBJ, class T> struct drawable { static void apply(const OBJ& obj, T& os, size_t pos) { draw(obj, os, pos); } }; I get an error like: error call to function 'draw' that is neither visible in the template definition nor found by argument-dependent lookup I worked around this problem by defining a concept map, but that is not realy a good solution. On researching a better solution I saw that you already added the convenience macros BOOST_TYPE_ERASURE_MEMBER and BOOST_TYPE_ERASURE_FREE, but didn't have much luck with them. Is there a compileable example where they are used somewhere? Best regards Fabio **** [1] *************************************************************** [1] full error docu example: In file included from te_multi03.cpp:5: ../../Staging/type_erasure/boost/type_erasure/operators.hpp:187:1: error: no matching function for call to 'call' BOOST_TYPE_ERASURE_BINARY_OPERATOR(addable, +) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../Staging/type_erasure/boost/type_erasure/operators.hpp:166:20: note: expanded from macro 'BOOST_TYPE_ERASURE_BINARY_OPERATOR' return ::boost::type_erasure::call(name<T, U, R>(), lhs, rhs); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~ te_multi03.cpp:25:17: note: in instantiation of member function 'boost::type_erasure::operator+' requested here any_type z(x + y); ^ ../../Staging/type_erasure/boost/type_erasure/call.hpp:323:1: note: candidate template ignored: failed template argument deduction call( ^ ../../Staging/type_erasure/boost/type_erasure/call.hpp:356:1: note: candidate template ignored: substitution failure [with Op = boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, U = <const boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, boost::type_erasure::typeid_<boost::type_erasure::_self>, boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, boost::type_erasure::ostreamable<std::__1::basic_ostream<char>, boost::type_erasure::_self>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, boost::type_erasure::param<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, boost::type_erasure::typeid_<boost::type_erasure::_self>, boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, boost::type_erasure::ostreamable<std::__1::basic_ostream<char>, boost::type_erasure::_self>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, const boost::type_erasure::_self &>>]: no type named 'type' in 'boost::type_erasure::detail::call_result<boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, void (const boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, boost::type_erasure::typeid_<boost::type_erasure::_self>, boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, boost::type_erasure::ostreamable<std::__1::basic_ostream<char>, boost::type_erasure::_self>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> &, boost::type_erasure::param<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, boost::type_erasure::typeid_<boost::type_erasure::_self>, boost::type_erasure::addable<boost::type_erasure::_self, boost::type_erasure::_self, boost::type_erasure::_self>, boost::type_erasure::ostreamable<std::__1::basic_ostream<char>, boost::type_erasure::_self>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, const boost::type_erasure::_self &> &), void>' call( ^ 1 error generated. **** [2] *************************************************************** [2] Code and error for Value semantic example: #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/concept_interface.hpp> #include <boost/type_erasure/rebind_any.hpp> #include <boost/type_erasure/free.hpp> #include <vector> namespace bte = boost::type_erasure; namespace mpl = boost::mpl; //-------------------------------------------------------------------------------------------------- template<class OBJ, class T> struct drawable { static void apply(const OBJ& obj, T& os, size_t pos) { draw(obj, os, pos); } }; namespace boost { namespace type_erasure { template<class OBJ, class T, class Base> struct concept_interface< ::drawable<OBJ, T>, Base, OBJ> : Base { void draw(typename rebind_any<Base, T&>::type os, size_t pos) const { call(::drawable<OBJ, T>(), *this, os, pos); } }; } } using object_t = bte::any< mpl::vector< bte::copy_constructible<>, drawable<bte::_self, std::ostream> >>; //-------------------------------------------------------------------------------------------------- void draw(const int& value, std::ostream& out, size_t position) { out << std::string(position, ' ') << "int = " << value << std::endl; } void draw(const std::string& value, std::ostream& out, size_t position) { out << std::string(position, ' ') << "string = " << value << std::endl; } struct my_class_t {}; void draw(const my_class_t&, std::ostream& out, size_t position) { out << std::string(position, ' ') << "my_class_t" << std::endl; } //-------------------------------------------------------------------------------------------------- using document_t = std::vector<object_t>; // or std::vector<copy_on_write<object_t>>; void draw(const document_t& x, std::ostream& out, size_t position) { out << std::string(position, ' ') << "<document>" << std::endl; for (auto& e : x) { e.draw(out, position + 2); } out << std::string(position, ' ') << "</document>" << std::endl; } //-------------------------------------------------------------------------------------------------- using history_t = std::vector<document_t>; void commit(history_t& x) { assert(x.size()); x.push_back(x.back()); } void undo(history_t& x) { assert(x.size()); x.pop_back(); } document_t& current(history_t& x) { assert(x.size()); return x.back(); } //-------------------------------------------------------------------------------------------------- int main () { history_t h(1); current(h).emplace_back(0); current(h).emplace_back(std::string("Hello!")); draw(current(h), std::cout, 0); std::cout << "--------------------------" << std::endl; commit(h); current(h).emplace_back(current(h)); current(h).emplace_back(my_class_t()); draw(current(h), std::cout, 0); std::cout << "--------------------------" << std::endl; undo(h); draw(current(h), std::cout, 0); } **** Error: ************************************************************ te_sp_copy.cpp:14:59: error: call to function 'draw' that is neither visible in the template definition nor found by argument-dependent lookup static void apply(const OBJ& obj, T& os, size_t pos) { draw(obj, os, pos); } ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:91:28: note: in instantiation of member function 'drawable<int, std::__1::basic_ostream<char> >::apply' requested here BOOST_PP_REPEAT(N, BOOST_TYPE_ERASURE_INSTANTIATE_IMPL, concept_sequence) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:38:60: note: expanded from macro 'BOOST_PP_REPEAT_1' # define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:43:63: note: expanded from macro 'BOOST_PP_REPEAT_1_I' # define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:54:62: note: expanded from macro 'BOOST_PP_REPEAT_1_3' # define BOOST_PP_REPEAT_1_3(m, d) BOOST_PP_REPEAT_1_2(m, d) m(2, 2, d) ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:70:47: note: expanded from macro 'BOOST_TYPE_ERASURE_INSTANTIATE_IMPL' (void)&::boost::mpl::at_c<data, n>::type::apply; ^ ../../Staging/type_erasure/boost/type_erasure/any.hpp:182:13: note: in instantiation of function template specialization 'boost::type_erasure::detail::instantiate_concept3::apply<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::map1<boost::mpl::pair<boost::type_erasure::_self, int> > >' requested here BOOST_TYPE_ERASURE_INSTANTIATE1(Concept, T, U), ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:51:14: note: expanded from macro 'BOOST_TYPE_ERASURE_INSTANTIATE1' >::type::apply( \ ^ /usr/bin/../lib/c++/v1/memory:1681:31: note: in instantiation of function template specialization 'boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>::any<int>' requested here ::new((void*)__p) _Up(_VSTD::forward<_Args>(__args)...); ^ /usr/bin/../lib/c++/v1/memory:1608:18: note: in instantiation of function template specialization 'std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> >::construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, int>' requested here {__a.construct(__p, _VSTD::forward<_Args>(__args)...);} ^ /usr/bin/../lib/c++/v1/memory:1492:14: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::__construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, int>' requested here {__construct(__has_construct<allocator_type, pointer, _Args...>(), ^ /usr/bin/../lib/c++/v1/vector:1519:25: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, int>' requested here __alloc_traits::construct(this->__alloc(), ^ te_sp_copy.cpp:71:15: note: in instantiation of function template specialization 'std::__1::vector<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::emplace_back<int>' requested here current(h).emplace_back(0); ^ te_sp_copy.cpp:33:6: note: 'draw' should be declared prior to the call site void draw(const int& value, std::ostream& out, size_t position) { ^ te_sp_copy.cpp:14:59: error: call to function 'draw' that is neither visible in the template definition nor found by argument-dependent lookup static void apply(const OBJ& obj, T& os, size_t pos) { draw(obj, os, pos); } ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:91:28: note: in instantiation of member function 'drawable<std::__1::basic_string<char>, std::__1::basic_ostream<char> >::apply' requested here BOOST_PP_REPEAT(N, BOOST_TYPE_ERASURE_INSTANTIATE_IMPL, concept_sequence) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:38:60: note: expanded from macro 'BOOST_PP_REPEAT_1' # define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:43:63: note: expanded from macro 'BOOST_PP_REPEAT_1_I' # define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:54:62: note: expanded from macro 'BOOST_PP_REPEAT_1_3' # define BOOST_PP_REPEAT_1_3(m, d) BOOST_PP_REPEAT_1_2(m, d) m(2, 2, d) ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:70:47: note: expanded from macro 'BOOST_TYPE_ERASURE_INSTANTIATE_IMPL' (void)&::boost::mpl::at_c<data, n>::type::apply; ^ ../../Staging/type_erasure/boost/type_erasure/any.hpp:182:13: note: in instantiation of function template specialization 'boost::type_erasure::detail::instantiate_concept3::apply<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::map1<boost::mpl::pair<boost::type_erasure::_self, std::__1::basic_string<char> > > >' requested here BOOST_TYPE_ERASURE_INSTANTIATE1(Concept, T, U), ^ ../../Staging/type_erasure/boost/type_erasure/detail/instantiate.hpp:51:14: note: expanded from macro 'BOOST_TYPE_ERASURE_INSTANTIATE1' >::type::apply( \ ^ /usr/bin/../lib/c++/v1/memory:1681:31: note: in instantiation of function template specialization 'boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>::any<std::__1::basic_string<char> >' requested here ::new((void*)__p) _Up(_VSTD::forward<_Args>(__args)...); ^ /usr/bin/../lib/c++/v1/memory:1608:18: note: in instantiation of function template specialization 'std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> >::construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, std::__1::basic_string<char> >' requested here {__a.construct(__p, _VSTD::forward<_Args>(__args)...);} ^ /usr/bin/../lib/c++/v1/memory:1492:14: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::__construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, std::__1::basic_string<char> >' requested here {__construct(__has_construct<allocator_type, pointer, _Args...>(), ^ /usr/bin/../lib/c++/v1/vector:1519:25: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::construct<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, std::__1::basic_string<char> >' requested here __alloc_traits::construct(this->__alloc(), ^ te_sp_copy.cpp:72:15: note: in instantiation of function template specialization 'std::__1::vector<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, std::__1::allocator<boost::type_erasure::any<boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_self>, drawable<boost::type_erasure::_self, std::__1::basic_ostream<char> >, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self> > >::emplace_back<std::__1::basic_string<char> >' requested here current(h).emplace_back(std::string("Hello!")); ^ te_sp_copy.cpp:37:6: note: 'draw' should be declared prior to the call site void draw(const std::string& value, std::ostream& out, size_t position) { ^ 2 errors generated.

2 3

[gil::io] Feedback for scanline_read_iterator
by Christian Henning 25 Feb '13

25 Feb '13

Hi all, I'm getting close to finally commit the new io extension for boost::gil. As it was required from the boost review I have implemented a basic image_read_iterator to read large images. I would like to get some feedback on my interface and maybe on the actual implementation, as well. I must admit this is my first iterator that I have designed and implemented from scratch with some help by other people. The latest io code can be found here via svn: http://code.google.com/p/gil-contributions/source/browse/#svn%2Ftrunk%2Fgil… A basic usage of the code is here: http://pastebin.com/3E7KpfwE Thanks! Christian

7 51

[utility]proposal for a small utility of namespace
by law chrono 25 Feb '13

25 Feb '13

I like c++ and boost，but write namespace is a boring work for brace-matching. So I write a small util with boost.preprocessor, like below: #ifndef BOOST_NAMESPACE_UTILITY_HPP_ #define BOOST_NAMESPACE_UTILITY_HPP_ #include <boost/preprocessor/seq/for_each.hpp> #define _PP_NS_BEGIN_FUNC(r,data,elem) namespace elem { #define _PP_NS_END_FUNC(r,data,elem) } #define BOOST_BEGIN_NAMESPACE(SEQ) \ BOOST_PP_SEQ_FOR_EACH(_PP_NS_BEGIN_FUNC, ~, SEQ) #define BOOST_ END_ NAMESPACE (SEQ) \ BOOST_PP_SEQ_FOR_EACH(_PP_NS_END_FUNC, ~, SEQ) #endif //BOOST_NAMESPACE_UTILITY_HPP_ Then the code can be more clear and easy-reading: BOOST_BEGIN_NAMESPACE((boost)(asio)(ip)) //namespace boost{namespace asio{namespace ip{ ... //to something BOOST_END_NAMESPACE((boost)(asio)(ip)) //}}} c++11 inline namespace also can work: inline BOOST_BEGIN_NAMESPACE((detail)) ... //to something BOOST_END_NAMESPACE((detail)) I wander to know whether this util could be a part of boost. Thanks a lot.

3 2

[thread|shared_ptr|atomic] segmentation fault in exception_ptr assignment
by Oliver Kowalke 24 Feb '13

24 Feb '13

I've replaced shared_ptr<> by intrusive_ptr<> + atomic< std::size_t > in boost.thread's future implementation. atomic< std::size_t > use_count; // initialized with '0' in ctor friend inline void intrusive_ptr_add_ref( future_continuation_base * p) BOOST_NOEXCEPT { ++p->use_count; // should be seq_cst } friend inline void intrusive_ptr_release( future_continuation_base * p) { if ( 0 == --p->use_count) // should be seq_cst delete p; } I get an error if I compile the code with gcc-4.7.2 on x86_64: segmentation fault backtrace: 0x0000000000426a96 in boost::detail::atomic_exchange_and_add (pw=0x436a40, dv=-1) at ../../../boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50 50 ); (gdb) bt #0 0x0000000000426a96 in boost::detail::atomic_exchange_and_add (pw=0x436a40, dv=-1) at ../../../boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50 #1 0x0000000000426ba7 in boost::detail::sp_counted_base::release (this=0x436a38) at ../../../boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:143 #2 0x0000000000426c57 in boost::detail::shared_count::~shared_count (this=0x7fffffffc868, __in_chrg=<optimized out>) at ../../../boost/smart_ptr/detail/shared_count.hpp:368 #3 0x0000000000427c3e in boost::shared_ptr<boost::exception_detail::clone_base const>::~shared_ptr (this=0x7fffffffc860, __in_chrg=<optimized out>) at ../../../boost/smart_ptr/shared_ptr.hpp:316 #4 0x000000000042b2cd in boost::shared_ptr<boost::exception_detail::clone_base const>::operator= (this=0x75df00, r=...) at ../../../boost/smart_ptr/shared_ptr.hpp:485 #5 0x0000000000427d6f in boost::exception_ptr::operator= (this=0x75df00, other=...) at ../../../boost/exception/detail/exception_ptr.hpp:73 #6 0x0000000000429a2f in boost::fibers::detail::future_object_base::mark_exceptional_finish_internal (this=0x75def0, e=..., lock=...) at ../../../boost/fiber/future.hpp:278 #7 0x000000000043749a in boost::fibers::detail::task_base<int>::owner_destroyed (this=0x75def0) at ../../../boost/fiber/future.hpp:1241 #8 0x000000000042e768 in boost::fibers::packaged_task<int>::~packaged_task (this=0x7fffffffc9b0, __in_chrg=<optimized out>) at ../../../boost/fiber/future.hpp:1341 called funtions: ~packaged_task() -> task_base::owner_destroyed() -> future_object_base::mark_exceptional_finish_internal() -> exception_ptr::operator=(excepton_ptr const&) -> shared_ptr -> shared_count -> sp_counted_base_gcc_x86 -> boost::detail::atomic_exchange_and_add() I'm wondering why a simple assignement of excpetion_ptr causes a segmentation fault if future's implementation uses intrusive_ptr + atomic + sequential - consistent ops instead of shared_ptr. Does someone have an explanation?

2 1

[thread] ~condition_variable_any verifications
by Tim Blechmann 24 Feb '13

24 Feb '13

hi, one of my project uses exit() to terminate the program. this is sometimes called while some threads are waiting on a global condition_variable_any. when calling exit(), this global variable is destroyed while other threads are still waiting on it, which causes BOOST_VERIFY to fire an assertion failure !pthread_cond_destroy(&cond). this scares the hell out of my users. i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure. thoughts? thnx, tim

4 5

[lexical_cast][math] can't unconditionally call math::changesign with long double
by Eric Niebler 24 Feb '13

24 Feb '13

lexical_cast is using math::changesign with long double regardless of whether BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS is defined or not. This is causing Boost.Test build problems (see here http://tinyurl.com/af5453h) I'm pretty sure this is a bug in lexical_cast, so I've opened a ticket: https://svn.boost.org/trac/boost/ticket/8162 I've assigned it to the last person to touch lexical_cast.hpp. Apologies if that's not right. There is no entry for lexical_cast in libs/maintainers.txt. -- Eric Niebler Boost.org http://www.boost.org

6 6

[tuple] - Move constructors for Tuple
by Moore, Andrew 23 Feb '13

23 Feb '13

Are there plans for move constructors/assignment operations in the tuples library?

4 8

Re: [boost] [thread] ~condition_variable_any verifications
by Martin Elzen 22 Feb '13

22 Feb '13

Because the standard exit function doesn't call destructors for 'temporary or automatic objects that exist at the time of the call' (see: http://msdn.microsoft.com/en-us/library/6wdz5232%28v=vs.80%29.aspx ) which just ... seems surprising, I prefer not to use it in C++ projects. So I think it's not necessarily a bad thing to re-write code to get rid of it.

1 0

New gil::io has been added
by Christian Henning 22 Feb '13

22 Feb '13

Hi all, I have successfully replaced the old gil::io extension with the new gil::io. The new io has been developed on and off over the last few years and I believe it's a great improvement over the old one. Before going into details I like thank everyone that has been helping me out along the way. I have learned a lot of things and I'm very grateful for the experience! There are numerous improvements and perhaps it's best to study the documentation before using it. Here are some noteworthy points that come to my mind: * updating code that uses the old version only requires to change the header from "boost/extension/io/jpeg_io.hpp" to "boost/extension/io/jpeg/jpeg_io_old.hpp" * new formats: bmp, pnm, raw, targa * read numerous meta information from images. See boost/gil/extension/io/png_tags.hpp for example. * use all sorts of file metaphers or file names, like FILE*, ifstream, stringstream, wstring, filesystem::path, etc * in-memory images are supported * read large images with a scanline_read_iterator * have access to the file format backend * etc. There are some items left for which I need help from the boost maintainers. * How do I hook up the gil::io documentation so it's build when all boost documentation is build? * Same for the test suite. * Should I update boost_release? Or should the new extension "simmer" for a while? Again thanks for everything, Christian

3 7

Re: [boost] boost serialization backwardscompatibility ofbinary archives broken
by Markus Henschel 22 Feb '13

22 Feb '13

> -----Original Message----- > > You didn't comment any part of my mail that proposed a fix for > > compatibility of archives prior to 1.42. Does that mean that you > > consider this issue solved or will you look into that later? > > Actually I'm afraid to touch it. But I'm willing to take a look at it. > Maybe you should add your patch and email (and maybe my > response) as a comment to one of the trac items which touch upon this > subject. Another benefit of this - and another reason that I left the items > open is that other people how had variations on this problem will get notified > when you append to the trac item and that might also be helpful. > > Robert Ramey I posted my analysis of the problem to this track item: https://svn.boost.org/trac/boost/ticket/4660#comment:51 I will provide a patch against the current svn trunk next week. May be it will be possible to reduce the problem to archives created by 1.44.0. Have a nice weekend

2 1

[flat_map] doxygen bug
by Steve Lorimer 22 Feb '13

22 Feb '13

Hi all The default types for 'Predicate' and 'Allocator' exposed to doxygen in flat_map are incorrect. See below ./flat_map.hpp: #ifdef BOOST_CONTAINER_DOXYGEN_INVOKED template <class Key ,class T ,class Pred = std::less< std::pair< Key, T> > <-- incorrect ,class A = std::allocator<T> > <-- incorrect #else template <class Key, class T, class Pred, class A> #endif class flat_map; ./container_fwd.hpp: template <class Key ,class T ,class Pred = std::less<Key> ,class A = std::allocator<std::pair<Key, T> > > class flat_map;

1 0

Problems with building quickbook docs
by Andrey Semashev 21 Feb '13

21 Feb '13

Hi, I'm having problems with building quickbook docs for my library. I have the using quickbook ; as well as doxygen, xsltproc and boostbook in my ~/user-config.jam. When I run: bjam -j 2 release link=static libs/log/doc I get the following error: .../boost-release/tools/build/v2/build/generators.jam:978: in try-one-generator-really *** argument error * rule object(generator)(a)60.run ( project name ? : property-set : sources + ) * called with: ( object(project-target)@1010 filters_reference-xml : object(property-set)@1387 : ) * missing argument sources .../boost-release/tools/build/v2/build/generators.jam:370:see definition of rule 'object(generator)(a)60.run' being called .../boost-release/tools/build/v2/build/generators.jam:1040: in try-one-generator .../boost-release/tools/build/v2/build/generators.jam:1254: in construct-really .../boost-release/tools/build/v2/build/generators.jam:1338: in generators.construct .../boost-release/tools/build/v2/build/targets.jam:1495: in construct .../boost-release/tools/build/v2/build/targets.jam:1298: in object(typed-target)(a)1058.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1164.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(typed-target)(a)1061.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1165.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(typed-target)(a)1062.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1166.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(install-target-class)(a)1065.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1167.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1399: in basic-target.compute-usage-requirements .../boost-release/tools/build/v2/build/alias.jam:47: in compute-usage-requirements .../boost-release/tools/build/v2/build/targets.jam:1319: in object(alias-target-class)(a)1068.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1168.generate .../boost-release/tools/build/v2/build/targets.jam:258: in object(project-target)(a)1010.generate .../boost-release/tools/build/v2/build-system.jam:736: in load .../boost-release/tools/build/v2/kernel/modules.jam:283: in import .../boost-release/tools/build/v2/kernel/bootstrap.jam:142: in boost-build .../boost-release/boost-build.jam:17: in module scope index.html libs/index.html more/getting_started.html tools/index.html I'm using the release branch. Does anyone know what the problem could be?

2 2

boost serialization backwards compatibility of binary archives broken
by Markus Henschel 21 Feb '13

21 Feb '13

Hello, in its current state boost serialization isn't able to read binary archives from older versions. The documentation states that there is a problem with version 1.42-1.44 but this is not the whole story. My archives from 1.34 don't work either. There are currently open bugs for this: https://svn.boost.org/trac/boost/ticket/4903 https://svn.boost.org/trac/boost/ticket/5567 https://svn.boost.org/trac/boost/ticket/4660 This situation has been like this for a very long time now. Comments of users even suggest not using binary archives or switching to another serialization library because of maintenance problems. I'm posting to this list as it seems like no one cares about these bug reports anymore. The least thing that should be done I think is to update the release notes. There are even patches in the bug reports that provide fixes although I don't know if they work for all situations. The current situation is quite uncomfortable for me as I have to patch every new boost version to get serialization working. What can be done to improve this situation? Thanks, Markus Henschel

2 5

[test][thread] double free or corruption
by Vicente J. Botet Escriba 21 Feb '13

21 Feb '13

Hi, before moving from Boost.Test to lightweight_test.hpp the following error occurred on Boost.Thread test_barrier. After the change the error has disappeared. The same kind of error occurs on all the test using Boost.Test Could other confirm that this error is on Boost.Test? Best, Vicente Sandia-gcc-4.7.1 ------------------------------------------------------------------------ Tests are run on Linux platform. ------------------------------------------------------------------------ Command Line run.py --proxy=http://wwwproxy.sandia.gov:80 --runner=Sandia-gcc-4.7.1 \ --bjam-toolset=gcc --pjl-toolset=gcc --toolsets=gcc-4.7.1 \ "--bjam-options=-j15 warnings=on warnings-as-errors=on" Test output: Sandia-gcc-4.7.1 - thread - test_barrier / gcc-4.7.1 Rev 82993 / Tue, 19 Feb 2013 08:14:00 +0000 *Report Time: *Tue, 19 Feb 2013 19:31:12 +0000 Compile [2013-02-19 08:54:27 UTC]: succeed "/sierra/Sntools/extras/compilers/gcc-4.7.1/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -Werror -g -pthread -fPIC -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier.o" "../libs/thread/test/test_barrier.cpp" Link [2013-02-19 08:54:27 UTC]: succeed "/sierra/Sntools/extras/compilers/gcc-4.7.1/bin/g++" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi" -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier" -Wl,--start-group "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier.o" "/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-4.7.1/debug/link-static/threading-multi/libboost_unit_test_framework.a" "/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0" "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0" "/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread Run [2013-02-19 08:54:27 UTC]: fail Running 1 test case... *** No errors detected *** glibc detected *** /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier: double free or corruption (out): 0x000000000f903530 *** ======= Backtrace: ========= /lib64/libc.so.6[0x30ab67245f] /lib64/libc.so.6(cfree+0x4b)[0x30ab6728bb] /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6(_ZNSsD1Ev+0x20)[0x2b123aaa5660] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421c1a] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421c34] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x42028f] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421b97] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421bca] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x47918f] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x478fb2] /lib64/libc.so.6(exit+0xe5)[0x30ab6334f5] /lib64/libc.so.6(__libc_start_main+0xfb)[0x30ab61d99b] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier(_ZNSt8ios_base4InitD1Ev+0x39)[0x4116d9] ======= Memory map: ======== 00400000-004f1000 r-xp 00000000 68:11 12550145 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier 006f1000-006f3000 rw-p 000f1000 68:11 12550145 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier 006f3000-006f6000 rw-p 006f3000 00:00 0 0f8fb000-0f91c000 rw-p 0f8fb000 00:00 0 [heap] 414fe000-414ff000 ---p 414fe000 00:00 0 414ff000-416ff000 rw-p 414ff000 00:00 0 416ff000-41700000 ---p 416ff000 00:00 0 41700000-41900000 rw-p 41700000 00:00 0 41a48000-41a49000 ---p 41a48000 00:00 0 41a49000-41c49000 rw-p 41a49000 00:00 0 41f6d000-41f6e000 ---p 41f6d000 00:00 0 41f6e000-4216e000 rw-p 41f6e000 00:00 0 4216e000-4216f000 ---p 4216e000 00:00 0 4216f000-4236f000 rw-p 4216f000 00:00 0 4236f000-42370000 ---p 4236f000 00:00 0 42370000-42570000 rw-p 42370000 00:00 0 42570000-42571000 ---p 42570000 00:00 0 42571000-42771000 rw-p 42571000 00:00 0 42771000-42772000 ---p 42771000 00:00 0 42772000-42972000 rw-p 42772000 00:00 0 42972000-42973000 ---p 42972000 00:00 0 42973000-42b73000 rw-p 42973000 00:00 0 42b73000-42b74000 ---p 42b73000 00:00 0 42b74000-42d74000 rw-p 42b74000 00:00 0 30ab200000-30ab21c000 r-xp 00000000 68:05 27394072 /lib64/ld-2.5.so 30ab41b000-30ab41c000 r--p 0001b000 68:05 27394072 /lib64/ld-2.5.so 30ab41c000-30ab41d000 rw-p 0001c000 68:05 27394072 /lib64/ld-2.5.so 30ab600000-30ab74e000 r-xp 00000000 68:05 27394073 /lib64/libc-2.5.so 30ab74e000-30ab94e000 ---p 0014e000 68:05 27394073 /lib64/libc-2.5.so 30ab94e000-30ab952000 r--p 0014e000 68:05 27394073 /lib64/libc-2.5.so 30ab952000-30ab953000 rw-p 00152000 68:05 27394073 /lib64/libc-2.5.so 30ab953000-30ab958000 rw-p 30ab953000 00:00 0 30aba00000-30aba82000 r-xp 00000000 68:05 27394266 /lib64/libm-2.5.so 30aba82000-30abc81000 ---p 00082000 68:05 27394266 /lib64/libm-2.5.so 30abc81000-30abc82000 r--p 00081000 68:05 27394266 /lib64/libm-2.5.so 30abc82000-30abc83000 rw-p 00082000 68:05 27394266 /lib64/libm-2.5.so 30ac200000-30ac216000 r-xp 00000000 68:05 27394078 /lib64/libpthread-2.5.so 30ac216000-30ac415000 ---p 00016000 68:05 27394078 /lib64/libpthread-2.5.so 30ac415000-30ac416000 r--p 00015000 68:05 27394078 /lib64/libpthread-2.5.so 30ac416000-30ac417000 rw-p 00016000 68:05 27394078 /lib64/libpthread-2.5.so 30ac417000-30ac41b000 rw-p 30ac417000 00:00 0 30ade00000-30ade07000 r-xp 00000000 68:05 27394095 /lib64/librt-2.5.so 30ade07000-30ae007000 ---p 00007000 68:05 27394095 /lib64/librt-2.5.so 30ae007000-30ae008000 r--p 00007000 68:05 27394095 /lib64/librt-2.5.so 30ae008000-30ae009000 rw-p 00008000 68:05 27394095 /lib64/librt-2.5.so 2b123a378000-2b123a37a000 rw-p 2b123a378000 00:00 0 2b123a37a000-2b123a387000 r-xp 00000000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a387000-2b123a587000 ---p 0000d000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a587000-2b123a588000 rw-p 0000d000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a588000-2b123a589000 rw-p 2b123a588000 00:00 0 2b123a589000-2b123a5ba000 r-xp 00000000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a5ba000-2b123a7b9000 ---p 00031000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a7b9000-2b123a7bc000 rw-p 00030000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a7bc000-2b123a7c0000 r-xp 00000000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a7c0000-2b123a9bf000 ---p 00004000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a9bf000-2b123a9c0000 rw-p 00003000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a9c0000-2b123a9c1000 rw-p 2b123a9c0000 00:00 0 2b123a9e6000-2b123a9e7000 rw-p 2b123a9e6000 00:00 0 2b123a9e7000-2b123aad1000 r-xp 00000000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123aad1000-2b123acd0000 ---p 000ea000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acd0000-2b123acd8000 r--p 000e9000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acd8000-2b123acda000 rw-p 000f1000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acda000-2b123acef000 rw-p 2b123acda000 00:00 0 2b123acef000-2b123ad04000 r-xp 00000000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123ad04000-2b123af03000 ---p 00015000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123af03000-2b123af04000 rw-p 00014000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123af04000-2b123af07000 rw-p 2b123af04000 00:00 0 7fff4d39e000-7fff4d3b3000 rw-p 7ffffffe9000 00:00 0 [stack] 7fff4d3f6000-7fff4d3fa000 r-xp 7fff4d3f6000 00:00 0 [vdso] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vsyscall] EXIT STATUS: 134 TinyUrl <javascript:make_tinyurl()>

1 0

[tuple] Functionals for tuple element access?
by Jan Hudec 21 Feb '13

21 Feb '13

Hello All, Doing some heavy template work on collections of pairs and tuples I came across the need for functors returning tuple and pair members. So I looked whether Boost has anything like that, but couldn't find any. Now the functors can be written using bind like: bind(_1, &TupleType::get<3>); bind(_1, &PairType::first); except that requires explicitly mentioning the tuple/pair type. Trying to use simply &boost::tuples::get<3, WHAT?!?!?> even failed for me as boost::tuples::get is actually a 3-argument template based on boost::tuples::cons, which looks like implementation detail I better not rely on. Besides bost methods involve pointer-to-{function,member}, which might interfere with inlining. So I think it would be convenient to have functions like this somewhere in boost: template <int N> struct getter { template <typename X> struct result; template <typename F, typename T> struct result<F(T &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type &type; }; template <typename F, typename T> struct result<F(T const &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type const &type; }; template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type & operator()(T &t) { return get<N>(t); } template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type const & operator()(T const &t) { return get<N>(t); } }; I would like to ask: 1. Would there be interest in adding this? Should I polish it up? 2. What would be good name and place for it (boost::tuples::getter)? 3. To support pairs, would it be preferred to specialize the N=0 and N=1 cases (unfortunately I don't see how to handle the result struct without copy-paste) or define separate first_getter and second_getter or something like that? 4. The definition of result with const and non-const reference was enough for my uses in boost::transform_value_property_map, but I suspect it does not cover all necessary cases (I need non-reference and rvalue reference for C++11 too, right?) My actual use-case was with boost::transform_value_property_map. I needed several property maps with the same set of keys, so I created one boost::associative_property_map with tuple values and splitted it to maps for the items using the above functor. Obviously nothing of this is needed with C++11 lambdas, but I am stuck having to support some obscure platforms like WinCE 4.2 and for it with MSVC++9.0. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

[range] [general] making member functions SFINAE-friendly
by Nathan Ridge 21 Feb '13

21 Feb '13

Hi, I recently came across a request to make iterator_range::size() SFINAE-friendly [1]. The respect in which it is not currently SFINAE-friendly is that it is only applicable to instantiations where I is a random-access iterator, but it is defined for all instantiations, and fails with a static assertion if I is not random-access. This makes it impossible to use SFINAE techniques to detect whether "r.size()" is valid where r is some iterator_range. The suggested workaround is to give iterator_range a base class, specialize this base class for random-access iterators, and only define size() in this specialization. I think this deficiency and workaround can be generalized to any template class 'C<T>' with a member function 'foo' that is only applicable for a subset of valid template arguments for 'T'. I am curious what the Boost community thinks about applying this workaround (factoring out the member function into a base class) as a general rule in such situations? Is making the member function SFINAE-friendly worth the decrease in readability? Are there other disadvantages to this workaround? Are there alternative ways of making such a function SFINAE- friendly that don't require introducing a base class? Finally, if the consensus is that such a workaround is not justified in general, is there any reason it should be justified specifically for iterator_range::size()? Regards, Nate [1] https://svn.boost.org/trac/boost/ticket/8011

15 49

[git] Should I commit to SVN or Git?
by Joaquín Mª López Muñoz 20 Feb '13

20 Feb '13

Hi, I'd like to commit some changes to one of my libs for delivery with Boost 1.54. Should I use SVN as always or begin now using Git for the commit? I've skimmed thru the Git transition project wiki and it doesn't seem to have anything on dates for SVN deprecation etc. Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

5 5

[thread] Is there interest in shared_lock_prioritized?
by Antony Polukhin 20 Feb '13

20 Feb '13

Hi, I've got a very basic implementation and tests of shared_lock_prioritized, that can be used like that: // Events are written down in order of // their execution in different threads shared_lock_prioritized<2 /*priorities count*/ > lock; // thread #1 // Lock with minimal priority lock_shared(); // thread #2 // Lock with minimal priority lock_shared(0); // thread #3 // Lock for writing with priority // greater than locks of threads 1 and 2 // Waits till already acquired locks in #1 and #2 finish // and then writes lock(1); // thread #4 // Will wait till thread #3 finishes, only then acquire lock lock_shared(0); Such shared lock gives us ability to manage order/priority of different lock attempts, we can make write locks have bigger priority that read locks, have multiple priorities writes (ordered write locks) and so on... Is there an interest in it? -- Best regards, Antony Polukhin

2 2

[PropertyMap] proposing compose_property_map
by Guillaume Pinot 19 Feb '13

19 Feb '13

Hi. Using boost graph, and particulary reverse_graph, I needed a compose_property_map adaptor. As it may be interesting to everyone, I propose my code. http://texitoi.eu/~texitoi/compose_property_map/ I had problems to find a good return type for the get() free function. The solution proposed here has the drawback of needing a copy constructible type for the value_type of the FPMap in the concept checks. I didn't find any other type for the get() function that pass the concept checks and that do not return stack variable, and avoid useless copy. The patch may not work completely as I am discovering the boost build system. I am open to any comment. Thanks.

2 4

[interprocess] atomic<offset_ptr>
by Tim Blechmann 19 Feb '13

19 Feb '13

hi ion, i was wondering, what would be the best way to provide an atomic<offset_ptr>? it cannot be used out of the box, as offset_ptr does not conform to the std/boost::atomic<> requirements. afaict, one would have to pre-compute the offset for a specific memory location when performing a compare_exchange or store and fix up the offset after an atomic load. to do that, it will probably be required to access some internals of the offset_ptr. also, if i'm going to work on it (not sure if i will have time), where shall the implementation go? in a way, i'd rather put it into interprocess than into atomic. thoughts? cheers, tim

2 2

[test] recent commit causing general failure
by Joaquín Mª López Muñoz 19 Feb '13

19 Feb '13

Boost.MultiIndex trunk tests fail all over with message errors like this: C:\...\boost/test/impl/test_main.ipp(39) : error C3861: 'BOOST_CHECK': identifier not found which is seemingly caused by the suppresion of an internal #include in a recent change to Boost.Test: https://svn.boost.org/trac/boost/changeset/82718#file5 Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 6

Tests failing?
by Marshall Clow 19 Feb '13

19 Feb '13

A bunch of my (String.Algo and Boost.Algo) tests are failing locally, with errors like: darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o In file included from ../../../libs/test/src/test_main.cpp:16: ../../../boost/test/impl/test_main.ipp: In member function 'void test_main_caller::operator()()': ../../../boost/test/impl/test_main.ipp:39: error: 'BOOST_CHECK' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o" "../../../libs/test/src/test_main.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o... Before I dive into this - is anyone else seeing this? Looking at the test results on the web site, it appears that Boost.Test is broken for several libraries. For example: http://www.boost.org/development/tests/trunk/developer/algorithm.html http://www.boost.org/development/tests/trunk/developer/crc.html http://www.boost.org/development/tests/trunk/developer/geometry.html -- 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

7 16

Re: [boost] (no subject)
by Vishnu M Menon 19 Feb '13

19 Feb '13

http://www.morguardlogistics.com/ssgd/uc9d53wpgmm.9z7a?nvb0jr11asciq Vishnu M Menon 2/19/2013 6:03:25 PM

1 0

[algorithm] gather.hpp include guard
by Ian Hobson 19 Feb '13

19 Feb '13

Hi, The include guard in boost/algorithm/gather.hpp on SVN is incorrect: #ifndef BOOST_ALGORITHM_GATHER_HPP #define ADOBE_ALGORITHM_GATHER_HPP Best, Ian

2 1

Release Managers: permission to merge small feature to release?
by Marshall Clow 19 Feb '13

19 Feb '13

I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array. I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks. This is technically not a bug fix, but new functionality, but I'd like to get it into the next release. So, I'm asking permission to merge to release. The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs) Thanks! -- Marshall

5 5

Cannot commit due to "svn:mime_type is not set"
by Christian Henning 18 Feb '13

18 Feb '13

Hi there, I'm trying to commit the gil::io test suite and I get the following errors: Error: Commit failed (details follow): Error: Commit blocked by pre-commit hook (exit code 1) with output: Error: /home/subversion/boost/hooks/check-mime-type.pl: Error: Error: trunk/libs/gil/io/test_images/bmp/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/png/PngSuite/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/pnm/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/raw/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/targa/fileformat.info/readme.txt : svn:mime-type Error: is not set Error: trunk/libs/gil/io/test_images/tiff/graphicmagick/readme.txt : svn:mime-type is Error: not set Error: trunk/libs/gil/io/test_images/tiff/libtiffpic/readme.txt : svn:mime-type is not Error: set Error: Error: Error: Every added file must have the svn:mime-type property set. In Error: addition text files must have the svn:eol-style property set. Error: Error: For binary files try running Error: svn propset svn:mime-type application/octet-stream path/of/file Error: Error: For text files try Error: svn propset svn:mime-type text/plain path/of/file Error: svn propset svn:eol-style native path/of/file Error: Error: You may want to consider uncommenting the auto-props section Error: in your ~/.subversion/config file. Read the Subversion book Error: (http://svnbook.red-bean.com/) Chapter 7, Properties section, Error: Automatic Property Setting subsection for more help. Also, Error: see http://svn.boost.org/trac/boost/wiki/BoostSubversion I'm using Tortoise subversion and in my configuration file I set the mime types as follows: *.txt = svn:eol-style=native;svn:keywords=Author Date Id Rev URL;svn:mime-type=text/plain *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg *.bmp = svn:mime-type=image/bmp *.tga = svn:mime-type=image/tga *.tif = svn:mime-type=image/tiff Can someone help out, please. Thanks, Christian

2 2

[type_erasure] Overloading
by Christophe Henry 18 Feb '13

18 Feb '13

Hi Steven, I'm afraid I might need some help again. I try to take as model the example in the doc (http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure…) First problem, it seems that the example has a typo. It will not compile without a :Base in the concept_interface specialization: struct concept_interface< ::foo<T, U,void>, Base, T, Enable> : Base ... Second, the example overload.cpp includes a as_param.hpp which no more exists. But my problem is that I need an overload with 1 and 2 parameters: Test t; any< mpl::vector< foo<_self, int>, foo<_self, int, double>, boost::type_erasure::copy_constructible<> > > x (t); x.foo(1); // calls foo(int) x.foo(1,1.0); // calls foo(int, double) I don't get this to compile, the second foo cannot be found, I suppose the first one hides the second. Thanks in advance, Christophe Here my failed attempt (well, one of them ;-) ): template<class T, class U, class V=void, class Enable=void> struct foo {}; template<class T, class U, class V> struct foo<T,U,V,typename boost::disable_if<boost::is_same<V,void> >::type > { static void apply(T& t, const U& u, const V& v) { t.foo(u,v); } }; template<class T, class U, class V> struct foo<T,U,V,typename boost::enable_if<boost::is_same<V,void> >::type > { static void apply(T& t, const U& u) { t.foo(u); } }; namespace boost { namespace type_erasure { template<class T, class U, class Base, class Enable> struct concept_interface< ::foo<T, U,void>, Base, T, Enable> : Base { typedef void _fun_defined; void foo(typename rebind_any<Base, const U&>::type arg) { call(::foo<T, U, void>(), *this, arg); } }; template<class T, class U, class V, class Base> struct concept_interface< ::foo<T, U,V>, Base, T, typename Base::_fun_defined> : Base { using Base::foo; void foo(typename rebind_any<Base, const U&>::type arg, typename rebind_any<Base, const V&>::type arg2) { call(::foo<T, U,V>(), *this, arg,arg2); } }; } } struct Test { void foo(int) { std::cout << "foo(int) called" << std::endl; } void foo(double) { std::cout << "foo(double) called" << std::endl; } void foo(int,double) { std::cout << "foo(int,double) called" << std::endl; } }; int main() { Test t; any< mpl::vector< foo<_self, int>, foo<_self, int, double>, boost::type_erasure::copy_constructible<> > > x (t); x.foo(1); // calls foo(int) x.foo(1,1.0); // calls foo(int, double) return 0; }

2 2

*BSD detail/endian.hpp header patch looking for review
by Brad Smith 18 Feb '13

18 Feb '13

Hi, There is a patch for the detail/endian.hpp header for *BSD OS's in ticket 6013 that needs review and to be commited. Anyone able to help out here? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 9

Re: [boost] [geometry] Documentation building
by Alexey Kutumov 18 Feb '13

18 Feb '13

> I'm working on CMake'fication of boost libraries, and i 've got issue when > > building documentation of Boost.Geometry. This library uses > doxygen_xml2qbk > > utility for convertiong doxygen XML to quickbook, and this utility uses > > RapidXML for xml processing. I found rapidxml in Boost.PropertyTree > > library, but it is in detail subdirectory and also have different > > namespaces (`boost::property_tree::detail::rapidxml` vs `rapidxml`) > > > > Can i use rapidxml from PropertyTree library, or i must write CMake > script > > for searching rapidxml as thirdparty library? > > Unfortunately they're not interchangeable. PropertyTree has rapidxml in > boost::property_tree::detail namespace and in the "official" release it > is in global namespace. The doxygen_xml2qbk currently assumes that the > "official" one is used. > > Aside from this. During my work on the spatial index library I've > developed an version of this tool which supports additional doxygen > features like paragraphs, warnings, text formatting and automatic > references. You might check it out. It can be found here: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/src/tool… > > If --output_style alt is passed as a parameter like in > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/make_qbk… > > the alternative qbk is generated for a class or a group. > > The example of a reference which structure is defined here: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/rtree/re… > > looks like this: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/html/geo… Thanks for responce, i'll try these changes. I'm not sure whether my sources is up to date, but i made some changes, you can find them here: https://github.com/boost-cmake/geometry/tree/master/doc/src/docutils/tools/… * Added optional parameter with output file (it is needed for CMake script). * Also i fixed issue with brackets in description (added proper escaping).

1 0

[algorithm] adjacent_for_each interest?
by Ian Hobson 18 Feb '13

18 Feb '13

Hi, Is there any interest in a version of for_each that operates on each adjacent pair of elements in a range? #include <iostream> #include <boost/algorithm/adjacent_for_each.hpp> void PrintInts(int a, int b) { std::cout << '(' << a << ", " << b << ")\n"; } int main() { const int ints[] = {0, 1, 2, 3, 4}; boost::algorithm::adjacent_for_each(ints, ints + 5, PrintInts); } Output: (0, 1) (1, 2) (2, 3) (3, 4) Initial implementation available at http://github.com/irh/adjacent_for_each Best, Ian

7 18

[git] Bad superproject.
by Rene Rivera 18 Feb '13

18 Feb '13

In trying to use the new boost git superproject there's a reference to a non-existent subrepo "boostorg/spirit_classic.git". This of course makes it impossible to do a full clone. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 4

[Test] Allowing assert to break into debugger
by Alexander Lamaison 18 Feb '13

18 Feb '13

Normally when debugging a program in Visual Studio 2005, the debugger will let the user break the program if it asserts. But when the program in a Boost.Test runner, that doesn't happen. In this thread [1] other people report the same problem but Gennadiy says that it should work. Was this ever fixed? I'm using Boost 1.50. [1] http://boost.2283326.n4.nabble.com/BOOST-ASSERT-any-one-against-improving-d… Thanks, Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 0

[Installer] Windows 1.51 installer is broken
by Alexander Lamaison 18 Feb '13

18 Feb '13

I'm not sure who's dealing with this now, but the installer for 1.51 on Windows is broken with multiple File Not Found (404) errors. The sourceforge directory it tries to access seems to not be a real folder. Or at least it appear strangely when browsed: http://sourceforge.net/projects/boost/files/boost-binaries/ Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 0

[gil::io] Objections to replace gil::io
by Christian Henning 17 Feb '13

17 Feb '13

I'm ready to replace the old gil:io extension with the new version. Does anyone have any objections? Thanks, Christian

1 0

[website] SSL certificate for *.boost.org has expired
by Lars Viklund 17 Feb '13

17 Feb '13

It seems like the certificate for *.boost.org expired on the 16th, I'd reckon it's time to renew it and review the routines for renewing it in time. -- Lars Viklund | zao(a)acc.umu.se

2 1

[serialization] Limited Forward Compatibility
by Dmitry Shesterkin 17 Feb '13

17 Feb '13

Hello, We use xml serialization for saving and loading several types of metadata and we have to support possibility of reading new versions of files with old versions of soft. Boost::serialization is very good at backward compatibility but does not provide anything with opposite problem. So, This patch introduces new flag boost::archive::skip_unknown_tail_tags. When this flag is set and basic_xml_iarchive is faced with unknown tags at the end of element it will skip them (include nested). E.g., the first version of some file was: <Test class_id="0" tracking_level="0" version="0"> <a>31</a> <t2 class_id="1" tracking_level="0" version="0"> <a>11</a> 12 </t2> 32 </Test> After a while, the second version could be: <Test class_id="0" tracking_level="0" version="0"> <a>31</a> <t2 class_id="1" tracking_level="0" version="1"> <a>11</a> 12 <c>13</c> <d>14</d> <t1 class_id="2" tracking_level="0" version="0"> <a>1</a> 2 </t1> </t2> 32 </Test> Therefore, if the first version software set skip_unknown_tail_tags it can read second version of file (if does not set then exception will be thrown). See patch in attachments for details. Could it be useful, and should it be merged in trunk? Thanks in advance, Dmitry

2 3

[geometry] Documentation building
by Alexey Kutumov 17 Feb '13

17 Feb '13

I'm working on CMake'fication of boost libraries, and i 've got issue when building documentation of Boost.Geometry. This library uses doxygen_xml2qbk utility for convertiong doxygen XML to quickbook, and this utility uses RapidXML for xml processing. I found rapidxml in Boost.PropertyTree library, but it is in detail subdirectory and also have different namespaces (`boost::property_tree::detail::rapidxml` vs `rapidxml`) Can i use rapidxml from PropertyTree library, or i must write CMake script for searching rapidxml as thirdparty library?

2 1

[atomic] errors since the introduction of constexpr noexcept.
by Vicente J. Botet Escriba 17 Feb '13

17 Feb '13

Hi, There are some errors since the introduction of constexpr noexcept. Could you apply this patch? Best, Vicente svn diff boost/atomic Index: boost/atomic/detail/cas64strong.hpp =================================================================== --- boost/atomic/detail/cas64strong.hpp (revision 82919) +++ boost/atomic/detail/cas64strong.hpp (working copy) @@ -13,6 +13,7 @@ // atomic, so they are funnelled through cmpxchg as well. #include <cstddef> +#include <boost/config.hpp> #include <boost/cstdint.hpp> #include <boost/memory_order.hpp> #include <boost/atomic/detail/config.hpp> @@ -34,7 +35,8 @@ typedef T value_type; typedef T difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + int xxx; + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void @@ -158,7 +160,7 @@ typedef void * value_type; typedef ptrdiff_t difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void @@ -253,7 +255,7 @@ typedef T * value_type; typedef ptrdiff_t difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void Index: boost/atomic/detail/gcc-x86.hpp =================================================================== --- boost/atomic/detail/gcc-x86.hpp (revision 82919) +++ boost/atomic/detail/gcc-x86.hpp (working copy) @@ -1621,7 +1621,7 @@ template<typename T> inline T -platform_load64(const volatile BOOST_NOEXCEPT T * ptr) +platform_load64(const volatile T * ptr) BOOST_NOEXCEPT { T expected = *ptr; for (; !platform_cmpxchg64_strong(expected, expected, const_cast<volatile T*>(ptr));)

2 3

[mixin] Introducing a new library.
by Borislav Stanimirov 17 Feb '13

17 Feb '13

Hello, Boost.Mixin is a library I'm developing with the idea to someday submit it to Boost. It is an entity-component system, with full abstraction between interface and implementation. In short, users can define objects by combining components (often referred to from here on out as mixins). A mixin is a regular C++ class for which two macros are defined. The main thing however are the messages. Instead of getting the component with some function like `get_component` (which is possible but discouraged in the library), users deal with objects only. They can call messages (inspired by Smalltalk's messages) which are dynamically dispatched to the appropriate mixin. The messages (also defined with macros) are the only thing needed for a user to call methods from the object's mixins. When defining a mixin, the user tells which messages it's going to implement, and when adding this mixin to the object a virtual table of sorts is filled and the object starts responding to those messages by calling the mixin's actual C++ methods. Some of the key features are: * Multicast messages. A message that is implemented and handled by more than one mixin. See the message `trace` in the example. (As opposed to unicast messages, that are handled by a single mixin) * Object access from within the mixin. The macro `bm_this` (Boost.Mixin this). See the renderer do in the example. * "Live" object mutation by adding and removing mixins. As demonstrated in `change_rendering_system` in the example. This is done via the `object_transformer` class and is currently the only way of adding mixins to objects. * Mixin (and message) domains. The domain is a collection of mixins and messages that work together. If you create a set of mixins that will never conceivably have to exist in the same object as another set of mixins, you should use a different domain. Here is a github link to the library: http://github.com/iboB/boost.mixin A working example can be found here: http://github.com/iboB/boost.mixin/tree/master/libs/mixin/example/basic The example is nothing more than some objects and mixins working together as they would hypothetically in a simple game. All "game" code has been shortcut to text outputs like: "right now an object is being rendered by the d3d renderer". The example demonstrates most of the currently supported library features. There is no jamfile yet. I develop it with Qt Creator and Code::Blocks in Linux and MS Visual Studio Express 2008 and 2012 in Windows (the Windows projects might be somewhat outdated), so the are project files for these four in libs/mixin/build. The same goes for the example. I'd qualify the current state of the library as pre-alpha, so it might have some bugs. I also create a small performance testing project (much more is to be added). It calls a regular function, a virtual function, `std::function` and a unicast mixin message a hundred million times. So far I'm generally happy with the performance, which is not to say that I won't be working on improving it. Still my computer is the only one I've tested it on and I'd be happy if somebody else tries the perf project. Here are my results: 100,000,000 x | Debug t | Release t ------------------------------------------ regular method | 781 ms | 211 ms virtual method | 639 ms | 253 ms `std::function` | 10695 ms | 272 ms Mixin message | 3298 ms | 865 ms It should also be noted that currently the library depends on a piece of code from Don Clugston's fastdelegate (found here: http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-F…) The piece in question has been copy-pasted verbatim (wrapped around in the boost::mixin namespace) in the third_party subfolder. Don Clugston has done a wonderful job of creating a platform-independent representation of C++ methods as a pair of pointers. Boost.Mixin heavily relies on such a thing for its virtual tables. For now I am the only developer of the library. Zahary Karadjov (credited in the license) hasn't written anything in it yet, but he is responsible for most of the library's public interface design, the idea to reuse fastdelegate, and the ideas and implementation suggestions for many of the roadmap features listed below. The programming languages Smalltalk, Ruby, and, to a degree, Objective C have also influenced the design. So, here is a project roadmap of sorts: 1. Soon: * Overloaded messages - messages that call overloaded functions. The message's name is different for each overload but the calling function remains the same * Work on more sensible (and helpful) runtime and compile-time errors. Missing messages, ambiguous message priority, etc. * Add multicast result collectors. Like `and` or `or` for boolean return values. Like `sum` for numeric values. Sample usage some_multicast_message(obj, p1, p2, boost::mixin::sum). User-defined result collectors will be possible. * Add a new mixin feature `fact`. Facts are static const variables in a mixin. No multicasts. No virtual tables. * Add object type templates. Instead of manually transforming each object, you would be able to call `type_template::new_object()` * Add more graceful runtime error handling: default message implementations (if none is provided), more specific non-breaking exceptions * Rigorous unit tests * Performance tests * Tutorials 2. Later: * Boost.Jam build files * Full reference documentation * Formal submission to Boost?? * Call mixin constructors when mutating object or constructing them via object type templates. Sample usage: `mutate(obj).add<mixin>("foo", param2).add<other_mixin>(42)` * Reduce library memory footprint * Optional external allocators per domain. Every memory allocation should pass through them. * Make use of the fact that a BIG execution time improvement can be made if a user has no mixins or messages defined in a dynamic library (and has no plans to add such) * Integration with Boost.Serialization. As long as the mixins of an object are serializable, the object will be, too. * "Static" mixins. As long as they're not mutated in or out, it provides a faster message execution. * Reflection. Create objects with mixins by string. Call messages by string. * Object mutation injections. Automatically add some mixins when others are present. Substitute a mentioned mixin with another. Ban a mixin from being added to an object. 3. When humankind becomes a Kardashev type two civilization: * Integration with Boost.Thread. Call messages for a specific thread. * User-defined message hooks. Sample implementation with messages called on objects on another device through Boost.Asio. * A way to mutate static mixins in and out. Slight mutation execution penalty. * Some magic to make it work even faster. * Integration with Boost.Python and luabind. * Remove C++03 backward compatibility???? * Library being accepted in Boost???? I think I will be done with the items form list one by April (some of them are even semi-implemented) and with the items of list two by the end of the year (and if I have more free time maybe even sooner). As for the items in the this list... well... they are nice to think about. I do have at least some vague ideas for each of them, but then again, this is list three. Any questions, comments, and suggestions are welcome. ------ Borislav Stanimirov ------ PS: Whoa. I'm sorry this post turned out so long. I didn't expect it to.

6 22

[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

Track system Connection failing
by Vicente Botet 16 Feb '13

16 Feb '13

While connecting to the Trac system https://svn.boost.org/trac/boost/newticket I'm getting svn.boost.org uses an invalid security certificate. The certificate expired on 16/02/2013 17:02. The current time is 16/02/2013 17:25. (Error code: sec_error_expired_certificate) Could others confirm this behavior? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Track-system-Connection-failing-tp464291… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[array] failures in c++11 mode
by Tim Blechmann 15 Feb '13

15 Feb '13

hi, r82834 seems to break compilation of boost.array when compiled in c++11 mode: ../../../boost/array.hpp:131:9: error: body of constexpr function ‘constexpr const T& boost::array<T, N>::operator[](boost::array<T, N>::size_type) const [with T = boost::heap::detail::skew_heap_node<q_tester, false>*; long unsigned int N = 2ul; boost::array<T, N>::const_reference = boost::heap::detail::skew_heap_node<q_tester, false>* const&; boost::array<T, N>::size_type = long unsigned int]’ not a return-statement the boost.heap testsuite exposes this failure: http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-4-… thnx, tim

5 9

setting <cxxflags> and <linkflags> in Jamfile?
by Oliver Kowalke 14 Feb '13

14 Feb '13

Hello, if the define BOOST_USE_XYZ is given at b2/bjam command-line how can I set special compiler- and linker-flags in the Jamfile? something like this: Jamfile.v2: *project boost/abc : requirements <toolset>gcc-4.7,<defined>BOOST_USE_XYZ:<cxxflags>-fxyz <toolset>gcc-4.7,<defined>BOOST_USE_XYZ:<linkflags>"-static-libxyz" <link>static <threading>multi : source-location ../src : usage-requirements <link>shared:<define>BOOST_ABC_DYN_LINK=1 ; * if the lib is build with b2 toolset=gcc cxxflags="-DBOOST_USE_XYZ" then -fxyz static-libxyz is applied to the compiler otherwise not. How can I achieve this behaviour? best, Oliver

2 2

Re: [boost] [smart ptr] Any interest in copy-on-write pointer for C++11?
by Andreas Pfaffenbichler 14 Feb '13

14 Feb '13

hi ralph! a heavy argument for a 'COW' pattern is made here: http://cppnow.org/session/value-semantics-and-concepts-based-polymorphism ( 'copy_on_write' class template included). maybe it could be interesting to compare your 'cow_ptr' to this 'copy_on_write'. but no doubt: the direct support of 'COW' in boost would fill e need thank you for your efforts! best regards andreas pfaffenbichler

7 20

[gil] ToolBox uploaded
by Christian Henning 14 Feb '13

14 Feb '13

Hi all, I finally have managed to upload the "toolbox" extension for boost::gil. The toolbox provides some helpful extension for gil that are too small to be an extension themselves. There are: * color spaces: cmyka, gray_alpha, hsl, hsv, lab, xyz * metafunctions: channel_type_to_index, is_bit_aligned, is_similar, is_homogeneous, get_num_bits, channel_type, get_pixel_type, pixel_bit_size * image types: indexed_image * color converters: gray -> rgba I would need some help hooking up the tests and doc generation. Let me know if you any questions or improvements. Regards, Christian

3 9

Relational database library (was: [GSOC] Are we going to participate?)
by Mateusz Loskot 14 Feb '13

14 Feb '13

On 14 February 2013 09:40, Roland Bock <rbock(a)eudoxos.de> wrote: > On 2013-02-14 06:04, Michael Marcin wrote: >> - relational database library (what ever happened with boost and soci?) > FYI: > I am currently working on a C++11 SQL library. Once you declare your > table structures in C++, it will allow you to express queries very close > to SQL: For example: > > TabSample t; > auto results = sql::select(sql::distinct, t.b, t.c) > .from(t) > .where(t.a > 7 and t.b != "cheesecake") > .order_by(t.c).run(db); > > for (auto row: results) > { > int a = row.a; > std::string c = row.c; > } > > The library will take care of escaping (to prevent code injection), the > compiler will enforce type safety (e.g. disallow comparison of integral > and string values). There will also be a lot of sanity checks at compile > time, for instance you cannot call .from() twice. It will even be able > to tell you, if you are referencing tables, which are missing in > .from(), etc. > > No more string concatenation and hoping to get the syntax right. The > compiler will tell you, if you do it wrong. > No more indexed access to string results. Result rows will allow you to > access individual columns by name (and they will have a decent type). > [...] Roland, It all sounds exciting. I remember the discussion long time ago we had, with similar ideas brainstormed [1], where you also asked this question, later discussed with Maciej: "Maybe it would make sense to add such a layer as an option to SOCI?" FYI, in SOCI, we're planning [2] to move SOCI towards C++11 It likely may happen during SOCI 4.0.0 release. So, I'd be interested in taking another look at this and having such layer adopted in SOCI too. Where I could learn about your solution more? [1] http://lists.boost.org/Archives/boost/2010/09/170983.php [2] https://github.com/SOCI/soci/wiki/Roadmap Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Git] Documentation update
by Beman Dawes 14 Feb '13

14 Feb '13

The "Git and Modular Boost" documentation has been updated: * The GitHub mothership with be github.com/boostorg * Full history for the current trunk and branches/release will be available. * There are now active milestone and issue trackers for the conversion. See https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost --Beman

10 31

adding comment to boost_1_54_0.qbk?
by Oliver Kowalke 14 Feb '13

14 Feb '13

Is it allowed to add an entry for updated libraries in public_html/live/feed/history/boost_1_54_0.qbk? Oliver

2 1

[smart ptr] Any interest in copy-on-write pointer for C++11?
by Ralph Tandetzky 14 Feb '13

14 Feb '13

Hi, is there any interest in a copy-on-write pointer implementation? I wrote a cow_ptr<T> template class for C++11 which has the following use cases: 1. They are well suited as pimpl pointers for classes with value semantics. With most other smart pointers it is always necessary to reimplement the copy constructor, and the copy assignment operator, sometimes also the destructor. This is not necessary here and you'll get the right semantics and even the additional performance gain due to lazy copying. A futher advantage is that constness of cow pointer member functions propagates to the Impl object naturally making it easier to write const-correct code. // central_class_with_value_semantics.h class CentralClassWithValueSemantics { public: // ... public interface goes here ... // private: struct Impl; // forward declaration cow_ptr<Impl> m; }; // central_class_with_value_semantics.cpp struct CentralClassWithValueSemantics::Impl { // ... definition of hidden members goes here ... // } This is called the pimpl idiom, or private implementation idiom, handle body idiom, or compiler firewall idiom. 2. For classes with members whose copy-operations are expensive and/or which take a lot of space in memory, these members can be wrapped in a cow pointer. An example are matrix or image classes whose data might be stored in a std::vector. The matrix header information may be changed without deep copy. This boosts performance and optimizes memory usage, but at the same time retains the value semantics one feels comfortable with. class Matrix { public: // ... public interface goes here ... // private: size_t nRows, nCols; // can be touched without deep copy. cow_ptr<std::vector<float>> data; // copy-on-write } In such classes the default version of copy and move construction will usually work just fine. 3. You can add cloning to a class hierarchy from the outside. With cow_ptr<Base> a( new Derived1 ); cow_ptr<Base> b( new Derived2 ); cow_ptr<Base> c; c = a; // performs a shallow copy. c->doSomething(); // makes a deep copy of a as a Derived1 class. // There is no slicing involved. you copy Base objects polymorphically. The class Base can even be abstract here. It is only required that Derived1 and Derived2 be CopyConstructible. 4. You can create arrays with elements that retain polymorphic behaviour and have genuine value sematics at the same time with std::vector<cow_ptr<Base>> polymorphic_array_with_value_semantics; -- There are probably other use cases. I published the code on github ( https://github.com/ralphtandetzky/cow_ptr) Any suggestions for improvements would be greatly appreciated. Regards, Ralph Tandetzky.

10 42

[container] varray aka static_vector
by Andrew Hundt 13 Feb '13

13 Feb '13

As Adam mentioned in an earlier thread we have renamed static_vector to varray to better represent how it works like an array with size without requiring the values to be default constructible, and to better distinguish it from hybrid_vector. varray location: https://svn.boost.org/svn/boost/sandbox/varray/ Documentation: https://svn.boost.org/svn/boost/sandbox/varray/doc/html/index.html One open question is if the 3rd strategy parameter should be public or in the detail namespace. Based on some of the feedback we moved the strategy from container to container_detail, and made the public version varray<typename T, std::size_t N>. However, we wanted to get others' thoughts on this change. Additionally, should primitives be default initialized with the contents of memory like an array or value initialized to 0 like a standard container in the constructor, resize(), and emplace_back()? Generally, built-in types are initialized when the constructor is called explicitly. For example: int a; // a has the value of underlying memory int b = int(); // b has a value of 0 Right now the default behavior of our container is more like a vector than an array when creating values using the default ctor. Default constructable values are explicitly initialized in the varray ctor, resize(), emplace() and emplace_back() functions, even when they are trivially constructable. We find this behavior more intuitive and therefore we have made it the default. If the performance needs to be improved slightly the behavior may be changed or disabled in container_detail::varray_traits<V, C, S>. Here is an example demonstrating the current default behavior: vector<int> vec(3); varray<int, 3> varr(3); array<int, 3> arr; vec[0] == varr[0] and vec[0] != arr[0] Any feedback is very much appreciated. Cheers! Andrew Hundt Adam Wulkiewicz

5 19

[bind] Boost.Bind compile error with msvc-11 and msvc-10
by Ian Emmons 13 Feb '13

13 Feb '13

I have attached a short, self-contained test case that uses Boost.Bind. this test case compiles and runs correctly with the following tool sets: darwin (gcc 4.2.1 on MacOS 10.8) clang (clang on MacOS 10.8) gcc (gcc 4.7 on Ubuntu 12.04) msvc-9 (Visual Studio 2008 on Windows 7) It fails to compile on these: msvc-11 (Visual Studio 2012 on Windows 7) msvc-10 (Visual Studio 2010 on Windows 7) I have also attached the error messages from msvc-11, which seem to indicate that Boost.Bind is the problem. Can anyone shed any light on this issue? Is this an error in my usage of Boost.Bind? A Boost.Bind bug? A Visual Studio bug? Something else? Thanks, Ian

6 7

[Contract] Eagerly waiting...
by Robert Jones 13 Feb '13

13 Feb '13

Hi Lorenzo (or anyone who knows) AFAICS your contract library seems to have been approved for a while, but not made it into a release. Do you have an ETA for this? Thx, Rob.

2 1

[container] boost::container::vector, hybrid_vector, and performance
by Andrew Hundt 13 Feb '13

13 Feb '13

After some of the varray discussion and interest in hybrid_vector I modified an existing synthetic benchmark from the C++Next site (cpp-next.com) to test varray, boost::container::vector, boost::container::vector<T, stack_allocator>, and std::vector. Essentially for each container it times constructing a container of containers of primitives, std::sort, std::rotate, and destruction. Note that the test calls reserve() when setting up each container so that each gets a fair shot and isn't unfairly bogged down by a simple allocation optimization. The short results summary: varray was generally at or near the top for performance due to its simplicity, and interestingly on almost all platforms std::vector significantly outperformed boost::container::vector, which edged out boost::container::vector<T, stack_allocator>. Of course these are synthetic tests of only a subset of these containers’ functionality using only primitives so it should not be construed to necessarily represent the performance of these containers for other uses. Nonetheless I thought it may be interesting for discussion. There is also an additional benchmark of Adam Wulkiewicz’s rtree using linux clang comparing varray, container::vector, and std::vector with similar results. One question this leads me to ask is if someone might be able to illustrate a significant advantage hybrid_vector could have over boost::container::vector<T, stack_allocator>? The test can be found at: https://svn.boost.org/svn/boost/sandbox/varray/example/bench_varray.cpp Results are below. Cheers! Andrew Hundt --------------------------------------------------------------------------------------------------------------------------- Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix Processor 2.2 GHz Intel Core i7 Memory 16 GB 1333 MHz DDR3 Software OS X 10.8.2 (12C60) --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 17000000 bytes N = 1000 varray benchmark: construction took 10.576854s wall, 10.580000s user + 0.020000s system = 10.600000s CPU (100.2%) sort took 4.323139s wall, 4.290000s user + 0.010000s system = 4.300000s CPU (99.5%) rotate took 0.909033s wall, 0.910000s user + 0.000000s system = 0.910000s CPU (100.1%) destruction took 0.000725s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 15.824697s wall, 15.780000s user + 0.040000s system = 15.820000s CPU (100.0%) boost::container::vector benchmark construction took 11.656541s wall, 11.180000s user + 0.320000s system = 11.500000s CPU (98.7%) sort took 5.213782s wall, 4.940000s user + 0.000000s system = 4.940000s CPU (94.7%) rotate took 0.003201s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (312.4%) destruction took 2.482177s wall, 0.640000s user + 2.000000s system = 2.640000s CPU (106.4%) done Total time = 19.367074s wall, 16.770000s user + 2.330000s system = 19.100000s CPU (98.6%) boost::container::vector benchmark with stack_allocator construction took 11.698265s wall, 11.110000s user + 0.430000s system = 11.540000s CPU (98.6%) sort took 5.227070s wall, 5.180000s user + 0.000000s system = 5.180000s CPU (99.1%) rotate took 0.003778s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (264.7%) destruction took 2.493007s wall, 0.510000s user + 1.900000s system = 2.410000s CPU (96.7%) done Total time = 19.433571s wall, 16.810000s user + 2.340000s system = 19.150000s CPU (98.5%) std::vector benchmark construction took 11.605458s wall, 11.400000s user + 0.300000s system = 11.700000s CPU (100.8%) sort took 2.256151s wall, 2.250000s user + 0.000000s system = 2.250000s CPU (99.7%) rotate took 0.003200s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 2.498035s wall, 0.370000s user + 2.040000s system = 2.410000s CPU (96.5%) done Total time = 16.374640s wall, 14.020000s user + 2.350000s system = 16.370000s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 0.817093 user = 0.940966 system = 0.0171674 (user+system) = 0.828272 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.814297 user = 0.938727 system = 0.017094 (user+system) = 0.82611 varray/std::vector total time comparison: wall = 0.966415 user = 1.12553 system = 0.0170213 (user+system) = 0.966402 --------------------------------------------------------------------------------------------------------------------------- Windows VS2012 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- N = 1000 varray benchmark: construction took 18.901735s wall, 18.798121s user + 0.000000s system = 18.798121s CPU (99.5%) sort took 3.093771s wall, 3.260421s user + 0.000000s system = 3.260421s CPU (105.4%) rotate took 0.336938s wall, 0.280802s user + 0.000000s system = 0.280802s CPU (83.3%) destruction took 0.000270s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 22.339054s wall, 22.339343s user + 0.000000s system = 22.339343s CPU (100.0%) boost::container::vector benchmark construction took 18.757410s wall, 18.595319s user + 0.202801s system = 18.798121s CPU (100.2%) sort took 0.120896s wall, 0.140401s user + 0.000000s system = 0.140401s CPU (116.1%) rotate took 0.004482s wall, 0.015600s user + 0.000000s system = 0.015600s CPU (348.0%) destruction took 0.282280s wall, 0.046800s user + 0.171601s system = 0.218401s CPU (77.4%) done Total time = 19.167624s wall, 18.798121s user + 0.374402s system = 19.172523s CPU (100.0%) boost::container::vector benchmark with stack_allocator construction took 18.811076s wall, 18.361318s user + 0.312002s system = 18.673320s CPU (99.3%) sort took 0.134590s wall, 0.218401s user + 0.000000s system = 0.218401s CPU (162.3%) rotate took 0.004111s wall, 0.015600s user + 0.000000s system = 0.015600s CPU (379.5%) destruction took 0.279619s wall, 0.031200s user + 0.280802s system = 0.312002s CPU (111.6%) done Total time = 19.231975s wall, 18.626519s user + 0.592804s system = 19.219323s CPU (99.9%) std::vector benchmark construction took 19.587929s wall, 19.359724s user + 0.234002s system = 19.593726s CPU (100.0%) sort took 0.112920s wall, 0.124801s user + 0.000000s system = 0.124801s CPU (110.5%) rotate took 0.002486s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.262937s wall, 0.031200s user + 0.218401s system = 0.249602s CPU (94.9%) done Total time = 19.968799s wall, 19.515725s user + 0.452403s system = 19.968128s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 1.16546 user = 1.18838 system = 0 (user+system) = 1.16517 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 1.16156 user = 1.19933 system = 0 (user+system) = 1.16234 varray/std::vector total time comparison: wall = 1.1187 user = 1.14468 system = 0 (user+system) = 1.11875 --------------------------------------------------------------------------------------------------------------------------- Windows mingw_4_7 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- N = 1000 varray benchmark: construction took 13.752772s wall, 13.447286s user + 0.000000s system = 13.447286s CPU (97.8%) sort took 2.207612s wall, 2.449216s user + 0.000000s system = 2.449216s CPU (110.9%) rotate took 0.381684s wall, 0.452403s user + 0.000000s system = 0.452403s CPU (118.5%) destruction took 0.000265s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 16.348433s wall, 16.348905s user + 0.000000s system = 16.348905s CPU (100.0%) boost::container::vector benchmark construction took 16.736949s wall, 15.631300s user + 1.060807s system = 16.692107s CPU (99.7%) sort took 5.170353s wall, 5.226034s user + 0.000000s system = 5.226034s CPU (101.1%) rotate took 0.001871s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.537667s wall, 0.124801s user + 0.374402s system = 0.499203s CPU (92.8%) done Total time = 22.453639s wall, 20.982135s user + 1.435209s system = 22.417344s CPU (99.8%) boost::container::vector benchmark with stack_allocator construction took 16.227005s wall, 15.412899s user + 0.624004s system = 16.036903s CPU (98.8%) sort took 4.376050s wall, 4.477229s user + 0.000000s system = 4.477229s CPU (102.3%) rotate took 0.001871s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.523920s wall, 0.109201s user + 0.514803s system = 0.624004s CPU (119.1%) done Total time = 21.134513s wall, 19.999328s user + 1.138807s system = 21.138135s CPU (100.0%) std::vector benchmark construction took 15.182662s wall, 14.149291s user + 0.904806s system = 15.054096s CPU (99.2%) sort took 1.408413s wall, 1.528810s user + 0.000000s system = 1.528810s CPU (108.5%) rotate took 0.001668s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.451160s wall, 0.046800s user + 0.421203s system = 0.468003s CPU (103.7%) done Total time = 17.049415s wall, 15.724901s user + 1.326008s system = 17.050909s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 0.728097 user = 0.779182 system = 0 (user+system) = 0.729297 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.773542 user = 0.817473 system = 0 (user+system) = 0.773432 varray/std::vector total time comparison: wall = 0.958885 user = 1.03968 system = 0 (user+system) = 0.958829 --------------------------------------------------------------------------------------------------------------------------- Linux clang_3_0_6 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 9000000 bytes N = 1000 varray benchmark: construction took 27.455347s wall, 27.360000s user + 0.050000s system = 27.410000s CPU (99.8%) sort took 5.683607s wall, 5.750000s user + 0.010000s system = 5.760000s CPU (101.3%) rotate took 1.651716s wall, 1.560000s user + 0.000000s system = 1.560000s CPU (94.4%) destruction took 0.002050s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 34.810039s wall, 34.700000s user + 0.060000s system = 34.760000s CPU (99.9%) boost::container::vector benchmark construction took 39.073566s wall, 33.070000s user + 5.960000s system = 39.030000s CPU (99.9%) sort took 13.405286s wall, 13.440000s user + 0.020000s system = 13.460000s CPU (100.4%) rotate took 0.011300s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.005573s wall, 0.810000s user + 0.150000s system = 0.960000s CPU (95.5%) done Total time = 53.509749s wall, 47.330000s user + 6.130000s system = 53.460000s CPU (99.9%) boost::container::vector benchmark with stack_allocator construction took 39.457245s wall, 33.660000s user + 5.790000s system = 39.450000s CPU (100.0%) sort took 13.454378s wall, 13.190000s user + 0.050000s system = 13.240000s CPU (98.4%) rotate took 0.013398s wall, 0.040000s user + 0.000000s system = 0.040000s CPU (298.5%) destruction took 1.007952s wall, 0.860000s user + 0.300000s system = 1.160000s CPU (115.1%) done Total time = 53.947026s wall, 47.750000s user + 6.140000s system = 53.890000s CPU (99.9%) std::vector benchmark construction took 31.662683s wall, 25.550000s user + 6.240000s system = 31.790000s CPU (100.4%) sort took 3.102917s wall, 2.870000s user + 0.080000s system = 2.950000s CPU (95.1%) rotate took 0.010094s wall, 0.020000s user + 0.000000s system = 0.020000s CPU (198.1%) destruction took 1.002616s wall, 0.770000s user + 0.210000s system = 0.980000s CPU (97.7%) done Total time = 35.793019s wall, 29.220000s user + 6.530000s system = 35.750000s CPU (99.9%) varray/boost::container::vector total time comparison: wall = 0.650536 user = 0.73315 system = 0.00978793 (user+system) = 0.650206 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.645263 user = 0.726702 system = 0.00977199 (user+system) = 0.645018 varray/std::vector total time comparison: wall = 0.972537 user = 1.18754 system = 0.00918836 (user+system) = 0.972308 --------------------------------------------------------------------------------------------------------------------------- Linux gcc_4_7_2 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 9000000 bytes N = 1000 varray benchmark: construction took 27.677216s wall, 27.560000s user + 0.050000s system = 27.610000s CPU (99.8%) sort took 5.934591s wall, 6.080000s user + 0.010000s system = 6.090000s CPU (102.6%) rotate took 1.720024s wall, 1.590000s user + 0.000000s system = 1.590000s CPU (92.4%) destruction took 0.002077s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 35.350653s wall, 35.240000s user + 0.060000s system = 35.300000s CPU (99.9%) boost::container::vector benchmark construction took 38.196097s wall, 32.530000s user + 5.830000s system = 38.360000s CPU (100.4%) sort took 12.107587s wall, 12.070000s user + 0.010000s system = 12.080000s CPU (99.8%) rotate took 0.011146s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.054511s wall, 0.680000s user + 0.190000s system = 0.870000s CPU (82.5%) done Total time = 51.383338s wall, 45.290000s user + 6.030000s system = 51.320000s CPU (99.9%) boost::container::vector benchmark with stack_allocator construction took 37.421275s wall, 31.590000s user + 5.840000s system = 37.430000s CPU (100.0%) sort took 12.009866s wall, 11.930000s user + 0.020000s system = 11.950000s CPU (99.5%) rotate took 0.013459s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (74.3%) destruction took 1.053435s wall, 0.770000s user + 0.300000s system = 1.070000s CPU (101.6%) done Total time = 50.511806s wall, 44.300000s user + 6.170000s system = 50.470000s CPU (99.9%) std::vector benchmark construction took 31.849724s wall, 25.920000s user + 5.760000s system = 31.680000s CPU (99.5%) sort took 3.244223s wall, 3.240000s user + 0.110000s system = 3.350000s CPU (103.3%) rotate took 0.010454s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.054326s wall, 0.780000s user + 0.280000s system = 1.060000s CPU (100.5%) done Total time = 36.173664s wall, 29.950000s user + 6.150000s system = 36.100000s CPU (99.8%) varray/boost::container::vector total time comparison: wall = 0.687979 user = 0.778097 system = 0.00995025 (user+system) = 0.687841 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.699849 user = 0.795485 system = 0.00972447 (user+system) = 0.699425 varray/std::vector total time comparison: wall = 0.977248 user = 1.17663 system = 0.0097561 (user+system) = 0.977839 --------------------------------------------------------------------------------------------------------------------------- Linux clang_3_0_6 -O2 Core2Duo P7350 2GHz, 3GB Ram Additional benchmark of Adam Wulkiewicz’s rtree --------------------------------------------------------------------------------------------------------------------------- ins[s] qB[s] qiwo[s] qn[s] qnP5[s] qnB[s] rem[s] mem[MB] - container::vector 10.8 14.4 6.9 3.1 4.8 6.0 5.7 184.1 - std::vector 10.9 13.5 6.9 3.4 5.2 5.9 5.4 274,8 - varray 10.2 12.6 6.3 2.8 4.5 5.8 4.9 207,1 So in this case varray is slightly faster from both and consumes less memory than std::vector.

6 10

[iostreams] Check zlib/bzip2 availability on configuration checks
by Kohei Takahashi 13 Feb '13

13 Feb '13

Hi all, I attached a patch for preventing build error with the environment which provides no zlib and/or bzip2. This patch detects zlib.h and bzlib.h availability on configuration checks timing. It also should work with any environment variable (e.g. ZLIB_SOURCE,BZIP2_SOURCE, ...). Suggestions and comments welcome. Thanks, Kohei Takahashi

1 0

[mpl] is_lambda_expression bug?
by James Hirschorn 12 Feb '13

12 Feb '13

The compile-time assertion fails in the following program. I have tried with more than one version of boost including 1.53. Is it a bug? Shall I report it? -------------------------------------------------- #include <boost/mpl/assert.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/plus.hpp> namespace mpl = boost::mpl; struct MetafunctionClass { template<typename T1, typename T2> struct apply { typedef typename mpl::plus<T1,T2>::type type; }; }; BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>)); int main(int argc, char * argv[]) { } --------------------------------------------------

4 12