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

[test] missing include files
by Vicente J. Botet Escriba 12 Feb '13

12 Feb '13

Hi, I have needed to apply this patch to be able to compile with Boost.Test. Could I commit it? Best, Vicente svn diff boost/test Index: boost/test/tools/detail/print_helper.hpp =================================================================== --- boost/test/tools/detail/print_helper.hpp (revision 82823) +++ boost/test/tools/detail/print_helper.hpp (working copy) @@ -25,6 +25,7 @@ #include <boost/type_traits/is_array.hpp> #include <boost/type_traits/is_function.hpp> #include <boost/type_traits/is_abstract.hpp> +#include <limits> #include <boost/test/detail/suppress_warnings.hpp> Index: boost/test/utils/is_forward_iterable.hpp =================================================================== --- boost/test/utils/is_forward_iterable.hpp (revision 82823) +++ boost/test/utils/is_forward_iterable.hpp (working copy) @@ -33,6 +33,7 @@ // STL #include <utility> +#include <type_traits> #endif //____________________________________________________________________________//

2 2

[odeint] Docs don't build in 1.53.0
by John Maddock 12 Feb '13

12 Feb '13

I've finally got around to building the PDF docs for 1.53, and the the docs for Odeint don't build in 1.53: xslt-xsltproc.windows ..\..\..\..\bin.v2\libs\numeric\odeint\doc\msvc-10.0\debug \auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\refe rence-xml.doxygen file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/d ebug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/ reference-xml/index.xml:1327: parser error : Opening and ending tag mismatch: co mpound line 334 and doxygenindex </doxygenindex> ^ file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:1328: parser error : Premature end of data in tag compound line 333 ^ file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:1328: parser error : Premature end of data in tag compound line 266 Any ideas? Thanks, John.

3 2

[1.53] PDF doc build
by John Maddock 12 Feb '13

12 Feb '13

There's a preliminary build of the PDF docs for 1.53 here: https://sourceforge.net/projects/boost/files/boost-docs/1.53.0/ Currently missing Odeint, but should otherwise be complete and OK. Regards, John.

1 0

[interprocess] Platform-specific flags for mapped_region
by Andrey Semashev 12 Feb '13

12 Feb '13

Hi, I wanted to try using Linux huge pages in my application, which uses Boost.Interprocess currently for interprocess communication. However there seems to be no way to pass MAP_HUGETLB flag to mmap in the interface of mapped_region. I understand that this is a platform-specific option, so probably it would be best to just add an opaque unsigned int flags parameter to the mapped_region constructor with the default value of 0. Or is there a better way of doing this? I'll create a ticket for this feature, but I wanted to know if the general idea of this extension is welcome.

2 3

[Boost.Range] An issue with the documentation of 'remove_erase_if' algorithm
by Adam Romanek 12 Feb '13

12 Feb '13

Hi, I think there's an issue with the documentation of 'remove_erase_if' algorithm from Boost.Range library. It says: "remove_erase_if removes the elements x that satisfy pred(x) from the container. This is in contrast to the erase algorithm which merely rearranges elements." I believe it's not in contrast to the "erase" algorithm but rather the "remove" algorithm. WBR, Adam Romanek

5 8

Future of Boost Windows Installers
by Dave Abrahams 11 Feb '13

11 Feb '13

Hi, As many of you already know, I'm going to work at Apple in late February, and BoostPro is closing its doors. For many years, the Boost Getting Started Guide has suggested that Windows users pop over to BoostPro's website and use the latest installer to get Windows binaries. We'd like to donate to the community the technology used to build those installers. If anyone would like to pick up the job of creating them, we'd be happy to offer guidance. Right now I'm on a plane where an uplink to GitHub is creeping along at 4KB/s, so I've been pushing the stuff up in bits and pieces and the latest stuff isn't up there, but it's going to http://github.com/boostpro/installer and will be complete within 24 hours. Whatever happens with this installer code, someone is going to need to update the Getting Started Guide, either to point at the installer's new home, or to remove references to it. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 7

Release branch now open for merging
by Marshall Clow 11 Feb '13

11 Feb '13

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

2 1

[iostreams] mapped_file_source fails for zero sized file
by Michael Marcin 11 Feb '13

11 Feb '13

While testing out iostreams memory mapped file source I ran into an issue where it throws when opening a zero sized file (testing on windows 7 vc11 x64). for example something like: namespace io = boost::iostreams; namespace fs = boost::filesystem; fs::path path("C:\\boost\\boost_1_53_0\\libs\\context\\src\\dummy.cpp"); io::stream<io::mapped_file_source> file( path ); Will throw: failed create mapping: The volume for a file has been externally altered so that the opened file is no longer valid. From: http://tinyurl.com/cx2b9ru "When you do not want the size of the file to change (for example, when mapping read-only files), call CreateFileMapping and specify zero for both dwMaximumSizeHigh and dwMaximumSizeLow. Doing this creates a file mapping object that is exactly the same size as the file. Otherwise, you must calculate or estimate the size of the finished file because file mapping objects are static in size; once created, their size cannot be increased or decreased. An attempt to map a file with a length of zero in this manner fails with an error code of ERROR_FILE_INVALID. Programs should test for files with a length of zero and reject such files." I don't see anything in the docs that would lead me to believe this should throw. Rather I would expect: std::istream_iterator<char>(file) == std::istream_iterator<char>()

1 0

Picking overload with the most specific concept
by Louis Dionne 11 Feb '13

11 Feb '13

