- Boost - lists.preview.boost.org

[graph] Sync develop with master?
by Murray Cumming 12 Aug '16

12 Aug '16

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release. -- Murray Cumming murrayc(a)murrayc.com www.murrayc.com

5 21

[thread][circular_buffer] Unmerged changes for 1.62
by Andrey Semashev 12 Aug '16

12 Aug '16

Hi, There are a couple of my PRs hanging for quite some time that I'd like to be merged before 1.62 is released: https://github.com/boostorg/circular_buffer/pull/9 Changes the default implementation of circular_buffer in debug mode to the thread-safe by default. https://github.com/boostorg/thread/pull/92 Fixes compilation of Boost.Thread with MSVC-8. There is also https://github.com/boostorg/thread/pull/94, which is not mine but it looks like it fixes a genuine problem. Could someone have a look at them and merge? Thanks.

2 3

[interprocess] weirdest bug with offset_ptr equality comparison
by Joaquin M López Muñoz 11 Aug '16

11 Aug '16

The following is a distilled testcase after the ticket reported at https://svn.boost.org/trac/boost/ticket/12367 #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/managed_shared_memory.hpp> template<typename Allocator> struct node_base { using allocator_type=Allocator; }; template<typename Allocator> struct node_impl { using value_type= typename Allocator::template rebind<node_impl>::other::value_type; }; template<typename Super> struct trampoline:node_impl<typename Super::allocator_type>{}; template<typename Super> struct node:Super,trampoline<Super>{}; int main() { using node_type= node< node< node_base< boost::interprocess::allocator< int, boost::interprocess::managed_shared_memory::segment_manager > > > >; using pointer=boost::interprocess::offset_ptr<node_type>; pointer p=nullptr; bool b=(p==p); // here's the problem } This works fine with GCC. When compiled with Visual Studio 2015, we get: 1>------ Build started: Project: borrame2015, Configuration: Debug x64 ------ 1> sandbox.cpp 1>d:\usr\joaquin\proyectos\boost-repo\trunk\boost\interprocess\detail\mpl.hpp(74): error C2594: 'argument': ambiguous conversions from 'node<node<node_base<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>>>> ' to 'node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>> ' 1> with 1> [ 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>, 1> IndexType=boost::interprocess::iset_index 1> ] 1> d:\usr\joaquin\proyectos\borrame2015\sandbox.cpp(39): note: see reference to class template instantiation 'boost::interprocess::ipcdetail::is_convertible<node_type *,PointedType *>' being compiled 1> with 1> [ 1> PointedType=node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>,boost::interprocess::iset_index>>> 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Note that it is the line bool b=(p==p); // here's the problem that triggers the problem; if removed, compilation goes fine. Almost anything in the testcase program is needed for the problem to arise: - using node_type=node<node<...>> --> using node_type=node<...> (just one node level): compilation OK - remove using value_type=... in node_impl: compilation OK - rebind<node_mpl> --> rebind<char>: compilation OK - use std::allocator rather than boost::interprocess::allocator: compilation OK Ion, I'm totally puzzled by this and unable to navigate through the internals of Boost.Interprocess. Totally at your disposal if you need further info or assistance running tests etc. Thank you, Joaquín M López Muñoz

2 3

[contract] noexcept and throwing handlers
by Lorenzo Caminiti 10 Aug '16

10 Aug '16

