January 2019 - Boost - lists.boost.org

A class for embedded friendly callbacks.
by Mikael Rosbacke 07 Jan '19

07 Jan '19

Greetings. I'm Mikael Rosbacke and new to this list. The last couple of months I've been writing on a class for storing callbacks to different forms of callables (member functions, functors, free functions). The main focus has been to make it suitable for embedded work with small footprint and dependable exception and heap behavior. The code can be found on github: https://github.com/rosbacke/delegate It has reached a stage where I'm getting sort of 'done'. I feel it could be useful to a wider audience so I would like to get some feedback about if this is suitable for that and if it is worth starting a new branch for possibly adapting it to boost for inclusion in some future version of boost. Any feedback is appreciated. Cheers, --- Mikael Rosbacke

2 2

Should pass boost::asio::io_service by raw pointer or smart pointer?
by hh h 07 Jan '19

07 Jan '19

Hi, In many examples and even implementations, programmers like to pass boost::asio::io_service by raw pointer: MyClass::MyClass(boost::asio::io_service &io_service) : myRawIoService(io_service) {} Will this cause issues to pass raw pointer for large size of classes, should it be replaced by passing smart pointer: MyClass::MyClass(const std::shared_ptr<boost::asio::io_service> &io_service) : myIoService(io_service) {} Thank you.

5 9

Is there interest in an "iofiber" library?
by Vinícius dos Santos Oliveira 06 Jan '19

06 Jan '19

I have written a completion token for Boost.Asio that is a little more advanced than plain ASIO's spawn featuring abstractions such as join(), detach() and even interrupt(). I'd like to know if there is interest in seeing this library merged as part of Boost. https://vinipsmaker.github.io/iofiber/ (there is also a mutex and a semaphore, but these are undocumented as of now and were poorly ported from the previous token supporting abstractions and need rework) Boost.Fiber integration with ASIO is problematic: https://github.com/boostorg/fiber/issues/102#issuecomment-263558882 Default Boost.Asio yield token will do as long as you don't need communication between fibers. When primitive communication is necessary, you can work around it by exploiting the completion token protocol. In fact, after having rolled my own solution, I eventually was made aware of Peter's solution (which he rolled on his own independently) which was incredibly similar to my solution: https://github.com/equalitie/ouinet/blob/a2afaf9932c8a23434d1f0a10be06fc407… If you need anything more advanced such as careful strand integration, join, or interruption API, you'll just have to roll your own token. That's what I end up doing after working around ASIO's token for many months. There was also a recent request by Vinnie to turn Boost.Coroutine 1 deprecation warning off. This separate library would be an alternative (although it is still a far from review-ready). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

3 4

Re: [boost] Skipping regression builds for unsupported toolsets
by Nikita Kniazev 05 Jan '19

05 Jan '19

> > How can I 'tell' regression builders to skip building GIL > where required C++ version is not supported? Add requirements to you tests Jamfile, something like: import config : requires ; project /boost/gil/test : requirements [ requires cxx11_constexpr cxx11_decltype cxx11_template_aliases cxx11_variadic_templates ] (those checks come from Config library which most likely you are pulling already in your CI builds). I noticed that some libraris specify "std" in libraries.json, for example: > - Any: "std": [ "c++17" ] > - Ratio: "std": [ "proposal" ] > What is the purpose of these? > Is this respected by regression builds? I doubt those do anything. IIUC `libraries.json` is used only for https://www.boost.org/doc/libs/ list generation.

2 1

Skipping regression builds for unsupported toolsets
by Mateusz Loskot 05 Jan '19

05 Jan '19

Hi, The regression builds report unreloved issues for number of libraries: https://www.boost.org/development/tests/develop/developer/issues.html In particular, for Geometry and GIL those issues happen on msvc-8.0. For GIL, specifically, this is due to the fact GIL now requires C++11. How can I 'tell' regression builders to skip building GIL where required C++ version is not supported? I noticed that some libraris specify "std" in libraries.json, for example: - Any: "std": [ "c++17" ] - Ratio: "std": [ "proposal" ] What is the purpose of these? Is this respected by regression builds? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

iround() and itrunc() in Conceptual Requirements for Real Number Types
by Matt Pulver 04 Jan '19

04 Jan '19

Hello, Regarding the page Conceptual Requirements for Real Number Types https://www.boost.org/doc/libs/1_69_0/libs/math/doc/html/math_toolkit/real_… Is it still accurate to list these 2 rows under Standard Library Support Requirements? - iround(cr1) | int - itrunc(cr1) | int The motivation in asking this is two-fold: 1. I don't see either of these functions listed in the Standard Library. Perhaps this is just old documentation, or I am not looking in the right place. Instead, I do find lround() and truncl(). 2. One of the design goals of Boost.Autodiff (WIP) is to satisfy all of the requirements on this page, and these are the only two which I am unable to satisfy for the above reason. If someone were to update this page, or otherwise advise on how to reconcile, it would be appreciated so that the Boost.Autodiff <https://github.com/pulver/autodiff> library could accurately claim to satisfy 100% of Boost's Real Number Type requirements. Best regards, Matt

2 2

Could shared_ptr cause memory leak?
by hh h 04 Jan '19

04 Jan '19

Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak? class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared<B>(shared_from_this());} void Stop(); private: shared_ptr<B> b; };

3 6