Hi, I was playing around today and I achieved to do something I find quite cool. I would like to know whether the technique/general principle is of any interest. Basically, it allows to overload functions based on the modeling of a concept by a type without having to write complicated enable_ifs. It does come with some problems and it is not very general for the moment, but it's a first shot. Here we go: #include <duck.hpp> // the library where I implemented that #include <forward_list> #include <utility> #include <vector> // Generates some boilerplate required to enable concept overloading for // a function named `my_distance`. Ignore this for now. DUCK_ENABLE_CONCEPT_OVERLOADING( my_distance, my_distance(std::declval<Iterator>(), std::declval<Iterator>(), State()), typename Iterator ) struct random_access_version_picked { }; struct forward_version_picked { }; // The State template parameter will be used to carry information during // the resolution. tag::my_distance was defined by the above macro. template <typename Iterator, typename State = tag::my_distance> // This can be seen like an enable_if with some more functionality. typename duck::requires< // This overload is picked iff Iterator models RandomAccessIterator // and no other overload for a more specific concept exist. // Concepts are MPL metafunction classes, so there's no magic here. duck::model_of<duck::RandomAccessIterator, Iterator> // Could add more duck::model_of clauses here , duck::overload_resolution_state<State> // required for the mechanics , duck::template_parameters<Iterator> // ditto , random_access_version_picked>::type // return type my_distance(Iterator, Iterator, State = State()) { return random_access_version_picked(); } // Same thing for the ForwardIterator implementation. template <typename Iterator, typename State = tag::my_distance> typename duck::requires< duck::model_of<duck::ForwardIterator, Iterator> , duck::overload_resolution_state<State> , duck::template_parameters<Iterator> , forward_version_picked>::type my_distance(Iterator, Iterator, State = State()) { return forward_version_picked(); } int main() { std::forward_list<int> list; std::vector<int> vec; forward_version_picked forward = my_distance(begin(list), end(list)); random_access_version_picked random = my_distance(begin(vec),end(vec)); } This example works with Clang 3.3 and GCC 4.8. For those interested in seeing more, the full library is available at: http://github.com/ldionne/duck Look for the `next` branch. The file involved with the above mechanics is include/duck/requires.hpp. Also see the test in test/requires.cpp. Regards, Louis Dionne

1 0

[Git] Status update
by Dave Abrahams 10 Feb '13

10 Feb '13

Please see https://github.com/ryppl/boost-svn2git/wiki if you're interested in the status of modularized history conversion. -- Dave Abrahams

4 3

[smart_ptr] !defined(BOOST_NO_CXX11_SMART_PTR) does not imply !defined(BOOST_NO_CXX11_RVALUE_REFERENCES)
by Michel Morin 10 Feb '13

10 Feb '13

`!defined(BOOST_NO_CXX11_SMART_PTR)` does not necessarily mean that the compiler support of rvalue references is available. For example, when I use shared_ptr (on trunk) with clang + libc++ in a C++03 mode, I get warnings something like boost/smart_ptr/shared_ptr.hpp:556:51: warning: rvalue references are a C++11 extension [-Wc++11-extensions] shared_ptr & operator=( std::unique_ptr<Y, D> && r ) Regards, Michel

3 4

[preprocessor] enabling variadics support
by Gennadiy Rozental 09 Feb '13

09 Feb '13

Hi, It appears PP variadics support is disabled on wide range of compilers where it is in fact working (at least It seems to be). This includes Clang and PGI. Can we enable it now? Gennadiy

3 2

[variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
by Antony Polukhin 08 Feb '13

08 Feb '13

Current implementation of recursive_wrapper move constructor is not optimal: recursive_wrapper<T>::recursive_wrapper(recursive_wrapper&& operand) : p_(new T(std::move(operand.get()) )) { } During descussion were made following proposals: I: Leave it as is - bad performance - can not provide noexcept guarantee II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations + good performance + provides noexcept guarantee for move constructor + optimization will be used even if varinat has no type with trivial default constructor + easy to implement - triggers an assert when user tries to reuse moved object - adds an empty state to the recursive_wrapper III: Make recursive_wrapper and variant cooperate, enable move for varinat in the presence of recursive_wrappers only when there is at least one type that is nothrow-default-constructible, regardless of whether it's current. It is easyer to understand by example: typedef variant<int, recursive_wrapper<foo>> V; V v1( std::move(v2) ); This move-constructs v1 from v2 and leaves int() into v2. + good performance + provides noexcept guarantee for rcursive_wrapper + does not adds an empty state - optimization won't trigger if varinat has no type with trivial default constructor - hard to implement - user may be obscured by the fact, that v2 from the example now contains int IV: After move away, delay construction of type held by recursive_wrapper till it will be be required. +/- good performance? but more checks + provides noexcept guarantee for rcursive_wrapper + does not adds an explicit empty state + optimization will be used even if varinat has no type with trivial default constructor +/- not hard to implement --- additional requirement for type T of recursive_wrapper: it must be default constructible - less obvious behavior for user (for example get() function would construct values, allocate memory and can possibly throw) Please, vote for solution or propose a better one. P.S.: As I know Joel de Guzman votes for solution II (and totally agains solution I, because it is too slow). I wanted to leave as is (solution I) or use solution IV, but Joel talked me to solution II. P.P.S.: More info can be obtained from ticket #7718 https://svn.boost.org/trac/boost/ticket/7718 and previous series of letters. -- Best regards, Antony Polukhin

23 126

[asio] socks and http connect proxy support
by ecyrbe 08 Feb '13

08 Feb '13

Hi, I made a boost asio client stream to handle tcp proxy support (both socks v4/v5 and http connect). I think boost asio lack this type of support, so i'm asking if there is any interest to integrate such a feature in boost.Asio? I'm mainly asking this question to boost.Asio maintainers. if you want i can come with a patch for a proxyfied_stream<Stream> template class. Regards, ecyrbe.

1 0

[Git] Tracking conversion milestones and issues
by Beman Dawes 08 Feb '13

08 Feb '13

To track the Git and modular Boost conversion milestones and issues, see github.com/ryppl/boost-svn2git/issues/milestones github.com/ryppl/boost-svn2git/issues --Beman

1 0

[log] v2 Initialisation, default sink behaviour and filtering documentation
by Mats Taraldsvik 08 Feb '13

08 Feb '13

Hi, I'm in the process of adopting a logging library, so the timing of the Boost.Log v2 "status report" - for me - could not have been better. :) This library is awesome, thank you for making it! -- I am in the process of moving beyond the default sink now, and had some issues. I tried to add the sinks after my logger object had been default initialized, and this caused some problems (partial streams/corruption, mostly). Currently I'm calling core->remove_all_sinks() to remove the default sink. Are there any "best practices" here? Perhaps it would be a good idea to add these "requirements" to the documentation, if they are not there already and I missed them? :) -- I also noticed that the severity filter examples are : logging::core::get()->set_filter ( logging::trivial::severity >= logging::trivial::info ); >From "Setting up sinks", and sink->set_filter(expr::attr< int >("Severity") >= 2); (i.e. comparing the Severity with an int) when moving to the more advanced section in "Sink frontends". Could you adjust one of the examples in "Sink frontends" to use the severity_level type (that the documentation introduces in the tutorial "Adding more information to log: Attributes") directly? For example: sink->set_filter(expr::attr< severity_level >("Severity") >= warning); Or explaining this in "Log record formatting". I had trouble understanding this at first, but I might be the only one :). Thought I'd mention it anyway. -- Regards, Mats Taraldsvik Norkart AS norkart.no

