- 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

[thread][build] develop terminally broken?
by John Maddock 07 Oct '17

07 Oct '17

All CI tests are currently failing with: ./b2 headers /home/travis/build/boostorg/boost-root/tools/build/src/build/feature.jam:140: in feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "win32" "pthread" : "optional" "propagated" /home/travis/build/boostorg/boost-root/libs/thread/build/threadapi.jam:4: in load from module threadapi /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in modules.import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:1069: in import from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> libs/thread/build/Jamfile.v2:39: in modules.load from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:325: in load-jamfile from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:64: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:89: in load-used-projects from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:75: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:145: in project.find from module project /home/travis/build/boostorg/boost-root/tools/build/src/build-system.jam:535: in load from module build-system /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/travis/build/boostorg/boost-root/boost-build.jam:17: in module scope from module Any ideas? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 5

[contract] auto_..._error regression tests fail on C++1z
by Lorenzo Caminiti 04 Oct '17

04 Oct '17

Hello all, I asked this question on compl.c++ list as well, given this is more of a general C++1z question than a Boost question. However, this is making some Boost.Contract regression tests fail on C++1z compilers so I wanted to ask it here as well hoping to get some info more quickly... Following code prevents copies outside its friend function f: // File: 05.cpp struct x { x() {} private: x(x const&) {} x& operator=(x const&) { return *this; } friend x f(); }; x f() { return x(); } int main() { auto xx = f(); return 0; } Correctly it does not compile up to C++1y because main cannot access the copy operations: $ clang++ -std=c++1y 05.cpp 05.cpp:14:15: error: calling a private constructor of class 'x' auto xx = f(); ^ 05.cpp:5:5: note: declared private here x(x const&) {} ^ 1 error generated. However, it compiles on C++1z?! $ clang++ -std=c++1z 05.cpp # Not compiler errors?! Why... what changed in C++1z that makes the above compile? How can I prevent copying x outside its friend function f in C++1z? Thanks, --Lorenzo

6 7

[outcome v2] How important is it that an Expected implementation is also provided?
by Niall Douglas 04 Oct '17

04 Oct '17

Dear list, I know it's been a fair few months since any news on Outcome v2. Ordinarily I'd be speaking at CppCon happening right now, but I instead chose Jens' Meeting C++ in November where I'll be speaking on Expected. Outcome v2 has undergone its period of maturation since it was completely rewritten to reflect peer review feedback last May. The new consensus design has fared very well after being put under heavy production use these last few months, and I expect it to return here for a second review before the end of this year. Outcome v2 will also be appearing in the WG21 October mailing, watch out for: * P0762R0: Concerns about `expected<T, E>` from the Boost.Outcome peer review * P0779R0: Proposing `operator try()` Outcome v2 currently implements the not published yet D0323R3 Expected proposal as part of its test suite as a refinement of what boost-dev thought Expected ought to be instead of what it is (ahem!). We run it against the Expected reference test suite, and it passes. So here's the question before any second peer review. Should Outcome v2 provide: 1. No Expected implementation at all, not even under a different name. Not its place. 2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`). 3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected. Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise. Thoughts? Niall [1]: Known differences from P0323R3 `expected<T, E>` in this implementation: - `T` and `E` cannot be the same type. - No variant storage is implemented (note that technically speaking, D0323R3 does not require variant storage). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 5

Boost CMake update
by paul 04 Oct '17

04 Oct '17

Hi all, So I have been working at converting more of boost tests to cmake utilizing the BCM library, here: https://github.com/boost-cmake/boost/tree/1.64 This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake: cd build mkdir build cmake .. cmake --build . --target check This will build all the tests. You can check the tests for one target with: cmake --build . --target check-boost_core Which will run the tests for just `boost_core`. This was all generated using scripts in https://github.com/pfultz2/boost-cmake I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in. Thanks, Paul .

8 35

[beast] Supporting ICY 200 OK
by Vinnie Falco 04 Oct '17

04 Oct '17

Bjorn brought up the point that there are some niche cases where applications do not strictly follow the HTTP message syntax for responses. Specifically, for Shoutcast(?) / Icecast mp3 servers the status-line in the response looks something like this: ICY 200 OK\r\n I have thought about ways to support this directly in Beast but I have decided against it. "ICY 200" is not HTTP according to the RFC, and trying to accommodate this use case places needless technical debt in public interfaces. However, I came up with a very simple technique to make this work with Beast by writing just a tiny bit of extra code. The solution is to implement a stream wrapper which meets the requirements of SyncReadStream[1] and/or AsyncReadStream[2] and forwards the calls to read to the "next layer" object, which will be the actual socket or ssl::stream. The implementation of the icy_stream wrapper can check to see if the first 3 bytes received from the next layer match "ICY" and if so, return a buffer to the caller which replaces those characters with "HTTP/1.1" (or "HTTP/1.0"). With this wrapper, calls to beast::http::read or beast::http::async_read can parse the custom response as a regular HTTP message. The wrapper can embed state information to inform the caller if the "ICY" string was not received. The declaration for such a wrapper might look like this: template<class NextLayer> class icy_stream; Usage for the wrapper: asio::ip::tcp::socket sock{ios}; icy_stream<asio::ip::tcp::socket&> stream{sock}; beast::http::response<beast::http::empty_body> res; beast::multi_buffer buffer; beast::http::read(stream, buffer, res); This technique may of course be generalized to support any desired similar but non-standard HTTP requests or responses in a fashion that is completely transparent to Beast. Thanks [1] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/SyncRead…> [2] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/AsyncRea…>

