December 2016 - Boost - lists.boost.org

API/ABI changes report for Boost
by Ponomarenko Andrey 02 Dec '16

02 Dec '16

Hello, The report on API/ABI changes in the latest releases of Boost: https://abi-laboratory.pro/tracker/timeline/boost/ The report is generated by the open-source abi-tracker tool and updated three times a week. Hope it will be helpful for users and maintainers of the library. Thank you.

1 0

[poly_collection] Request for comments: fast polymorphic collections
by Joaquin M López Muñoz 02 Dec '16

02 Dec '16

A couple of years ago I wrote two blog entries about high-performance data structures for polymorphic objects: http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html that spurred some interest in the community. Now I've had the time to turn these ideas into something resembling a full-fledged library: https://github.com/joaquintides/poly_collection http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html and I'd be very grateful if people could give their opinion on usefulness, design, etc. so as to determine potential interest in an eventual official submission to Boost. Thank you, Joaquín M López Muñoz

6 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>After having a deeper dive into the documentation and examples, one >pattern I see popping up quite >frequently is this: >future<R> fut = my_promise.get_future(); >post_callback(some_work, [this](expected<R> r) { >this->my_promise.set_value(r.get()); }); >return fut; This is simply to make examples easier to run (it finishes the example). It demonstrates that the only one which blocks in an application built on Asynchronous is main(). This might be more confusing than useful and I probably should get rid of this. >Is there any performance/usability drawback from this (might have gotten >the syntax wrong here): >return post_future(pool, some_work); > >Why is the former to be preferred to the latter, or vice versa? post_future is the preferred for simple applications or examples. It is similar to std::async (without the problem of blocking futures and with different continuations). post_callback is the design the library seeks to promote for bigger applications: post a task to a threadpool, get a callback posted to the queue of the caller's thread world. >Regarding the documentation overall, >it seems to miss a proper reference section. >For example, boost::asynchronous::expected is used almost >everywhere, but not documented. My bad. Will be corrected. Thanks, Christophe

2 2

Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

Dear Community, The Asynchronous library is now listed in the Boost Library Incubator ( http://blincubator.com/bi_library/asynchronous-2/?gform_post_id=1654) I took a lot of time since first presenting it in C++ Now 2014 in order to extend the scope and intensively test the library. The library has been in use in production code for already 1.5 years, has survived billions of calls and usage 24/7, so its core is stable and quite tested. All algorithms have not been used though so that bugs are possible there. The reason for using the Incubator is, the library is quite big and 2 weeks review will not be sufficient so I hope for comments, discussions or pre-reviews earlier on. Asynchronous is first of all an architecture tool. It allows organizing a complete application into Thread Worlds, each world having the possibility to use the same or different threadpools for long-lasting tasks. The library provides an implementation of the Active Object pattern, extended to allow many Active Objects to live in the same World. It provides several Threadpools and many parallel algorithms making use of them. And most important of all, it allows simple, blocking-free asynchronous programming based on thread-safe callbacks. It also provides very useful logging and HTML diagnostics (see https://htmlpreview.github.io/?https://raw.githubusercontent.com/henry-ch/a…) to allow better understanding of code. I look forward to an interesting and lively discussion. Christophe

6 7

Upcoming review of the Synapse library starting tomorrow
by Edward Diener 01 Dec '16

01 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts tomorrow, December 2 and is scheduled to continue through December 11. I will be making an official announcement tomorrow, but I want to give the following information today for anyone wishing to acquaint themselves with the library. As explained previously by Emil Dotchevski when requesting that Synapse be put on the Boost Review list, Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at http://zajo.github.io/boost-synapse/Tutorial.html, or read full documentation at http://zajo.github.io/boost-synapse/index.html. The documentaion can also be viewed from the local clone at boost/libs/synapse/doc/index.html. I would urge anyone who may be interested in signal/slot processing in C++ to take a good look at the Synapse library. Edward Diener, review manager

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>I'm trying to digest the docs for this monster work. > >One things that strikes me immediately is that the doc preparation >does not use code snippets, and so code is in boring old >black'n'white rather than colored syntax. >For me, that makes it significantly harder to read (and understand) the code examples. Ok, I'll see if I can improve this. >It also means that one doesn't have the assurance that 'What You See is What Compiles'. For most features, the doc provides a link to an example, which I regularly compile. >(I've also having trouble finding things in all the plentiful 'good stuff'. >But that's a common (and largely still unsolved) >problem with all documentation.) >Paul Please let me know what is the "good stuff" for you and I'll make it more visible. Cheers, Christophe

2 1

[compute] Remove boost::chrono lib dependencie
by Viktor Sehr 01 Dec '16

01 Dec '16

Hi, Would it be possible to remove the dependency for boost/chrono is boost/compute/detail/duration.hpp. As it already supports std::chrono via a macro, couldn't the inclusion of boost/chrono.hpp be excluded? As it is now, boost compute is dependent on having libboost_chrono-vc140-mt-gd-1_62.lib built. /Viktor

4 4