2 5

[bind] Request: use result_of instead of result_type for functors
by Jason 07 Feb '13

07 Feb '13

One of the drawbacks of using functors with Boost.Bind is that the result type of the functor must be specified either as a typedef inside the functor's definition or as a template argument when building the binding. As the documentation states it: "In the general case, the return type of the generated function object's operator() has to be specified explicitly (without a typeof operator the return type cannot be inferred)" It seems that result_of() would be a good implementation of the "typeof" operator referenced in the above, instead of relying upon a single result_type typedef inside the functor struct/class. This would allow the use of functors whose result type depends upon the arguments passed to the functor. It looks like there was a proof-of-concept patch submitted for this a couple years ago: https://svn.boost.org/trac/boost/ticket/4542 It doesn't appear to have received any attention, however. Is this something that might happen? -- View this message in context: http://boost.2283326.n4.nabble.com/bind-Request-use-result-of-instead-of-re… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 11

[log] missing file in trunk?
by Michael Caisse 07 Feb '13

07 Feb '13

boost/log/filters.hpp seems to be missing from https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log revision 827. Ideas? michael -- Michael Caisse ciere consulting ciere.com

2 3

[bbv2] pdf doc missing?
by Michael Marcin 07 Feb '13

07 Feb '13

http://www.boost.org/doc/libs/1_53_0/tools/build/v2/index.html links to http://www.boost.org/doc/libs/1_53_0/tools/build/v2/doc/userman.pdf Which appears to be broken 404 Not Found File "/home/grafik/www.boost.org/archives/live/boost_1_53_0/tools/build/v2/doc/userman.pdf" not found. In fact the last working one seems to be http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf

1 0

[Function] : Memory allocation upon bind()
by Harry van Haaren 06 Feb '13

06 Feb '13

Hi All, Summary: Boost::bind() allocates memory on the heap. In my situaion it is necessary to use manual memory pool instead of heap allocation, to conform with real-time timing requirements. (no malloc() calls allowed in real-time code) A solution might be writing a custom allocator for the boost::bind()'s data, and use a pre-allocated memory pool with the "placement" new( void* ) to write directly into it. I've found that there was a discussion on std::allocator support for std::bind and std::function here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html I'm not very familiar with the internals of bind() and Function in general, hence advice is appreciated. What is the status of boost::bind() and custom allocators? Is there a chance this could work? Am I missing some "easy" workaround or solution? Thanks for reading, -Harry

2 2

[log][phoenix] Bound arguments not protoified?
by Andrey Semashev 06 Feb '13

06 Feb '13