2 4

Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!
by Vinnie Falco 04 Oct '17

04 Oct '17

On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > My preview of Boost.Asio version 1.66.0 is here: > > <https://github.com/vinniefalco/boost.asio/commits/net-ts> Upon re-reading the message I realize that it might be confusing, so to clarify - this is NOT an "official" version of Boost.Asio it is just an experimental branch of what Boost.Asio might look like soon, for anyone who wants to try out the latest stand-alone Asio features in the Boost.Asio context. Thanks

2 5

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

03 Oct '17

During the formal review of Beast, desires were expressed to use components like the HTTP parser and serializer independently from the rest of the library. The sticking point was the abstraction used to represent a range of non-owning buffers. In particular, Asio imposes certain concrete type requirements in its ConstBufferSequence and MutableBufferSequence concepts. It would seem there is significant interest in making some components of Beast modular, in their own libraries. The main feature of these components would be that they should not require Boost.Asio. Unfortunately, the way Asio's concepts are defined this is not possible. Two solutions present themselves: 1. Create a new buffer sequence concept which retains all the features of Asio's concepts but does not require the concrete types. While this is possible it would create a significant complication. Interfaces which use the new concept would require some kind of adapter at every call site that tries to use a traditional Asio style interface. 2. Create a new library which uses conditional compilation to either include just the Asio header files which fulfill the needs for interacting with buffer sequence concepts, or provide the declarations directly from a copy of the Asio sources. The solution used in Boost.Buffers (a new library I am considering proposing) is choice number two. Someone who wants to create a new library ("Foo") that does no network I/O but wants to interoperate with Asio buffer concepts merely need to do the following #include <boost/buffers.asio.hpp> and then, in their build script for the tests and examples, set: #define BOOST_NET_BUFFER_NO_ASIO 1 This works because Boost.Buffers contains copies of all the necessary header files to work with buffer sequences, and JUST those header files. All of Boost.Asio is not necessary: <https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6…> Now if someone wants to use library Foo they will also be getting a dependency on Boost.Buffers. If that user doesn't need Asio, then they will also set the macro to 1 in their build script. However. if that user wants to use Asio in their program or library, they just set #define BOOST_NET_BUFFER_NO_ASIO 0 and now Boost.Buffers will simply include the relevant Asio header files. This library will allow the creation of new libraries which use Asio buffer concepts, but do not require all of Boost.Asio as a dependency, as well as all the things that Boost.Asio is dependent on, which is non-trivial as can be seen here: <https://github.com/boostorg/beast/blob/develop/.travis.yml#L140> I would like feedback on this library before I move forward with it, as you can imagine it has some controversial aspects to it. Boost.Buffers is here: <https://github.com/vinniefalco/buffers> Thanks

1 0

[beast] The Networking-TS version of Boost.Asio and Boost.Beast is here!
by Vinnie Falco 03 Oct '17

03 Oct '17

I have taken the tip of standalone Asio, from: <https://github.com/chriskohlhoff/asio/commits/asio-1-10-branch> and applied this "boostify.pl" script: <https://github.com/chriskohlhoff/asio/blob/asio-1-10-branch/asio/boostify.pl> plus a bit of manual fixing, to produce a new branch of Boost.Asio which is up-to-date with respect to the stand-alone Asio. This means you can have access to the Networking-TS changes that will be introduced in Boost.Asio (according to the author, this will be in Boost 1.66.0). My preview of Boost.Asio version 1.66.0 is here: <https://github.com/vinniefalco/boost.asio/commits/net-ts> Beast has been ported to this version of Asio, you can try it here: <https://github.com/vinniefalco/beast/commits/net-ts> When Boost.Asio is updated for 1.66.0 to bring it in-line with the standalone Asio (which supports Networking-TS), Beast will simultaneously be updated. Hopefully this will all be done in time for 1.66.0, so that users of the debut version of Beast will have the latest interfaces available for their use. Thanks!

1 0

Modularizing explicit-failures-markup.xml
by Daniel James 03 Oct '17

03 Oct '17

Hi, I'm looking into implementing a mechanism for updating explicit-failures-markup.xml without updating the super project. My basic idea is that modules can have a 'status/explicit-failures-markup.xml' file, and I'll write a script to update the super project file from modules. It will have the same format as the super project file, so can just copy and paste the relevant parts into your module. Does that sound okay? It might be better if the regression scripts handled this themselves, but I'm not sure if anyone would be available to implement that. Daniel

