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

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

[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

[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

[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

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

[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

[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

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

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

Re: [boost] [filesystem] thread safety on msvc 2010
by Jacob Schloss 31 Jan '13

31 Jan '13

> Message: 9 > Date: Mon, 28 Jan 2013 11:05:07 -0500 > From: Beman Dawes <bdawes(a)acm.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] [filesystem] thread safety on msvc 2010 > Message-ID: > < > CAAygHNO8u+gvpGABgJR-KxSP-EqvhyRWRCSKKwx_7chH2hesSg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Some critical points to getting a patch accepted are that it applies > only to the affected platform (i.e. Windows) and that it includes test > cases that fail with the current code but pass with the patch applied. > If it works for you with msvc 2010, I can test with other versions and > compilers. > > Thanks, > > --Beman > > Ok, I have some test code I could submit. Is it all right to use boost::threads in the test so it is cross platform? It might be a while (have trip for work soon) until I have time to pull svn (or git, looks like that move is happening soon) and make the patch, but I will try to follow up on this when I get back. Thanks, Jacob PS: Sorry if this broke threading. I just switched off of the digest

2 1

Query of interest for a container output library
by meta221 31 Jan '13

31 Jan '13

Hello, lately I've been working on a library that can output different kinds of containers to standard output streams. The library is currently completely generic and can output any object that models the input range concept or Boost.Fusion's sequence concept. It doesn't restrict itself to std containers. If an object looks like a sequence, then it is a sequence in the eyes of the library. The library uses different open and close characters for different kinds of containers. For example the output of the following: std::cout << std::vector<int> {1,2,3} << '\n'; std::cout << std::set<int> {1,2,3} << '\n'; std::cout << std::map<int,int> { {1,2}, {2,3}, {3,1} } << '\n'; is: [1,2,3] {1,2,3} {(1,2), (2,3), (3,1)} In the example std::vector is interpreted as an ordered_dynamic container and std::set and std::map are interpreted as associative_dynamic containers by the library. The library recursively outputs the contents of each container, so because std::map::value_type is a std::pair (which models Boost.Fusion's sequence concept) it can also output that. std::pair is interpreted as an ordered_fixed container by the library. The library picks the appropriate category for each type being outputted by using Boost.MPL to introspect the type of the object being outputted. In the future I would like to extend the library to offer facilities to help users implement a operator<< (std::ostream&, T) function for arbitrary types but I haven't really given that a lot of thought yet. The library's name is currently Boost.Stringize but I don't really like that name and I'm really open for suggestions. Overall I think this library would make a good addition to Boost as it simplifies things for the end user. If a user wants to output a vector, he/she shouldn't have to iterate over it. It should be as simple as outputting an int. In Python a user can just "print [1,2,3]". Why can't we have something similar in C++? Is there any interest for this library in Boost? Thanks, Tal Zion -- View this message in context: http://boost.2283326.n4.nabble.com/Query-of-interest-for-a-container-output… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 10

[string_ref] type erasure to support arbitrary strings
by Andreas Pokorny 31 Jan '13

31 Jan '13

Hi, When I made a first glance of the proposal I expected that string_ref is some kind of type erasing non owning holder of a reference to an arbitrary string class. The imperfect silver bullet for the diversity of string types. Take a project that uses c++ libraries using std::string, Qt GUI and maybe a module that works with chunked strings (string composed out of a list of usually equally sized blocks of memory). At the boundaries of the software modules copies have to occur. Frequently the interface expects some kind of constant references to a certain string type. Most of the time the callee just wants to process the complete string or just a part of the string. So there might not even be the necessity to have random access hence no need for a contiguous copy of the string contents. Thats why I would prefer a facility that only requires that the source string is a forward range of characters in an arbitrary encoding. I do not think that it makes sense to only address contiguous sequences of characters. regards Andreas Pokorny

5 8

[rfc] loop utility
by Tim Blechmann 31 Jan '13

31 Jan '13

hi all, since c++11 has lambda functions, writing functors is easier than never before ... so, i wonder, what do people think about a small utility function, that calls a functor N times? ruby: 10.times { puts 'hello world' } supercollider: 10.do { "hello world".postln } c++11/boost proposal: boost::loop(10, [] { printf("hello world\n"); }); boost::loop(10, [](int index) { printf("hello %d\n, index); }); personally, i find this coding style more elegant than for loops, as it avoids the visual noise of explicitly counting a loop variable ... not sure, if it is worth a separate library, maybe it could just be added to boost/utility ... thoughts? prototype available at github: https://github.com/timblechmann/boost_loop tim

4 6

[release] some Boost.Build fixes
by Jürgen Hunold 30 Jan '13

30 Jan '13

Hi, I would like to merge 82654 and 82655 to the release branch. The first is the fix for issue #7920 and the latter a fix for a broken test case. Both only touch the qt5 toolset and tests. Bothe checked in yesterday and have cycled. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 5

[random] ranlux24_base(0) should be equal to ranlux24_base()
by Stephan T. Lavavej 30 Jan '13

30 Jan '13

Hi, After fixing a bug in VC11's <random> (see [1]), I compared VC's fixed output to Boost 1.52.0's output and I believe I found a bug in Boost. Here's a self-contained test case: C:\Temp>type meow.cpp #include <ios> #include <iostream> #ifdef USE_BOOST #include <boost/random.hpp> using std::boolalpha; using std::cout; using std::endl; using boost::random::minstd_rand0; using boost::random::mt19937; using boost::random::ranlux24_base; #else #include <random> using namespace std; #endif template <typename Engine> typename Engine::result_type run_10k(Engine engine) { for (int i = 0; i < 9999; ++i) { engine(); } return engine(); } int main() { cout << boolalpha; #ifdef USE_BOOST cout << "Using boost." << endl; #else cout << "Using std." << endl; #endif cout << "N3485 26.5.5 [rand.predef]/1 satisfied: " << (run_10k( minstd_rand0()) == 1043618065) << endl; cout << "N3485 26.5.5 [rand.predef]/3 satisfied: " << (run_10k( mt19937()) == 4123659995) << endl; cout << "N3485 26.5.5 [rand.predef]/5 satisfied: " << (run_10k(ranlux24_base()) == 7937952 ) << endl; cout << "I believe minstd_rand0(0) == minstd_rand0() should be true: " << (minstd_rand0(0) == minstd_rand0()) << endl; cout << "I believe mt19937(0) == mt19937() should be false: " << (mt19937(0) == mt19937()) << endl; cout << "I believe ranlux24_base(0) == ranlux24_base() should be true: " << (ranlux24_base(0) == ranlux24_base()) << endl; cout << "run_10k( minstd_rand0(0)): " << run_10k( minstd_rand0(0)) << endl; cout << "run_10k( mt19937(0)): " << run_10k( mt19937(0)) << endl; cout << "run_10k(ranlux24_base(0)): " << run_10k(ranlux24_base(0)) << endl; } With my fixed build of Milan/VC12, I'm getting: C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp meow.cpp C:\Temp>meow Using std. N3485 26.5.5 [rand.predef]/1 satisfied: true N3485 26.5.5 [rand.predef]/3 satisfied: true N3485 26.5.5 [rand.predef]/5 satisfied: true I believe minstd_rand0(0) == minstd_rand0() should be true: true I believe mt19937(0) == mt19937() should be false: false I believe ranlux24_base(0) == ranlux24_base() should be true: true run_10k( minstd_rand0(0)): 1043618065 run_10k( mt19937(0)): 1543171712 run_10k(ranlux24_base(0)): 7937952 (Note that VC11 RTM/Update 1 will suffer the bug described by [1].) If I use Boost's implementation with VC11 Update 1, I get: C:\Temp>cl /EHsc /nologo /W4 /MTd /DUSE_BOOST meow.cpp /I boost-1.52.0\include meow.cpp C:\Temp>meow Using boost. N3485 26.5.5 [rand.predef]/1 satisfied: true N3485 26.5.5 [rand.predef]/3 satisfied: true N3485 26.5.5 [rand.predef]/5 satisfied: true I believe minstd_rand0(0) == minstd_rand0() should be true: true I believe mt19937(0) == mt19937() should be false: false I believe ranlux24_base(0) == ranlux24_base() should be true: false run_10k( minstd_rand0(0)): 1043618065 run_10k( mt19937(0)): 1543171712 run_10k(ranlux24_base(0)): 14007167 Here's why I believe that ranlux24_base(0) should be equal to ranlux24_base(). ranlux24_base is a subtract_with_carry_engine. 26.5.3.3 [rand.eng.sub]/7 says: "explicit subtract_with_carry_engine(result_type value = default_seed); [...] linear_congruential_engine<result_type, 40014u,0u,2147483563u> e(value == 0u ? default_seed : value);" /7 doesn't refer to "value" anywhere else. Therefore, 0 should behave identically to the default_seed 19780503u. (For comparison, VC and Boost agree that minstd_rand0(0) == minstd_rand0(). 26.5.3.1 [rand.eng.lcong]/5 says: "explicit linear_congruential_engine(result_type s = default_seed); [...] If c mod m is 0 and s mod m is 0, sets the engine’s state to 1, otherwise sets the engine’s state to s mod m." The default_seed is 1u and minstd_rand0 sets c to 0, so that's why 0 behaves identically to the default_seed.) Stephan T. Lavavej Visual C++ Libraries Developer [1] http://connect.microsoft.com/VisualStudio/feedback/details/776456

2 2

permission to merge docu ?
by Oliver Kowalke 29 Jan '13

29 Jan '13

The release branch is closed because of building boost-1.53. I'd like to add a comment to boost.context documentation. Would this be possible? Oliver

2 1

[log][phoenix][spirit] Cygwin compiler crashes in actor_operator_10.hpp
by Bernd Prager 29 Jan '13

29 Jan '13

All, I am trying to compile the trunk version of Andrey Semashev's great Boost.Log library in Cygwin 1.7.17 with g++ 4.5.3. The line that crashes compiling his code is: $ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -fno-strict-aliasing -ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2\libs\log\build\gcc-4.5.3\release\link-static\threading-multi\formatt er_parser.o" ./libs/log/src/formatter_parser.cpp The result is: ... >> ./libs/log/src/formatter_parser.cpp:447:95: instantiated from here >> ./boost/phoenix/core/detail/preprocessed/actor_operator_10.hpp:31:2307: >> internal compiler error: Segmentation fault Andrey suggests it might be related to the Boost.Spirit parser rather then Boost.Phoenix. Could somebody please have a look at this? Thank you so much, -- Bernd

4 10

boost::filesystem::path frustration
by Dave Abrahams 29 Jan '13

29 Jan '13

I'm finding that boost::filesystem::path seems to be a strange mix of different beasts, unlike any entity we have in the STL. For example, when you construct it from a pair of iterators, they're expected to be iterators over characters, but when you iterate over the path itself, you are iterating over strings of some kind (**). Even though, once constructed, this thing acts sort of like a container, it supports none of the usual container mutators (e.g. push_back, pop_back, erase) or even queries (e.g. size()), making it incompatible with generic algorithms and adaptors. In particular, this comes up because I'm trying to find the greatest common prefix of two paths. I thought this would be easy; I'd just use std::mismatch. But even once I've found the mismatch I don't see any obvious way to chop off the non-matching parts of one of the paths. I end up having to resort to some really ugly code (or I just haven't figured out how to use this thing correctly). Why should paths be so different from everything else? I think, if the design is actually right, some rationale is sorely needed. Also, * (**) the docs don't say what the value_type of path::iterator is. A string value? A range that becomes invalid when the path is destroyed? Ah!?! How surprising; inspecting the code shows it iterates over paths! A container whose element type is itself is very unusual! * the docs claim you can construct a path from a "A C-array. The value type is required to be char, wchar_t, char16_t, or char32_t", but doesn't say how that array will be interpreted. From the wording I might have assumed it accepts a CharT(&)[N] and the length of the input is taken as N, but inspecting the code shows it expects a CharT* and interprets the source as null-terminated. Thanks, -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

15 32

[1.53.0] Beta release candidates 2 now available for testing
by Marshall Clow 28 Jan '13

28 Jan '13

Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 579b680bf55f53cd6d50adc391cb6c23 *boost_1_53_0_beta1_rc2.tar.gz 02098bb6da0e9c10712ae63c16e6aeea *boost_1_53_0_beta1_rc2.tar.bz2 998e2616a66c50e5693f563afb899002 *boost_1_53_0_beta1_rc2.zip e4fde6a869a3e21f8751ba8b7fd471a8 *boost_1_53_0_beta1_rc2.7z There were three changes between rc1 and rc2: * Fixes for compilation errors in Boost.Serialization * Documentation updates for Boost.SmartPtr * Updates to Boost.Threads Thanks, --The release managers

9 16

[release] permission to merge
by Vicente J. Botet Escriba 28 Jan '13

28 Jan '13

Hi, could I merge https://svn.boost.org/trac/boost/changeset/82659 (ticket https://svn.boost.org/trac/boost/ticket/7940) svn diff rel/boost/chrono/config.hpp Index: rel/boost/chrono/config.hpp =================================================================== --- rel/boost/chrono/config.hpp (revision 82662) +++ rel/boost/chrono/config.hpp (working copy) @@ -96,6 +96,9 @@ # undef BOOST_CHRONO_HAS_THREAD_CLOCK # undef BOOST_CHRONO_THREAD_CLOCK_IS_STEADY # endif +# if defined(__VXWORKS__) +# undef BOOST_CHRONO_HAS_PROCESS_CLOCKS +# endif # endif Best, Vicente

2 1