Hello all, I would like to discuss contracts and exception specifications (e.g., noexcept) specifically with respect to what Boost.Contract does. On one hand, it seems silly to allow a contract failure handler to throw an exception to only translate such an exception into a call to terminate() for noexcept functions. However, noexcept can be considered part of the function contract (namely, the contract that says the function shall not throw) and contract failure handlers should not be allowed to break such contract, not even when they are allowed to throw. For example consider a noexcept function fclose() that is called from a destructor without a try-catch statement (correctly so because fclose is declared noexcept). If fclose() is now allowed to throw when its preconditions fail, that will cause the destructor ~x() to throw as well?! void fclose(file& f) noexcept [[requires: f.is_open()]] ... class x { ~x() noexcept { fclose(f_); // f_ might not be open because of some bug... ... } file f_; }; (A point similar to the above is also made in N4160, in contrast with what argued in N4110.) Functions should honor their exception specifications (noexcept, etc.) even when their contracts fail and contract failure handlers are configured to throw. That is what Boost.Contract does (given that contract checking code appears within the function definition so it is subject to the exception specifications that appear in the enclosing function declaration): void fclose(file& f) noexcept { // This will call terminate()... boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(f.is_open()); // ...even if this throws. } ; ... } int main() { boost::contract::set_precondition_failure( [] (boost::contract::from where) { // Re-throw exceptions (assertion_failure, user-defined, etc.). if(where != boost::contract::from_destructor) throw; std::terminate(); // But destructors never throw. } ); ... } Also note that a contract framework that allows to install failure handlers that throw exceptions should also pass some sort of parameter to the handler function to indicate if the contract failure happened in a destructor or not. That is so the failure handlers can choose to never throw for destructors, not even if class invariants (or postconditions) fails when checked by destructors. --Lorenzo

3 4

[release] Continuous release archives.
by Rene Rivera 09 Aug '16

09 Aug '16

Starting with this release the archives for the prospective beta and release candidates are continuously built from the master branch and uploaded to SourceForge [1] (and to Bintray [2]). The release team would really appreciate if authors would download the archives and check the contents. In particular that the archives contain all the content you expect of your library, or libraries. And if you can also try building in your system that would stupendous. The more eyes we have on the final release products the smoother the process will be. And result in more time that the master branch is not blocked. Please report any problems sooner rather than later. So that we can try and address them before it's took late. Thank you, The Release Team [1] <https://sourceforge.net/projects/boost/files/boost/snapshots/master/> [2] <https://bintray.com/boostorg/master/snapshot#files> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 7

Feature suggestions for Boost's program_options
by Eyal Rozenberg 09 Aug '16

09 Aug '16

Greetings Boost developers, [ Disclaimer: I'm new to this list - I joined by Vladimir Prus' suggestion that I raise my feature ideas here on the list. I've read the posting guidelines, and I haven't seen any discussion of program_options (at least not by Vladimir himself) for at least a year back in the list archives, so I think my post is legit. ] I've been using Boost's program_options library for several months now. It mostly does the job (that's a compliment...) - but there are some features whose lack is really bugging me. For some of them (especially Feature Idea 1) I actually work around by taking some options as unparsed remainders, sticking them in a string->string map and parsing them myself. Without further ado, and in decreasing order of importance to me: -------------------------------- Feature Idea 1: Support specifying multiple alternative long option names, using comma-separation. Right now we can specify, for example, "include-path,I" - one short form, one long form. Why not allow specifying "include-path,include-dir,headers-path,I" ? Only the first long option name would be printed as part of the usage information, to not complicate things overmuch, and merely tolerate alternative phrasing. Feature Idea 2: Have a (new?) parser which supports taking "semi-parsed command-line options" as input: A map from string keys to string values, or to optional<string> values to represent options without an argument as well. This is actually very close to environment parsing, except that the environment parser gets its "map" from, well, the environment variables. So the implementation might be simply exposing the existing functionality with a slightly richer interface. Feature Idea 3: A facility for pretty-printing parsed options to an std::ostream, in which the option description starts the line, and the option value (not the name used for parsing) is printed after it. There is some pretty-printing for the usage info to the console, so why not this? (Argument against this idea: Choosing a default is a very touchy subject. Counter-argument: ... but that's also somewhat true of printing usage information; and nobody has to use this default, it would be entirely optional.) Feature Idea 4: Support three rather than just two levels of describing options: name, for the command line; short description, for listing values (see Feature Idea 3; long description for the usage info. Feature Idea 5: Create a variant of update_with which doesn't just set the option value, but creates a link of sorts between the variable which the app would use and the variable_map entry. With this in place, further changes to the variable map automagically affect the app variable. -------------------------------- So, - What do you think about these suggestions, in principle? - If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? - Assuming a feature idea is both relevant and feasible, is it customary to request implementation by the maintainer? Commit yourself to implementing it vis-a-vis statement of statement of partiality to accepting a patch? Some other practice? Thank you for getting through the long(ish) email and for your hard work, Eyal Rozenberg DB architecture group CWI Amsterdam

3 4

[release] Boost 1.62 closing for new libraries this week
by Rene Rivera 07 Aug '16

07 Aug '16

Hopefully everyone has had a good Summer and has gotten all the new libraries and breaking changes in.. As we are closing the release window for that this week. Please consult the calendar [1] for the full release schedule. And take this as a reminder to merge your changes that you want in the next release as soon as possible. [1] <http://www.boost.org/development/index.html> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[boost-process] Beta & Review
by Klemens Morgenstern 07 Aug '16

07 Aug '16

Hi, boost-process is now in beta, you can check it out here: https://github.com/klemens-morgenstern/boost-process and read the doc here: http://klemens-morgenstern.github.io/process/ It will probably be in review in the beginning of November, Antony Polukhin will be the review manager. I really hope I'll get some feedback before that, so I can work on the weak points and also get more detailed in the documentation. Thanks, Klemens

4 10

[boost-spirit-qi] Support for n-ary operators PR
by Frank Hein 06 Aug '16

06 Aug '16

Hello, some days ago I raised an PR (https://github.com/boostorg/spirit/pull/200) which adds support for a new class of parsers, in particular named n-ary operators. Joel de Guzman reviewed that. The code is ok. Because this addition touches the inner core of qi, the metagrammar, Joel asked me to drum for support in the community. So if you are in qi, may I kindly ask you to review this PR, the code, the discussion so far, and respond, if you want to support this PR or if you think, it's not needed. Thank you very much. I highly appreciate your feedback. The PR description is very detailled, so this mail has not to be. :) Regards, Frank

1 0

Review Schedule and Review Manager for PODs Flat Reflection (ex magic_get)
by Antony Polukhin 05 Aug '16

05 Aug '16

Hello, PODs Flat Reflection (or PFR) is a C++14 library that represents POD structures as tuples and provides tuple-like methods for PODs. Library has a set of predefined operators for PODs and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Could the PODs Flat Reflection library be put on review schedule? Anyone wishing to become a Review Manager for the library? -- Best regards, Antony Polukhin

6 9