- Boost - lists.boost.org

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

Boost.Format Library Maintenance
by James E. King, III 12 Oct '17

12 Oct '17

Currently the Boost.Format library is being maintained by the CMT. I would like to petition for that responsibility and lighten their case load further. I recently assumed maintenance for Boost.Uuid, and I have added Universal Windows Platform support to Boost.WinAPI and Boost.Predef so that folks will have an easier time making Windows Store compatible apps. I have also been working on a change that will add UWP support to Boost.Random and turn it into a header-only library, and expect to submit that in the next few days. I would like to shore up the CI environment for Boost.Format and groom the backlog in trac and on github, and get all the open issues resolved. Thanks for your consideration, Jim King

3 3

[Build] How to build libboost_lzma?
by degski 12 Oct '17

12 Oct '17

Up till now I have built libboost_zlib and libboost_bzip2 by setting ZLIB_SOURCE and BZIP2_SOURCE variables to their respective source directories on the bjam command-line and the libraries get built without fail. I gather (from the bjam output) their is now support for lzma, which I would like to use. I've tried a similar (did not find a doc) approach with LZMA by feeding "-sLZMA_SOURCE=c:\xz-5.2.3" (from https://tukaani.org/xz/xz-5.2.3.tar.gz) to bjam. This does not work. How do I make bjam build libboost_lzma? Thanks in advance. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 1

Boost Serialization: Serializing large objects
by Adlai Shawareb 12 Oct '17

12 Oct '17

We are trying to text serialize a 700 MB object. We are getting an archive_exception: input stream error. This is on a 32-bit QNX system. * Is there a limit to the size of the object that can be serialized? * Is there anything we can do to fix or work around this? Here is the code we are using: std::stringstream ss_; boost::archive::text_oarchive oa(ss_, boost::archive::no_header); oa << &object; Adlai

4 11

interest in a stateful pointer library?
by Hans Dembinski 11 Oct '17

11 Oct '17

Hi everyone, I wrote a variant of std::unique_ptr, called tagged_ptr, which allows safe read/write access to a customisable number of bits in the pointer variable. You can find the library on github: https://github.com/HDembinski/stateful_pointer You can use those bits to store extra state in the pointer variable at no extra space cost. I did some benchmarks to show that the computational overhead required for the bit manipulation is also negligible. One needs little imagination to find good use for those bits. As a proof of principle, I wrote an STL compatible string class which has the size of const char*, but can store up to 7 ASCII characters (on a 64 bit system) without allocating any memory on the heap (aka small string optimisation). The string class is also included in the library. To make this work, I use one of the bits in the pointer variable to recognise whether the variable should be interpreted as a pointer or as a char array. The Stateful Pointer library is C++11, header-only, and AFAIK platform-independent (in theory, this has not been tested so far). To create pointers which allow one to use a certain number of bits for other purposes, I rely on Boost.Align to allocate aligned memory. How does it work? Aligned memory, as the name implies, does not point to any address in memory, only certain addresses are allowed. For example, a two-byte aligned memory block can only have an even address. Therefore the lowest bit in the address is always zero. Since the bit is guaranteed to be zero, we can use it to store something else and mask it to zero whenever we need to dereference the pointer. I think this is a generally useful class to have in Boost, so is there some interest in polishing it up in a review process? Best regards, Hans

7 18

Master Regression Tests Failing
by Tom Kent 11 Oct '17

11 Oct '17

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas? Tom notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated" /var/boost/run/boost_root/libs/thread/build/Jamfile.v2:151: in modules.load from module Jamfile</var/boost/run/boost_roo t/libs/thread/build> /var/boost/run/boost_bb/src/build/project.jam:325: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:113: in load-parent from module project /var/boost/run/boost_bb/src/build/project.jam:464: in initialize from module project /var/boost/run/boost_bb/src/build/project.jam:306: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:145: in project.find from module project /var/boost/run/boost_bb/src/build-system.jam:535: in load from module build-system /var/boost/run/boost_bb/src/kernel/modules.jam:295: in import from module modules /var/boost/run/boost_bb/src/kernel/bootstrap.jam:139: in boost-build from module /var/boost/run/boost_regression/boost-build.jam:57: in module scope from module # Searching for "process_jam_log" in "/var/boost/run/boost_regression/stage/bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/var/boost/run/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/var/boost/run/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/var/boost/run/boost_regression_src/regression.py", line 581, in command_regression self.command_setup() File "/var/boost/run/boost_regression_src/regression.py", line 352, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "/var/boost/run/boost_regression_src/regression.py", line 715, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "/var/boost/run/boost_regression_src/regression.py", line 740, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log" in any of the following locations: /var/boost/run/boost_regression/stage/bin/process_jam_log /var/boost/run/boost_regression/stage/bin

9 19

[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