Hi, I have a problem with Boost.Phoenix v3 bind implementation when used with attribute keywords from Boost.Log. For some reason phoenix::bind does not apply proto::detail::protoify to the bound arguments which breaks compilation of some formatting expressions in Boost.Log. Here's an example: namespace logging = boost::log; namespace expr = boost::log::expressions; namespace phoenix = boost::phoenix; // Custom severity level formatting function std::string severity_level_as_urgency( logging::value_ref< logging::trivial::severity_level, logging::trivial::tag::severity > const& level); // The function initializes the logging library void init_logging() { // ... sink->set_formatter ( expr::stream << phoenix::bind(&severity_level_as_urgency, logging::trivial::severity) ); } The intended behavior of this code is to invoke severity_level_as_urgency function with severity level value extracted from a log record and put the result of this function into a stream, thus forming a formatted representation of the record. trivial::severity is a keyword of type expr::attribute_keyword< ... >. Keywords themselves should never actually be embedded into phoenix expressions, instead I have attribute_actor that implements all the necessary work to extract attribute values. I have specialized proto::detail::protoify template for attribute_keyword (including references and reference_wrappers thereof) so that it is automatically converted to attribute_actor whenever it participates in expressions. But it doesn't work with the above code, Boost.Phoenix embeds attribute_keyword as is into the expression. This results in the error I posted in the end of the post. I realize that proto::detail::protoify is not for public use and may not be intended for my use case but I did not find any other way to implement what I described. Anyway, I think bind should treat bound arguments as child subexpressions and protoify them. Is that right? In case if you want to see the complete code of the example and/or Boost.Log, you can check it out from SVN: svn co https://boost-log.svn.sourceforge.net/svnroot/boost- log/branches/bleeding-edge boost-log The example resides in libs/log/example/doc/extension_app_launcher.cpp. I have modified it to call or_none() on trivial::severity so that the example compiles; in order to reproduce the problem you have to remove this call (it sould be performed by my protoify specialization instead). Compilation error: In file included from ./boost/phoenix/core/preprocessed/expression.hpp:12:0, from ./boost/phoenix/core/expression.hpp:21, from ./boost/phoenix/core/argument.hpp:14, from ./boost/phoenix/core.hpp:17, from ./boost/phoenix/phoenix.hpp:11, from ./boost/phoenix.hpp:11, from libs/log/example/doc/extension_app_launcher.cpp:13: ./boost/phoenix/core/preprocessed/expression_10.hpp: In instantiation of ‘static boost::phoenix::expr_ext<Actor, Tag, A0, A1>::type boost::phoenix::expr_ext<Actor, Tag, A0, A1>::make(typename boost::call_traits<A0>::param_type, typename boost::call_traits<A1>::param_type) [with Actor = boost::phoenix::actor; Tag = boost::phoenix::detail::tag::function_eval; A0 = boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>; A1 = boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>; boost::phoenix::expr_ext<Actor, Tag, A0, A1>::type = boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >; typename boost::call_traits<A0>::param_type = const boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>&; typename boost::call_traits<A1>::param_type = const boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>&]’: ./boost/phoenix/bind/bind_function.hpp:45:83: required from ‘const typename boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::function_ptr<1, RT, RT (*)(T0)>, A0>::type boost::phoenix::bind(RT (*)(T0), const A0&) [with RT = std::basic_string<char>; T0 = const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&; A0 = boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>; typename boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::function_ptr<1, RT, RT (*)(T0)>, A0>::type = boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >]’ libs/log/example/doc/extension_app_launcher.cpp:92:91: required from here ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: warning: missing braces around initializer for ‘boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >::expr_type {aka boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l>}’ [-Wmissing-braces] ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: warning: missing braces around initializer for ‘boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l>::proto_child0 {aka boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>}’ [-Wmissing- braces] ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: error: could not convert ‘boost::proto::make_expr<boost::phoenix::detail::tag::function_eval, boost::proto::domainns_::basic_default_domain, boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>, boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity> >((* & a0), (* & a1))’ from ‘const type {aka const boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity> >, 2l>}’ to ‘boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>::proto_child0 {aka boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>}’ ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: error: no matching function for call to ‘boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>::attribute_actor(<brace-enclosed initializer list>)’ ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: note: candidates are: In file included from ./boost/log/expressions.hpp:20:0, from libs/log/example/doc/extension_app_launcher.cpp:16: ./boost/log/expressions/attr.hpp:174:14: note: boost::log::v2s_mt_posix::expressions::attribute_actor<T, FallbackPolicyT, TagT, ActorT>::attribute_actor(const base_type&) [with T = boost::log::v2s_mt_posix::trivial::severity_level; FallbackPolicyT = boost::log::v2s_mt_posix::fallback_to_none; TagT = boost::log::v2s_mt_posix::trivial::tag::severity; ActorT = boost::phoenix::actor; boost::log::v2s_mt_posix::expressions::attribute_actor<T, FallbackPolicyT, TagT, ActorT>::base_type = boost::phoenix::actor<boost::log::v2s_mt_posix::expressions::attribute_terminal<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity> >] ./boost/log/expressions/attr.hpp:174:14: note: candidate expects 1 argument, 0 provided ./boost/log/expressions/attr.hpp:156:7: note: boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>::attribute_actor(const boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>&) ./boost/log/expressions/attr.hpp:156:7: note: candidate expects 1 argument, 0 provided

2 3

-commits list broken?
by Marshall Clow 06 Feb '13

06 Feb '13

I just noticed that I haven't received any mail from boost-commits since 1/29. The archives on the web site stop at 1/14. Any ideas for giving the server a thwack? -- 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

1 0

[range] missing includes in any_range.hpp
by svarneticist 05 Feb '13

05 Feb '13

Hello, I get errors when I try to use boost/range/any_range.hpp It appears that boost/range/detail/any_iterator.hpp needs #include <boost/utility/enable_if.hpp> and boost/range/detail/any_iterator_wrapper.hpp needs #include <boost/range/concepts.hpp> Thank you -- View this message in context: http://boost.2283326.n4.nabble.com/range-missing-includes-in-any-range-hpp-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Okay, I believe I need to provide a really good example that can show the need of static construction with no preliminary calls to initialization functions. The example if part of my work project: - I have two layers: presentation and model. - Each layer work in its own thread because presentation must remain responsive whatever happens in model. - Model itself is an abstract layer, the actual logic implementation is implemented in specific agents, so the model is not aware of the agents. - Agents are asynchronous tasks. - I have DatabaseFacade utility class, internal data of which require some preliminary initialization, like setting initial values, creating locks, filling hash maps, but not actual connection because it's a proxy to real database object. - All agents use the DatabaseFacade asynchronously. These are the possible scenarios of initialization of DatabaseFacade internal data: 1. Make a call to DatabaseFacade::initialize() from main (or other wiring code), thus making main aware about DatabaseFacade, i.e. introduce an unnecessary dependency. 2. Call DatabaseFacade::initialize() from model construction, again introducing an unnecessary dependency, because the abstract model doesn't care about some specific needs of some agents. 3. Call DatabaseFacade::initialize() during specific agent construction. But another agent can be inside a call to DatabaseFacade::initialize(). So, I'd need to wrap it in critical section. But the critical section itself has to be initialized before agents start. Should I introduce dependency on this specific critical section to the abstract model? Nop. Should I wrap DatabaseFacade::initialize() inside in a static critical section thus making assumptions about clients of the function? Nop again. And by introducing public method DatabaseFacade::initialize() I will open a possibility for double initialization. Of course I can insert checks, but the checks can reveal problems at run-time only. So it's more correct to allow a class to initialize its internal data itself on its own discretion, thus writing robust API that cannot be misused: "Anything that can go wrong will go wrong" - Murphy's Law ;) Thank you. ______________________________ With best regards, Alexander Stoyan

