October 2017 - Boost - lists.preview.boost.org

[ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 10 Oct '17

10 Oct '17

Hello, Here is my C++ GUI library based on Boost, it - is cross-platform - uses native system-provided widgets - has STL-like and Boost-like API - compatible with other Boost libraries - supports modern C++11/14/17 features Currently supported modules: - Graphics - Widgets * Command widgets * Data input-output widgets + Date and time pickers + Strings container widgets + Text widgets * Informational widgets + Logging * Containers + Alerts + Notifications + Prompts - Layouts - Events - Audio - Coordinates - Localization - Thread support - Helpers Documentation (and "Hello, World!" application source code): https://kosenko.github.io/boost.ui/ Source code: https://github.com/kosenko/ui Beman's challenge: https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp Re-implemented GUI examples from Bjarne Stroustrup's book: https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp Other examples: https://github.com/kosenko/ui/tree/master/example What do you think? Regards, Kolya Kosenko.

11 21

Boost Trac, random, No-Maintainer?
by James E. King, III 10 Oct '17

10 Oct '17

I filed 3 defects into Boost Trac for Boost.Random based on work I just did on adding CI integration, and the maintainer that Trac assigned to these new items was "No-Maintainer". That seems incorrect? The backlog in trac for random also has "No-Maintainer" assigned to all the items. For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247 - Jim

10 37

Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 10 Oct '17

10 Oct '17

During the formal review of Beast the desire was expressed to have parsing and serialization available independently of Asio. Unfortunately the obstacles to this are the concrete functions and types required for interoperability with the buffer sequence concepts defined in Asio. I have drawn up a solution to this problem which involves creating two brand new libraries. The first new library is called Boost.Buffers, and I described it partially in an earlier list posting. This library will contain copies of just the header files from Asio needed to implement the buffer sequence concepts. A preprocessor switch will allow users of Boost.Buffers to decide whether to use the copies of the headers, or to just include the Asio headers directly: <https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6…> If an author wants to develop a library which uses just the buffer sequence concepts from Asio, then instead of writing: #include <boost/asio/buffer.hpp> they will instead write: #include <boost/buffers/asio.hpp> in header files, and in their build scripts set: #define BOOST_NET_BUFFER_NO_ASIO 1 This way, their tests and example programs will use the copies of the asio headers found in the Boost.Buffers libraries and everything will work. Boost.Asio will not be a dependency. However, if a consumer of that library wants to also use Boost.Asio, they can do so by just not setting the macro in their build scripts (or explicitly setting it to 0). Now that we have a way to write a library that uses Asio buffer concepts without depending on all of Asio, we can move the Beast dynamic buffer implementations and buffer adapters into the Boost.Buffers library. Boost.Buffers will contain these public includes: Boost.Buffers <boost/buffers.hpp> <boost/buffers/asio.hpp> boost::asio::const_buffer boost::asio::const_buffers_1 boost::asio::mutable_buffer boost::asio::mutable_buffers_1 boost::asio::buffer_copy boost::asio::buffer_size boost::asio::buffer_cast boost::asio:is_const_buffer_sequence boost::asio:is_mutable_buffer_sequence <boost/buffers/buffers_adapter.hpp> <boost/buffers/buffers_cat.hpp> <boost/buffers/buffers_prefix.hpp> <boost/buffers/buffers_suffix.hpp> <boost/buffers/buffers_to_string.hpp> <boost/buffers/flat_buffer.hpp> <boost/buffers/flat_static_buffer.hpp> <boost/buffers/multi_buffer.hpp> <boost/buffers/ostream.hpp> <boost/buffers/read_size.hpp> <boost/buffers/static_buffer.hpp> Boost.Buffers would have dependencies on these Boost libraries: Array Assert Config Core Exception Intrusive StaticAssert ThrowException TypeTraits Beast will then be modified to take a dependency on Boost.Buffers to have access to all the buffer adapters and dynamic buffer implementations. Now that we have a new library which offers Asio buffer concepts and Beast's collection of useful dynamic buffers and buffer adapters, we can extract the HTTP parsing and serialization algorithms from Beast to form a new library: Boost.HTTPKit will contain these public includes: Boost.HTTPKit <boost/http/basic_file_body.hpp> <boost/http/basic_dynamic_body.hpp> <boost/http/basic_parser.hpp> <boost/http/buffer_body.hpp> <boost/http/chunk_encode.hpp> <boost/http/dynamic_body.hpp> <boost/http/empty_body.hpp> <boost/http/parse_error.hpp> <boost/http/field.hpp> <boost/http/fields.hpp> <boost/http/message.hpp> <boost/http/parser.hpp> <boost/http/rfc7230.hpp> <boost/http/serializer.hpp> <boost/http/span_body.hpp> <boost/http/status.hpp> <boost/http/string_body.hpp> <boost/http/string_param.hpp> <boost/http/type_traits.hpp> <boost/http/vector_body.hpp> <boost/http/verb.hpp> Boost.HTTPKit would have dependencies on these Boost libraries: Array Assert Config Core Exception Intrusive StaticAssert ThrowException TypeTraits This new library provides serialization and parsing of HTTP/1 messages to and from Asio buffer sequences, without requiring the full Boost.Asio dependency. The library also provides Beast's universal HTTP message container. Beast will be modified to take an additional dependency on Boost.HTTPKit. This solution satisfies long-stated needs of users to have HTTP parsing and serialization without Boost.Asio. However, there is one problem and that is the documentation. All of Beast's documentation related to buffer-oriented parsing and serialization, message containers, Body types, Fields concept, buffer sequences, and dynamic buffers will now be moved into two other libraries. This leaves the Beast documentation objectively worse off for users, as it is impossible to cross-link to other library documentation from inside a Javadoc comment extracted by Doxygen. I would like to hear ideas for how to smooth this out. Questions: How does the community feel about: * Boost.Buffers as a solution to accessing buffer concepts without Asio? * Boost.Buffers offering Beast's buffer sequence adapters and dynamic buffers? * Boost.HTTPKit depending on Boost.Buffers? * Boost.HTTPKit offering serialization and parsing without Asio? Any feedback is appreciated Thanks

3 5

[outcome v2] Proposed second review dates?
by Niall Douglas 10 Oct '17

10 Oct '17

Dear all, Now that the DoubleEnded review has finished, can I poll for preferred dates for a second Outcome review? Options: 1. Friday 1st December until Monday 11th December? 2. Friday 19th January until Monday 29th January? The reason for the delay is that the documentation writers are committed to other stuff until mid-November, plus there is the US Thanksgiving. Other than documentation, the library is ready to go at https://github.com/ned14/boost-outcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

[contract] Differential Sandia's regression tests for C++11, C++14, etc.
by Lorenzo Caminiti 09 Oct '17

09 Oct '17

Hello all, On the regression test site: http://www.boost.org/development/tests/develop/developer/contract.html How do I differentiate between the following? Sandia-clang-4.0-c++11 Sandia-clang-4.0-c++14 Sandia-clang-4.0 They all have the same toolset name clang-gnu-4.0.1 but they have different compiler options (C++11, C++14, original C++ standard). My tests are expected to fail only on Sandia-clang-4.0 but not on the first 2... I need different toolset names to selectively mark the failure expected in expected-failure-markup.xml: <mark-unusable> <toolset name="WHAT_SHALL_I_PUT_HERE?"/> <note author="Lorenzo Caminiti"> Most tests use C++11 lambda functions and variadic macros (even if technically the library itself does not require C++11). </note> </mark-unusable> Other toolset using ...~c++11, ...~c++1y prefixes for this, but Sandia does not. Thanks a lot. --Lorenzo

1 0

Need help >> Boost's managed_shared_memory usage in between two processes (C and C++)
by vijay sharma 09 Oct '17

09 Oct '17

Hi, I am having a Design/Implementation issue with Boost managed_shared_memory. Let me describe it: -------------------- Problem ------------------------- I am having two processes (i) Writer (ii) Reader Here Writer is a c++ executable which is using boost to write in shared memory. Code snapshot for writing method: shm_controller.reset(new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create, shmName, size));void * addr = shm_controller->allocate(size) ; shm_controller ->deallocate(addr); Once I have addr pointer, I am using memcpy to write in SHM. On other hand I am having Reader, which is C executable. They both are communicating via message passing application. I wrote Reader code in such way: Writer is passing address, which is stored in "addr" (from above code snapshot) to Reader. Once reader receive the address and size, I am using memcpy to write SHM data in Reader's local variable. Note1:- (This reader is not using any boost shm API, as it's C application ) Note2:- I validated address is same on Writer and reader (after communication). But reader's memcpy to read shm data is leading crash in my executable (reader). ------------------------------------------------------------- I need help in : 1) Can we use boost::interprocess::managed_shared_memory in C ?? 2) Is there any implementation problem in above section. (can't a reader access shm of writer via pointer) 3) Is there a way to solve this C and C++ limitation like any wrapper implementation etc. Please provide me any kind of help or pointers on this issue, as I am stuck with this and need to resolve it ASAP. Thanks, sharmavijay1991(a)gmail.com