6 12

[asio] Verify SSL certificates using the OS-specific certificate store
by Vinnie Falco 01 Oct '17

01 Oct '17

My understanding of boost::asio::ssl::context is that it is just a small wrapper around OpenSSL. You can set default verify paths, but that assumes the certificates are in a particular directory which they almost never are. For example they might be in some OS-specific type of database which need system calls to access. If a program wants to use the native operating system facilities for verifying certificates, then I believe significant additional code is needed. Is this correct? I am interested in writing a simple function object which will validate a hostname and its accompanying certificate against the operating-system-dependent certificate authorities. Is there some code somewhere that does this? Any resources that I can be pointed to would be of immense value. Thanks

2 1

Re: [boost] [beast] Supporting ICY 200 OK
by Bjorn Reese 01 Oct '17

01 Oct '17

On 10/02/2017 12:06 AM, Vinnie Falco wrote: > However, I came up with a very simple technique to make this work with > Beast by writing just a tiny bit of extra code. The solution is to > implement a stream wrapper which meets the requirements of > SyncReadStream[1] and/or AsyncReadStream[2] and forwards the calls to > read to the "next layer" object, which will be the actual socket or > ssl::stream. Sounds like a good solution.

1 0

[review] The review period of Boost.DoubleEnded has been extended with one week. Now ends 7th of October.
by Thorsten Ottosen 28 Sep '17

28 Sep '17

Dear users and members of Boost, People have been requesting extra time for the review of Boost.DoubleEnded. We therefore continue one week extra, so the final date will be October the 7th. kind regards Thorsten Original review announcement ------------------------------------------ I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Boost.DoubleEnded as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

[admin] Turning on Issues tab on Github for Boost libraries
by Edward Diener 28 Sep '17

28 Sep '17

Can we not have some resolution from an administrator about turning on the Issues tab in Github for Boost libraries ? There are two 'admin' issues regarding this and, since it should be a quick job for an administrator to implement this, I would really prefer not to wait for a long time for this to get done. Just now I had a "bogus" PR for iostreams, which I rejected, and the explanation from the person who created the PR was that the PR was "created" because there was no Issue tab for the library and he was only trying to create an Issue to be looked at. There is absolutely no logical reason that I can think of why the Issue tab on Github cannot be turned on for Boost libraries, to benefit end-users.

3 3

Re: [boost] [ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 28 Sep '17

28 Sep '17

On 09/28/2017 03:02 PM, Stefan Seefeld via Boost wrote: >> - uses native system-provided widgets > > what widgets do you consider "system-provided" ? What backends do you > bind to on the different platforms, and can those bindings be changed ? Native system-provided widgets means widgets from toolkits GTK+, Qt, Windows Controls, Cocoa etc. >> - compatible with other Boost libraries > > What does that mean ? Boost.Geometry and Boost.Polygon could be used with Boost.UI coordinates, Boost.Chrono - boost::ui::on_timeout() function, Boost.Date_Time library are used in date and time pickers etc. > I'd be interested in some high-level documentation explaining the basic > programming and execution model of the API. You can ask for implementation details here. Documentation explains only API. > For example, how are events > handled and how are they bound to particular actions ? Library subscribes to event handlers in native toolkit. When user press button, native event handler eventually calls Boost.UI event handler. > Are programs > inherently multi-threaded or single-threaded (e.g., does the main event > loop run in its own thread) ? There is main GUI thread and you should call GUI functions from other your own threads using boost::ui::call_async() function. Boost.UI library (like all other C++ GUI libraries) aren't thread safe because native toolkits are not thread safe. > Is your library mostly just a (thin) layer over existing > platform-specific GUI libraries, or does it reimplement a lot of the > logic itself ? Boost.UI is a rather thin layer with C++11/Boost support. > (And what is that cryptic "ui_main()" function ? :-) ) ui_main() function call required for GUI initialization, deinitialization, cleanup. It is required for underlying toolkits. Actually you can call some functions directly from main() function, but it is at your own risk. Regards, Kolya.

2 4

[1.65] [process] Library version outdated
by Andrey Semashev 28 Sep '17

28 Sep '17

Hi, It looks like something is broken in the release procedure, which resulted in all Boost 1.64.0, 1.65.0 and 1.65.1 to contain the same revision of Boost.Process 4075371cbe78dab8f43578c655747c831b554318 (you can see that by git tags). This revision is dated Wed Apr 5 11:32:27 2017, which is more like when 1.64.0 was being prepared. I know that 1.65 has long sailed, but can the release managers double check that this doesn't happen in 1.66? As a possible clue, on the local checkout I didn't have a head for the master branch for Boost.Process for some reason. I surely wasn't doing anythhing special with its repository, but maybe something happened on the remote side that caused this. I solved the problem locally by removing libs/process, .git/modules/process and running `git submodule update --init --recursive`.

3 3