1 0

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Hello everybody, Sorry for late response. To Mateusz. Thank you for a good point, I have updated my initial blogpost with with clear statement of the goal. And I also corrected naming and put some extra comments. To Mathias. >> What's the functional difference between putting it as a type list and >> putting it as code? Not sure that I understood your question correctly, but if you meant differences between dependencies in the static_dependencies list and dependencies caused by calling initialization from main, then the difference is clear: if we put dependencies B and C to static_dependencies list when declaring class A, then only class A declaration becomes dependent on B and C. But if we require a call to A::initialize, B::initialize and C::initialize from main, then main becomes dependent on A, B and C. This way your startup code will be dependent on everything like that, that's not right. >> If you want it to be initialized before main, then use global variables or static members. Ok, try to answer your question yourself: struct A { static A& instance() { ... } } struct B { static A& instance() { ... } } struct C { static A& instance() { ... } } ... static A& forceAConstr = A::instance(); static B& forceBConstr = A::instance(); static C& forceCConstr = A::instance(); ... int main() { ... } Can you guarantee the order of construction for A, B and C in this case when standard explicitly states that the order of initialization is not determined? >> But then you have to make sure no threads exist prior to entering main. >> Unlike for static variables in functions, global constructors are not thread-safe. Starting threads before main execution is a bad idea itself, so don't do it. >> I have no idea what you're talking about. The compiler cannot remove >> things if it changes observable behaviour, outside of a few situations >> where copy constructors can be elided. In my code you can find a declaration and initialization of bool static_constructible<T, Dependencies>::constructed. So, if this variable is not referenced in the code it never get initialized. At least this is how VS11 compiler works. So in order to refer this variable all data access functions have to make a call to static_constructible<T, Dependencies>::ensure_static_constructed. This way if you call a data access function from main, which calls ensure_static_constructed, then static_constructible::constructed becomes referenced! >> There is an "isinside" boolean. That's only made for cases if a derived class from singleton does not provide his own static constructor. If you remove B::static_construct() the code will work fine anyway. >> A given order can still be forced. Unless it's through compile configuration, provide an example please. Otherwise, having long lists of initialization orders for all supported compilers is error prone. The code itself has to describe itself as much as possible. I appreciate your attention. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1

[gil] compiler error with clang in c++11 mode
by Christian Henning 05 Feb '13

05 Feb '13

Hi there, Can someone shed some light on the following compiler errors: c:\boost\boost\gil/channel_algorithm.hpp:54:85: error: non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long long' [-Wc++11-narrowing] struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; ^ c:\boost\boost\gil/channel_algorithm.hpp:204:19: note: in instantiation of template class 'boost::gil::detail::unsigned_integral_max_value<unsigned long long>' requested here if (src > unsigned_integral_max_value<uintmax_t>::value - div2) I only get those in c++11 mode. The code to trigger them is: #include <boost\gil\gil_all.hpp> int main() { return 0; } I'm using clang 3.2 on Windows with CodeBlocks. Thanks, Christian

2 3

[type_traits] Request: is_iterable
by Nevin Liber 05 Feb '13

05 Feb '13

I'd like to make a request for an is_iterable<T> type trait, which detects if a type can be used in C++11 range-based for. I have a prototype which currently meets my needs (I can make it available; it detects if both std::begin(c) and std::end(c) can be called), but I'm wondering: a) What should the name be? (I'm not married to is_iterable) b) Should there be a second template parameter indicating the type returned by derefencing the iterator, defaulting to don't care. c) What should the C++03 behavior be? d) Is there someone with more expertise than I willing to implement a robust version of it? Does this sound like a good idea? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

4 4

Boost 1.53.0 released!
by Marshall Clow 04 Feb '13

04 Feb '13

Release 1.53.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains five new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries: * Atomic: C++11-style atomic<>, from Helge Bahmann, maintained by Tim Blechmann. * Coroutine: Coroutine library, from Oliver Kowalke. * Lockfree: Lockfree data structures, from Tim Blechmann. * Multiprecision: Extended precision arithmetic types for floating point, integer and rational arithmetic from John Maddock and Christopher Kormanyos. * Odeint: Solving ordinary differential equations, from Karsten Ahnert and Mario Mulansky. For details, including download links, see http://www.boost.org/users/news/version_1.53.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.53.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

6 7

[1.53] Too late for doc fixes?
by John Maddock 04 Feb '13

04 Feb '13

Am I correct in assuming that it's too late to fix typos in docs: https://svn.boost.org/trac/boost/ticket/7958 ? Thanks, John.

3 3

[function] Documentation suggestion (FAQ)
by Evan Driscoll 04 Feb '13

04 Feb '13

