January 2013 - Boost - lists.preview.boost.org

[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

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

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

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

[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

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

[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