May 2014 - Boost - lists.preview.boost.org

JSON Archives for Boost.Serialization
by Matt Calabrese 08 May '14

08 May '14

I'm looking into implementing JSON archives to be used with Boost.Serialization in a manner similar to the xml archives. After a quick search I see that others have worked on this (2008 GSOC project?), though there is nothing currently in Boost that I see. Is there any existing work on this that is up somewhere before I implement my own from scratch? -- -Matt Calabrese

3 3

[thread] Request review of new synchronisation object, boost::permit<>
by Niall Douglas 07 May '14

07 May '14

Dear Boost, Review and commentary upon a proposed new Boost object, boost::permit<> is invited. A quick description of their purpose: "Permits come in two variants, consuming and non-consuming. There is always a one-to-one relationship between the granting of a permit and the receiving of that permit, the only difference with the non-consuming variant is that the permit is automatically regranted as soon as it is consumed. This leads to the only API difference to condition variables: permit<consuming=true> provides notify_one() but not notify_all(), whilst permit<consuming=false> provides neither and you will have to use grant() and revoke() instead. When deciding to substitute permits for condition variables, you will need to decide carefully which kind of permit is the correct substitute." "Permit objects are actually very similar to a void promise/future i.e. they act as a reusable promise/future pair but without transporting any value or exception state, just the permission to proceed. This is due to their original design intention, which was as a promise/future equivalent for C11 (see below for their history, and note that the original C API is available in the boost::c_permit namespace and documentation can be found at https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/lastSu ccessfulBuild/artifact/boost-trunk/boost/thread/permit/latex/pthread_p ermit_reference.pdf). As such, they can be very useful for situations where a promise/future is too heavy (permits can spin instead of sleep, plus they need not be repeatedly constructed and destructed)." There is lots more detail at their documentation page: https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/Boost. Thread_Documentation/libs/thread/doc/html/thread/synchronization/permi t_ref.html Source code of Permit containing fork of Boost.Thread: https://github.com/ned14/thread/tree/permit_object They come with a functional and load soak test suite. They work on Windows, Linux, FreeBSD and I believe OS X. Any other questions do ask. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

8 27

[TTI] macro to "box" types for subsequent traits extraction?
by Rein Halbersma 07 May '14

07 May '14

Hi everyone, this is my first post to this mailinglist, so I hope I follow the proper conventions around here (yes, I did read the Discussion Policy). I have a small feature request for the Type Traits Introspection library: a macro BOOST_TTI_BOX_TYPE(U) that defines a class template box_type<T> with a nested typedef named "type" that equals T::U. Rationale: because box_type<T> is a metafunction that can be supplied to mpl::eval_if, this facilitates user-defined traits that extract a nested type U, but can fall back to a (user-defined) default type. This mimics the C++11 allocator_traits that also provide defaults for allocators that lack certain nested typedefs or other properties. Small self-contained example: http://coliru.stacked-crooked.com/a/76b9abf4aaf00350 One could probably also define similar "boxing" macros to go along with the has_template and other introspection tools in TTI. Would this be considered a useful feature? Rein

3 4

[locale] Who owns/has commit access to review/merge a pull request?
by Chris Stylianou 07 May '14

07 May '14

I have a pull request on boost::locale (on the develop branch), but it appears there has no activity in this repository since the SVN -> Git migration occurred. Who actually maintains boost::locale? I would really like to have this pull request review and then hopefully merge, so that it makes the 1.56 release :) -- View this message in context: http://boost.2283326.n4.nabble.com/locale-Who-owns-has-commit-access-to-rev… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 5

Constant iterator of Single Pass Range
by Jan Hudec 07 May '14

07 May '14

Hello All, The documentation of [Single Pass Range][1] in Boost.Range says that there should be both `iterator` and `const_iterator` associated types and both const and non-const overloads for `begin` and `end`. However if it is really a single-pass range, I don't see a way to implement a `const_iterator` that would work on `const` reference to the range, because the `operator++` of the iterator involves calling a non-const method of the range. For example the `std::istream_iterator::operator++` calls `std::istream::operator>>`, which is non-const and so there is no `const_istream_iterator`. The `istream_range` cheats around this a little, because the range is a wrapper around the stream, not the stream itself. But when I have similarly behaving class that I can make itself be a range, do I really have to work around this using a wrapper, or can the requirement be relaxed in practice? [1]: http://www.boost.org/libs/range/doc/html/range/concepts/single_pass_range.h… -- Jan Hudec <bulb(a)ucw.cz>

4 8

[1.56] Release status?
by Joaquin M Lopez Munoz 06 May '14

06 May '14

Hi, Seems like Boost 1.56 release schedule has been postponed sine die. Is there any blocking issue with the SVN->Github transition that the release depends upon? Thank you, Joaquin M López Muñoz Telefónica

3 2

Help transfer type_index library to the boostorg
by Antony Polukhin 06 May '14

06 May '14

Hi, TypeIndex library was accepted into the Boost. Only a few minor issues remain unfixed so it's time to transfer the library to the boostorg. Unfortunately I have no permissions to do so. Could someone help? -- Best regards, Antony Polukhin

2 2

marking regression test failures as expected
by Andrzej Krzemienski 06 May '14

06 May '14

Hi, I noticed in the regression tests results taht some failing tests are marked as "fail*" in greyish color indicating that the failure is expected along with the explanation why. E.g., http://www.boost.org/development/tests/develop/developer/output/teeks99-03a… Question: how can I indicate that the new failure is expected in the same manner? Regards, &rzej

3 3

Anyone driving from/to Denver?
by Sebastian Redl 06 May '14

06 May '14

Hi, I could only get my bonus miles flights to Denver, not Aspen, so I'm wondering whether anyone else is only flying from/to Denver and driving the rest of the way. I would be interested in sharing that car. Please let me know. Sebastian

3 3

[atomic] Constraints on failure_order?
by Bjorn Reese 05 May '14

05 May '14

According to [1]: "The compare_exchange_weak/compare_exchange_strong variants taking four parameters differ from the three parameter variants in that they allow a different memory ordering constraint to be specified in case the operation fails." According to std::atomic there are some constaints on failure_order. Is this also the case for boost::atomic? [1] http://www.boost.org/doc/html/atomic/interface.html

2 1