I just wrote up a longish email (excerpted below) that was basically asking for advice about how to work around the fact that I can't compare two function objects. However, I fortunately decided to take another look at the docs before sending, and realized that Boost actually supports what I *really* needed, which was to compare a function object to see if it points to a particular function so I could use a much faster implementation. In other words, I was doing void backing_func() {...} boost::function<void()> func(backing_func); void foo(function<void()> callback) { if (callback == func) { fast_foo(); } else { slow_foo(callback); } } but by changing the if statement condition to if (callback == &backing_func) everything is fine and dandy. My suggestion is that the FAQ entry at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html should be updated to point out that there IS a way to do this specific case. If everyone read the whole docs and remembered them perfectly this wouldn't be a problem, but of course those statements are probably true of exactly no one. :-) I stumbled across the FAQ entry, which I feel strongly suggests that what I want to do is impossible. Evan P.S. If you have suggestions for a better design, I'm open to suggestions. --------- I'd like input about how to handle a design. I'll describe what I'm doing; my question is what people would suggest. I have a class which stores a boost::function<> as a parameter so as to provide a hook to customize its behavior. I can give the actual code and description of what I'm doing if that will help, but I suspect it distract more than help, so I'll just make something up (untested): typedef boost::function<bool (int, int)> CallbackType; class MyClass { CallbackType callback; void foo() { ... if (callback(x, y)) { .... } } MyClass(CallbackType cb) : callback(cb) {} }; There are a couple generically useful behaviors, so the library predefines callbacks for those: bool behavior_a(int, int) {...} bool behavior_b(int, int) {...} bool behavior_c(int, int) {...} CallbackType behavior_a_callback(behavior_a), behavior_b_callback(behavior_b), behavior_c_callback(behavior_c); I have need to make 'foo' fairly general and support fairly general callbacks, but for one behavior (say behavior_a), I can use a substantially more efficient algorithm (log or constant time, instead of linear) inside foo(). What I WANTED to do was make the behavior_a(int,int) function just a dummy, then do void foo() { if (callback == behavior_a_callback) { fast_foo(); } else { slow_foo(); } } However, for reasons described at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html#id1617166, you can't compare functions with equality. Any thoughts as to how you'd do this? Evan

2 1

[Fusion] Some ideas
by TONGARI 03 Feb '13

03 Feb '13

Hi, Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::transform(a, b, some_void_return_ftor)) * Conversion function 'as_view' to make Container a view to reserve the mutability. What do you think? Are these already achieved in some way that I didn't aware of? BTW, I just implemented left_mapping/left_mapped_view, it's used like result = left_mapping(m1, m2, transform); For elements not mapped, fusion::void_ is passed to transform. Still mapping & full_mapping to do...

3 14

Re: [boost] (no subject)
by Gilbert Polo 03 Feb '13

03 Feb '13

Is boost version 1.48 portable to AIX version 6.1. xlC version 11.1

2 1

[thread] possible raise in future?
by Oliver Kowalke 03 Feb '13

03 Feb '13

Hello Vicente, after analyzing the code of future<> from boost.thread I think the code might contain raise condition. future.hpp:226: future_object_base defined 'bool done'. future_object_base::mark_finished_internal() sets 'done' tot true (line 308) and future_object_base::wait_internal() reads it (line 347). Shouldn't 'done' be of type atomic<bool >? I believe that the compiler can reorder the usage of 'done' and two threads (writer thread calling make_finished_internal() and reader calling wait_internal()) might see different values. At least I think it might be possible that some thread will always be waiting in waiters.wait() (line 349), because the write r thread sets done=true and call waiters.notify_all() and a reader thread calls later wait_internal() but does not see that done is true because of memory reordering etc. and will be blocked in waiters.wait()forever. What do you think? best regards, Oliver

2 3

Re: [boost] [thread] possible raise in future
by Oliver Kowalke 03 Feb '13

03 Feb '13