2 3

Appveyor setup for msvc-14.1 toolset
by Edward Diener 09 Oct '17

09 Oct '17

I have added an Appveyor test to some Boost libraries, but if I specify toolset=msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 on the b2 test script command line the run fails when it gets to 14.1, due to not finding 'cl', but succeeds for the others. What is the magical Appveyor incantation to test the latest VC++ ? I would like to avoid the environment/matrix gunk I see in other appveyor.yml files, but if it is the only way to get msvc-14.1 tests with Appveyor I will use it.

3 3

[review] The review period of Boost.DoubleEnded has ended -- thanks to all involved
by Thorsten Ottosen 09 Oct '17

09 Oct '17

Dear users and members of Boost, We are now done with the review of Benedek Thaler's Boost.DoubleEnded library. Many thanks to all those involved in discussions and reviews. It will take me some time to digest all the feedback and get back with the review results. kind regards Thorsten, review manager -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

Boost.Http parser documentation ready (feedback welcome)
by Vinícius dos Santos Oliveira 09 Oct '17

09 Oct '17

Hi, first of all, do not confuse this “Boost.Http” library with the one who was rejected in the Boost review. I've received financing[1] from Boost to write an HTTP parser and here it is, just a parser. The documentation has 4 tutorials. You may have special interest in the “tutorial #4: implementing Boost.Beast parser interface” where I answer why you don't want to use Boost.Beast parser. https://vinipsmaker.github.io/asiohttpserver/ Feedback welcome. [1] https://gist.github.com/vinipsmaker/4998ccfacb971a0dc1bd -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

1 0

GITHUB - How does one add another maintainer to a repo
by Robert Ramey 08 Oct '17

08 Oct '17

I'm maintainer of the boost serialization library. Is there a simple way to give update permission to other persons? What is it. Ideally I'd like to do it at the branch level. I've looked through the GitHub help, and as usual, I'm mistified. Robert Ramey

2 2