hmm - both functions are called by other member-fn of future_object_base, locking the same mutex before. But might reordering (of var done' inlined code) still be possible? I'm asking because l've some experimental code using future<> which sometimes blocks (I assume inside future<>::wait()).

1 0

Writing documentation
by Borislav Stanimirov 03 Feb '13

03 Feb '13

Hello, I'm developing a project for boost (discussion can be found here: http://lists.boost.org/Archives/boost/2013/01/200598.php) I was wondering how one writes documentation. I did find some templates here, but they seem outdated (ot at least different), compared to the documentation files that already exist for the libraries. So, are there any new templates? Is there a html generation tool I should use? -- Borislav

5 10

[auto_index] segfault during boostbook xml processing
by Alexey Kutumov 03 Feb '13

03 Feb '13

Hi! Recently i started to port boost documentation building to CMake ( https://github.com/boost-cmake/) with ryppl-dev community, and i have some issues with auto_index. According to documentation ( http://www.boost.org/doc/libs/1_52_0/tools/auto_index/doc/html/boost_autoin…) this tool supports boostbook XML, however when i started to process XML with auto_index it crashes. I created ticket (https://svn.boost.org/trac/boost/ticket/7967) and added example for reproducing ( https://svn.boost.org/trac/boost/attachment/ticket/7967/autoindex_issue.zip ). Also i have a question: is it legal to use auto_index with boostbook XML, because i have same issue for some others projects?

2 1

new proposal: order statistics tree
by Szymon Wojciechowski 03 Feb '13

03 Feb '13

Hi, I would like to propose to add new data structure - order statistics tree. Briefly, it is container which allows logarithmic inserting, searching and erasing as in set, but additionally it permits to access elements via numerical value - key order. I have some ready implementation with all appropriate functions (without their all overloaded forms) with gtest regression list, but the code isn't boostified. The regression passes on gcc 4.6.3 and vs2010. Is there anybody interested in? Best regards, Szymon Wojciechowski

7 21

Ok to commit to trunk?
by Christian Henning 03 Feb '13

03 Feb '13

Hi there, I'm planning to commit some changes and add the toolbox to gil on the trunk ( not the release branch! ). Is it OK to commit? Thanks! Christian

3 4

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

02 Feb '13

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

6 44

[1.53.0] Release candidates available
by Marshall Clow 02 Feb '13

02 Feb '13

Release candidate files for 1.53.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 57a9e2047c0f511c4dfcf00eb5eb2fbb *boost_1_53_0_rc1.tar.gz a00d22605d5dbcfb4c9936a9b35bc4c2 *boost_1_53_0_rc1.tar.bz2 c618e030fd4882e4dbacf54baf824544 *boost_1_53_0_rc1.zip cc680cab53a5405ca102a10d43b92b88 *boost_1_53_0_rc1.7z Thanks! -- The release managers

9 10

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello Mathias, I'm afraid you didn't get the point. Let me explain. >> The object will only be constructed when instance() is called Technically, yes, the instance will be create once singleton::instance is called for the first time, but in order to make it constructed BEFORE main, singleton::instance has to be called during static data initialization, and static_init GUARANTIES that this static initialization will be performed before main WITH NO additional calls. >> If the constructor of the object depends on >> other singletons, then instance() of those other singletons >> will naturally be called before, and therefore they >> will end up being constructed before. You're right, if you refer to singleton A's before creating singleton B's instance, to order of initialization would be correct. But let's no limit this case to singletons only, where initialization is achieved in just one call. There can many many different situation when you have to perform some additional data initialization and manipulation before creating singleton instance. Where would you put this code? Would you make singleton constructor or instance access method dependent on all this data when it naturally should not be? Anyway it doesn't solve the problem for the first call to a singleton if it has to be initialized before main. Unless you create a global static variable and make the first call to singleton during this variable initialization, but then you still need to refer to this variable from the code somewhere in order to make sure your compiler does not eliminate it due to optimization reasons, and this way you will introduce unnecessary dependency. 3. There is no construction recursion. If you did notice it somewhere, please point to exact place. 4. Static data construction order is undefined by C++ standard fixing it requires either changing the standard or getting rid of class and global static data. So, again, to make the idea crystal clear, the initial goal was: 1. Guarantee that static constructor method is called before main is executed 2. No additional calls in either global or any local scope should precede static constructor invocation in order not to introduce extra dependencies and eliminating a situation when initialization invocation code does not get called for any reason. 3. Provide a way to control the order of static constructors calls. No recursions are allowed. The described approach fully satisfies the three simple requirements. If anybody sees possible errors or ways to improve it, feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

3 2

Building 1.52.0 with g++ 4.7.2
by Richard Hadsell 01 Feb '13

01 Feb '13

I am having trouble building Boost 1.52.0 libraries with g++ 4.7.2 on Linux Fedora 14. I was able to build it with 4.7.1, and I think our Systems guys configured 4.7.2 the same as 4.7.1, so I need help. This is in my user-config: using gcc : 4.7.2 : /opt/gcc-4.7.2/bin/g++ :<compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp"<linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; This is my command line: bin/bjam --user-config=user-config.LINUX_INTF14X threading=multi instruction-set=core2 address-model=64 variant=release link=static,shared --stagedir=stageF14X And this is the result (snipped out redundant info): Building the Boost C++ Libraries. Performing configuration checks - x86 : no - power : no - arm : no - mips1 : no error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>qcc not matched [snip] next alternative: required properties:<abi>ms<address-model>64<architecture>x86<binary-format>pe<target-os>windows not matched - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. [snip] - Boost.Locale needs either iconv or ICU library to be built. - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched [snip] -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

[container] static_vector: fixed capacity vector update
by Andrew Hundt 01 Feb '13

01 Feb '13

*static_vector is a hybrid of boost::container::vector and boost::array with fixed capacity. Adam Wulkiewicz and I have updated static_vector with improvements from the list discussion and reorganized it for possible inclusion into boost.container. Overview: static_vector is a sequence container with contiguous storage that can change in size like boost::container::vector. It also includes static allocation, low overhead, and fixed capacity similar to boost::array. Synopsis: template* *<* * typename Value, * * std::size_t Capacity, * * typename Strategy = strategy::def<https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/static_vecto…> <Value> * *>* *class static_vector; Example: // static_vector of ints, fixed capacity: 3 boost::container::static_vector<int,3> three; // size: 0 three.push_back(1); // size: 1 three.push_back(2); // size: 2 three.push_back(3); // size: 3 //three.reserve(4); // no effect, fixed capacity: 3 //three.push_back(3); // size: 4, undefined behavior three.pop_back(); // size: 2 three.shrink_to_fit(); // no effect, fixed capacity: 3 Documentation: https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/index.html Source: https://svn.boost.org/svn/boost/sandbox/static_vector/ Discussions from boost.devel archive: http://goo.gl/PKEpB [google groups] Changes: - C++11 support - moved to boost::container namespace - strategy based error handling (“strategy” is aka “policy”) - bounds checks are asserts by default but can be switched to exceptions - memory is uninitialized until objects are inserted - internal size is currently the same as Strategy::size_type - expanded documentation and unit tests - optimizations based on type traits - boost::interprocess support ------------------------------------------------ ------------------------------------------------ Major questions from prior list discussions and the related design decisions: ------------------------ Q1: static_vector design *a) combination of fixed capacity vector and adjustable size array b) vector with small size optimization, possibly with configuration of what “small size” means. A1: (a) is implemented by static_vector, leaving the (b) as future work for a separate class. ------------------------ Q2: Is it best to implement push_back() and similar functions with or without bounds check? Main use cases: *a) no bounds check on each insertion because it is an undesirable use of resources b) vector emulation where static_vector is a drop in replacement and optimization so bounds checking is essential to minimize the amount of code that must be changed. A2: (a) no bounds check is the default for static_vector. A vector emulation strategy can be implemented for (b). ------------------------ Q3: Should a failed bounds check trigger an assertion or an exception? Main use cases: a) bounds check is too much overhead, but assert() allows for testing in debug mode b) vector emulation, so bad_alloc should be thrown when the capacity is exceeded c) exceptions are desired when bounds checking, but bad_alloc would cause the wrong behavior because freeing up memory will not allow the possibility of a larger capacity as it would in a vector. A3: (a) failed bounds checks trigger an assertion, and the user can implement the necessary strategy and traits to achieve (b) or (c). ------------------------------------------------ ------------------------------------------------ New/Unanswered Questions: ------------------------ Q4: Should the current static_vector actually be in the detail namespace, with policy specializations providing the actual interface to several classes with different desired functionality? This could be similar to what was suggested by Nate Ridge: On Sat, Oct 15, 2011 at 5:16 PM, Nathan Ridge <zeratul976(a)hotmail.com> wrote: > Now the implementor of these classes can implement them like this: > > typedef boost::detail::static_vector<T, AssertPolicy> capacity_array; > typedef boost::detail::static_vector<T, ThrowPolicy> stack_vector; It also seems to be backed by the fundamental interface differences between the various classes (static_vector, std::vector, AutoBuffer/hybrid_vector) as outlined by Dave Abrahams: On Wed, Oct 19, 2011 at 1:26 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > I see a container that can never store more than N items, for some > reasonably small N, as fundamentally, semantically different from one > that is highly likely to be able to store any M items you have to deal > with, and for which you can't determine a hard limit N ahead of time > (no, max_size() doesn't count—that's typically just > numeric_limits<size_t>::max()). I grant you that we don't have a very > strict way of expressing this difference in a specification, but I think > that's just missing. I wouldn't, except in very special circumstances, > consider one of those containers to be a suitable replacement for the > other, despite the similarity of the specification text. Would you? This would mean that the official interfaces can be specific to various common use cases and a bit simpler. An additional benefit here is that simpler interfaces are more welcoming to a wider range of developers. On the other hand, the current design makes the official interface configurable so they could customize it without being as concerned about changes in the detail implementation. If everyone will want something different for their specific use case, leaving the design as is may make the most sense. Furthermore, a reasonable default provides a simpler interface while permitting advanced configuration for those who need it. ------------------------ Q5: Should the static_vector Strategy concept (a) remain as is (b) add the Capacity as an additional template parameter (c) permit Standard Library Allocators as a strategy Currently, the default traits assume that the Strategy defines types normally defined by Allocator and provides a capacity check failure callback. Also, a different strategy and traits specialization can be used to configure the class as desired, such as modifying the size_type based on the Capacity. Consequently, leaving the Strategy as is (a) remains fairly reasonable. Adding an additional Capacity template parameter (b) to the Strategy concept would take the Strategy further from the Allocator concept, but ensure configuration of size_type based on the capacity is easy and consistent. We believe (c) does not make sense despite allowing static_vector to be more compatible with vector due to the fundamental interface differences discussed in Q4. Option (c) makes more sense for a class like AutoBuffer/hybrid_vector than it does for static_vector. Thus, the question ultimately becomes one concerning the tradeoff between options (a) and (b). ------------------------ Q6: Should static_vector_traits be part of the public interface or remain in the detail namespace? This would make some of the functionality in Q5a part of the official interface, but restrict future changes. In Boost.Container traits are defined in the detail namespace so we were hoping to find out the reasoning for this choice. The direction of the design discussion for Q4 could also make this a moot point. ------------------------ Q7: Does static_vector provide significant benefits over boost::container::vector with a stack Allocator template parameter? This has been discussed previously and we believe the answer is yes for the reasons outlined in Q4 and the documentation, but we wanted to bring it up again in case someone wanted to play devil’s advocate. ------------------------ That covers all the basics of the updated static_vector implementation and some of the biggest outstanding design questions. We appreciate any and all questions, design ideas, or issues you can come up with, so fire away. :-) Regards, Andrew Hundt* Adam Wulkiewicz

7 22

[GitHelp] varray (aka static_vector) to modular boost
by Andrew Hundt 01 Feb '13

01 Feb '13

I'm trying to bring varray over to github with modular boost, but since we just moved it from static_vector to varray the history is split between two directories. I have been able to run git svn on each directory independently and then pull the static_vector one into the varray one on a separate branch. I then want to stack all the versions so that they are continuous, but I am not sure how to do this. my steps so far: git svn clone http://svn.boost.org/svn/boost/sandbox/varray varray git svn clone http://svn.boost.org/svn/boost/sandbox/static_vector varray2 cp -a varray varray3 # backup # git pull command here that brings it into another branch Also, I'd be happy to take suggestions of better ways to accomplish this. I've noticed that all the dates on github.com/boostorgrepository changes are getting old and are up to nearly a month now, have the updates stopped working? Cheers! Andrew Hundt

2 2

[iterator] Constness of counting_iterator
by Claas 01 Feb '13

01 Feb '13

Hi all! I was wondering why the dereference operator of counting_iterator<T> returns a constant reference to T instead of a reference to T. Naively I would expect counting_iterator<T>::reference to be T& and counting_iterator<const T>::reference to be const T&. I suppose however that there was good reason to implement counting_iterator the way it is implemented. Could anyone kindly point this reason out to me? Regards Claas

2 1

Re: [boost] [variant] Please vote for behavior
by Markus Klein 01 Feb '13

01 Feb '13

On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave(a)boostpro.com> wrote: > Yes. IIUC the question here is whether the invariant of variant [;-)] > shall be weakened to accommodate efficient move semantics, thereby > breaking some code, or not, at some cost (the specific costs to be > incurred by various strategies presently under discussion). I'm new to this list, so I won't be offended if you correct me on any rookie mistakes. Concerning the invariant of variant: Why not provide a specialization of boost::optional for variant, which supports move Semantics? Users who don't want their invariant harmed, can use boost::variant as is. Users who need to squeeze out performance could use an optional<variant> and would be explicitly aware of the new null state they introduced for this. Markus www.clean-cpp.org

6 12

[asio] ssl::stream::async_handshake handler not called
by Alex 01 Feb '13

01 Feb '13

Hi guys, If ssl client cannot read data from server (SSL_connect: error in SSLv2/v3 read server hello A), handshake handler is not called. Is this by design? Or, probably, it should be called with error anyway. Thanks in advance. Alex

1 0

Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello community, I have implemented static constructors for my personal needs. They guarantee construction of static data prior main execution, and allow control the order of static initialization. The code now implemented and tested for VS2012 and GCC. I couldn't find anything like this in the boost library but consider it to be useful for C++ developers. More detailed approach on my blog page: http://alexander-stoyan.blogspot.com/2013/01/static-constructors-in-c.html Feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1