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

Master branch now open for merging
by Marshall Clow 13 Jul '17

13 Jul '17

I will be uploading 1.65.0 beta1 this morning. Hint: It's the same as rc2 ;-) -- Marshall

2 1

[fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 13 Jul '17

13 Jul '17

Hi, A #include "Windows.h" causes troubles when cross-compiling on Linux in C++14 mode with MinGW-W64 with Posix threads. Can we change it to "windows.h"? Here is a PR: https://github.com/boostorg/fiber/pull/134 Thanks, Frédéric

2 2

[Boost.Range] Documentation
by degski 12 Jul '17

12 Jul '17

I had a need to try and understand Boost.Range. I don't know what to say, did this documentation pass a review? Introduction first "example": Example - Iterate over the values in a map using namespace boost; using namespace boost::adaptors; for_each( my_map | map_values, fn ); 3 lines, out of which 2 'using' lines, that make this "example" even less informative than it might have been without them, in wich case I would at least have known in which namespace(s) these things are living. Ah, wait, there's also an example section, so I'll copy the first example <http://www.boost.org/doc/libs/1_64_0/libs/range/test/string.cpp> in here: // Boost.Range library // // Copyright Thorsten Ottosen 2003-2004. Use, modification and // distribution is subject to the Boost Software License, Version // 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // // For more information, see http://www.boost.org/libs/range/ <http://www.boost.org/doc/libs/1_64_0/libs/range/> // //#define _MSL_USING_NAMESPACE 1 #include <boost/detail/workaround.hpp <http://www.boost.org/doc/libs/1_64_0/boost/detail/workaround.hpp>> #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn -8091 // suppress warning in Boost.Test # pragma warn -8057 // unused argument argc/argv in Boost.Test #endif #include <boost/array.hpp <http://www.boost.org/doc/libs/1_64_0/boost/array.hpp>> #include <boost/range/as_array.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/as_array.hpp>> #include <boost/range/as_literal.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/as_literal.hpp>> #include <boost/range/functions.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/functions.hpp>> #include <boost/range/metafunctions.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/metafunctions.hpp>> #include <boost/static_assert.hpp <http://www.boost.org/doc/libs/1_64_0/boost/static_assert.hpp>> #include <boost/type_traits.hpp <http://www.boost.org/doc/libs/1_64_0/boost/type_traits.hpp>> #include <boost/test/test_tools.hpp <http://www.boost.org/doc/libs/1_64_0/boost/test/test_tools.hpp>> #include <boost/config.hpp <http://www.boost.org/doc/libs/1_64_0/boost/config.hpp>> #include <vector> #include <fstream> #include <algorithm> namespace { template< class CharT, std::size_t Length > class test_string { public: typedef CharT value_type; typedef value_type* pointer; typedef const value_type* const_pointer; typedef std::size_t size_type; typedef value_type array_t[Length]; typedef const value_type const_array_t[Length]; explicit test_string(const CharT literal_sz[]) { std::copy(literal_sz, literal_sz + Length, m_buffer.data()); m_buffer[Length] = value_type(); } const_pointer const_sz() const { return m_buffer.data(); } pointer mutable_sz() { return m_buffer.data(); } private: typedef boost::array<value_type, Length + 1> buffer_t; buffer_t m_buffer; }; } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_iterator<T>::type str_begin( T& r ) { return boost::begin( boost::as_literal(r) ); } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_iterator<T>::type str_end( T& r ) { return boost::end( boost::as_literal(r) ); } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_difference<T>::type str_size( const T& r ) { return boost::size( boost::as_literal(r) ); } template< class T > inline bool str_empty( T& r ) { return boost::empty( boost::as_literal(r) ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<Container>::type find( Container& c, T value ) { return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<const Container>::type find( const Container& c, T value ) { return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<Container>::type find_mutable( Container& c, T value ) { str_size( c ); return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<const Container>::type find_const( const Container& c, T value ) { str_size( c ); return std::find( str_begin(c), str_end(c), value ); } std::vector<char> check_rvalue_return() { return std::vector<char>( 10, 'm' ); } using namespace boost; void check_char() { typedef boost::range_difference<std::string>::type diff_t; typedef char* char_iterator_t; typedef char char_array_t[10]; test_string<char, 8> a_string("a string"); test_string<char, 14> another_string("another string"); const char* char_s = a_string.const_sz(); char my_string[] = "another_string"; const char my_const_string[] = "another string"; const diff_t my_string_length = 14; char* char_s2 = a_string.mutable_sz(); BOOST_STATIC_ASSERT(( is_same< range_value<char_iterator_t>::type, detail::iterator_traits<char_iterator_t>::value_type>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_iterator_t>::type, char_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<char_iterator_t>::type, ::std::ptrdiff_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<char_iterator_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_iterator_t>::type, char_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char*>::type, const char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_value<char_array_t>::type, char>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_array_t>::type, char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char_array_t>::type, const char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<char_array_t>::type, ::std::ptrdiff_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<char_array_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_array_t>::type, char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char_array_t>::type, const char* >::value )); BOOST_CHECK_EQUAL( str_begin( char_s ), char_s ); const diff_t sz = str_size(char_s); const char* str_end1 = str_begin( char_s ) + sz; BOOST_CHECK_EQUAL( str_end( char_s ), str_end1 ); BOOST_CHECK_EQUAL( str_empty( char_s ), (char_s == 0 || char_s[0] == char()) ); BOOST_CHECK_EQUAL( sz, static_cast<diff_t>(std::char_traits<char>::length(char_s)) ); BOOST_CHECK_EQUAL( str_begin( my_string ), my_string ); range_iterator<char_array_t>::type str_end2 = str_begin( my_string ) + str_size(my_string); range_iterator<char_array_t>::type str_end3 = str_end(my_string); BOOST_CHECK_EQUAL( str_end3, str_end2 ); BOOST_CHECK_EQUAL( str_empty( my_string ), (my_string == 0 || my_string[0] == char()) ); BOOST_CHECK_EQUAL( str_size( my_string ), my_string_length ); BOOST_CHECK_EQUAL( str_size( my_string ), static_cast<diff_t>(std::char_traits<char>::length(my_string)) ); char to_search = 'n'; BOOST_CHECK( find_mutable( char_s, to_search ) != str_end( char_s ) ); BOOST_CHECK( find_const( char_s, to_search ) != str_end(char_s) ); BOOST_CHECK( find_mutable( my_string, to_search ) != str_end(my_string) ); BOOST_CHECK( find_const( my_string, to_search ) != str_end(my_string) ); BOOST_CHECK( find_mutable( char_s2, to_search ) != str_end(char_s) ); BOOST_CHECK( find_const( char_s2, to_search ) != str_end(char_s2) ); BOOST_CHECK( find_const( as_array( my_string ), to_search ) != str_end(my_string) ); BOOST_CHECK( find_const( as_array( my_const_string ), to_search ) != str_end(my_string) ); // // Test that as_literal() always scan for null terminator // char an_array[] = "foo\0bar"; BOOST_CHECK_EQUAL( str_begin( an_array ), an_array ); BOOST_CHECK_EQUAL( str_end( an_array ), an_array + 3 ); BOOST_CHECK_EQUAL( str_size( an_array ), 3 ); const char a_const_array[] = "foobar\0doh"; BOOST_CHECK_EQUAL( str_begin( a_const_array ), a_const_array ); BOOST_CHECK_EQUAL( str_end( a_const_array ), a_const_array + 6 ); BOOST_CHECK_EQUAL( str_size( a_const_array ), 6 ); } void check_string() { check_char(); #ifndef BOOST_NO_STD_WSTRING typedef wchar_t* wchar_iterator_t; test_string<wchar_t, 13> a_wide_string(L"a wide string"); test_string<wchar_t, 19> another_wide_string(L"another wide string"); const wchar_t* char_ws = a_wide_string.const_sz(); wchar_t my_wstring[] = L"another wide string"; wchar_t* char_ws2 = a_wide_string.mutable_sz(); BOOST_STATIC_ASSERT(( is_same< range_value<wchar_iterator_t>::type, detail::iterator_traits<wchar_iterator_t>::value_type>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<wchar_iterator_t>::type, wchar_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const wchar_t*>::type, const wchar_t* >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<wchar_iterator_t>::type, detail::iterator_traits<wchar_iterator_t>::difference_type >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<wchar_iterator_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<wchar_iterator_t>::type, wchar_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const wchar_t*>::type, const wchar_t* >::value )); typedef boost::range_difference<std::wstring>::type diff_t; const diff_t sz = str_size( char_ws ); BOOST_CHECK_EQUAL( str_begin( char_ws ), char_ws ); BOOST_CHECK_EQUAL( str_end(char_ws), (str_begin( char_ws ) + sz) ); BOOST_CHECK_EQUAL( str_empty( char_ws ), (char_ws == 0 || char_ws[0] == wchar_t()) ); BOOST_CHECK_EQUAL( sz, static_cast<diff_t>(std::char_traits<wchar_t>::length(char_ws)) ); wchar_t to_search = L'n'; BOOST_CHECK( find( char_ws, to_search ) != str_end(char_ws) ); BOOST_CHECK( find( char_ws2, to_search ) != str_end(char_ws2) ); #if BOOST_WORKAROUND(_MSC_VER, BOOST_TESTED_AT(1300)) BOOST_CHECK( find( my_wstring, to_search ) != str_end(my_wstring) ); #else boost::ignore_unused_variable_warning( my_wstring ); #endif #endif find( check_rvalue_return(), 'n' ); } #include <boost/test/unit_test.hpp <http://www.boost.org/doc/libs/1_64_0/boost/test/unit_test.hpp>> using boost::unit_test::test_suite; test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test = BOOST_TEST_SUITE( "Range Test Suite" ); test->add( BOOST_TEST_CASE( &check_string ) ); return test; } Well, that obviously got me up and running, thanks. Is there any other documentation/examples to have a look at? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 1

[thread] Trying to cross build 1.64.0 boost.thread with mingw posix threads
by Frédéric Bron 12 Jul '17

12 Jul '17

Hi, I built a w64 cross-compiler to make windows binaries on linux. The cross-compiler has Posix threads, not win32 threads. I would like to build boost.thread with it but I have some difficulties: 1. I do not need to link with any library to build applications with C++11 threads but boost build asks for PTW32_INCLUDE and PTW32_LIB otherwise it sets <build>no so that the library is not built. This is easily changed with the following patch: diff -r -u boost_1_64_0-0/libs/thread/build/Jamfile.v2 boost_1_64_0-1/libs/thread/build/Jamfile.v2 --- boost_1_64_0-0/libs/thread/build/Jamfile.v2 2017-04-17 04:22:25.000000000 +0200 +++ boost_1_64_0-1/libs/thread/build/Jamfile.v2 2017-07-12 14:24:03.960979687 +0200 @@ -271,10 +271,6 @@ { result += $(paths) ; } - else - { - result = <build>no ; - } } result += <define>BOOST_THREAD_DONT_USE_CHRONO ; if ! [ configure.builds has_atomic_flag_lockfree 2. Once this patch is applied, the library is built but there are errors when compiling libs/thread/src/pthread/thread.cpp. The command that is run by b2 is given below. Here are the errors: libs/thread/src/pthread/thread.cpp:541:2: error: #error #error ^~~~~ In file included from ./boost/thread/thread_only.hpp:17:0, from libs/thread/src/pthread/thread.cpp:11: ./boost/thread/pthread/thread_data.hpp: In member function ‘void boost::thread_attributes::set_stack_size(std::size_t)’: ./boost/thread/pthread/thread_data.hpp:53:35: error: ‘getpagesize’ was not declared in this scope std::size_t page_size = getpagesize(); The first error is because apparently neither BOOST_HAS_SCHED_YIELD nor BOOST_HAS_PTHREAD_YIELD is defined. I understand that the 2nd error comes from the fact that getpagesize() is not in unistd.h provided by mingw-w64. There is a strange thing about the command line: it contains -mthreads although I never provided it. I tried to remove it or replace it with -pthread or -lptread but I still get the same error message. "i686-w64-mingw32-g++-7.1.0" -ftemplate-depth-128 -std=c++14 -O2 -DNDEBUG -O3 -finline-functions -Wno-inline -Wall -pedantic -march=i686 -mthreads -m32 -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_LOG_WITHOUT_EVENT_LOG -DB OOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DBOOST_USE_WINDOWS_H -DNDEBUG -DWIN32_LEAN_AND_MEAN -I"." -c -o "bin.v2/libs/thread/build/gcc-mingw-7.1.0/release/boost.locale.iconv-on/boost.locale.icu-off/boost.locale.std-o ff/link-static/target-os-windows/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp"

1 0

[root_ptr] Deterministic Javascript-like memory manager
by Phil Bouchard 12 Jul '17

12 Jul '17

Hello Boost / Qt, After some experience I have gained in Javascript over the last year, I decided to integrate root_ptr in a quest to replace their garbage collector. So I did and I already have an example. If we mimic the Javascript function scope in C++ then we'll have the following: https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_exam… The application was compiled with: g++ -fpermissive -DBOOST_DISABLE_THREADS -std=c++11 -I../include -I/usr/local/include -L/usr/local/lib -lboost_thread -lboost_system javascript_example1.cpp And it outputs: Scope 0: BEGIN Scope 1: BEGIN A::A(const boost::node_proxy&) A::A(const boost::node_proxy&) A::~A() Scope 1: END A::~A() Scope 0: END Which is exactly what we want. Note that I didn't stress tested it yet and in Brave New World we would be able to integrate it to other languages relatively easily given Javascript is a worse-case scenario. What do you think? Regards, -Phil http://www.fornux.com http://www.finitetheory.com https://www.actatabula.com https://github.com/philippeb8/root_ptr/

3 10

[beast] Chunked Serialization, feedback requested! (Or: Bjorn, will you come out to play?)
by Vinnie Falco 12 Jul '17

12 Jul '17

During the review it was brought up that Beast could do a better job giving users control over the serialization and parsing of message payloads that have the chunked transfer coding applied. I collaborated with some helpful folks on the #boost slack channel and I have put together something solid for serializing chunks. I'm looking for feedback from anyone (especially Bjorn) before I merge this. The documentation is quite extensive and explains step by step how to achieve all of the goals stated in the review related to serialization of chunk encoded message payloads: <http://vinniefalco.github.io/stage/beast/bjorn/beast/using_http/chunked_enc…> I'm interested in hearing from anyone who cares to weigh in. Is the documentation sufficient? Are there any obvious defects? Do the interfaces meet the requirements for obtaining full control over the emitted chunked message payload? If anyone wants to play with or inspect the code, it is in the "bjorn" branch: <https://github.com/vinniefalco/Beast/commits/bjorn> In the meanwhile, I will start putting something together to provide better control during parsing of chunks. Thanks!

1 0

My Beast Review
by Phil Endecott 12 Jul '17

12 Jul '17

Dear All, This review is not very thorough - I've only looked at the docs and some small parts of the code, and read the discussion on the list. I've not tried to use the library. But I think I've seen enough to express an opinion. I've never used ASIO. I've studied it in the past, and concluded that it offers portability to platforms that I don't use but doesn't work well with other platforms that I do use. It also seems more complicated than I would have liked, perhaps in order to achieve some optimised level of performance that I don't need (or perhaps for no good reason). I have however quite often used HTTP (hasn't everyone?) and I think it's an embarrassment that std::c++ can't download something from the 'net with one or two lines of code in the way that almost every other language can. So, my first reaction is that it's a disappointment to see that a proposed HTTP library is tied to ASIO. On further investigation, however, I think this is no great loss to me as the functionality that this library provides is so limited in scope. Parsing HTTP headers, for example, is not much work. Even my own hacked-together-in-an-afternoon HTTP classes do more than this - to mention just one thing, parsing and formatting of dates in the correct format. Everyone who uses this library will have to implement this sort of thing themselves on top of it. (And many of them will implement it wrongly.) Vinnie says that he hopes that more functionality will be layered on top of this work. The danger is that the person who comes along wanting to implement the other 75% will not like Vinnie's starting point, and re-implement it all in their own style. (I know I would.) Unless, of course, Vinnie is going to offer this "other 75%" himself eventually. *That would be great*. If that is the plan, my review is "this is a fine start but please remove the ASIO dependency and come back when it's finished". But I think Vinnie has said that the library is to be reviewed "as is". In that case, my review is "just add this to ASIO and call it boost.asio.http and boost.asio.websocket, no need for a review" (assuming that the ASIO developer is happy with that). Regarding what I have seen of the implementation: - Security must be one of the most important properties of an HTTP library, and I'd really hope to find that such a library had been implemented by someone with significant experience in this area. I never cease to be amazed by the ingenuity of attackers. - I fear that there may be much premature optimisation in the parser code that I've looked at. For example: static bool is_digit(char c) { return static_cast<unsigned char>(c-'0') < 10; } Is that right? Say c='!' (ASCII 33). '0' is ASCII 48. So c-'0' is -15. But you cast that to an unsigned char, so -15 = 241, and 241 > 10, so the function returns false. So it is correct - but (1) it needs a comment to explain it, (2) it's the sort of thing that makes me worry from a security viewpoint, and (3) is it actually an improvement on the more obvious c >= '0' && c <= '9'? Well I've done a quick test and I get the same assembler for both - so why bother? (Except on close inspection actually I don't get exactly the same assembler. To get the same assembler I have to replace the constant 10 in your code with 10U, which changes the final comparison from signed to unsigned. I don't think that matters, but it again makes me wonder whether this security-critical code is ideal.) But hey, why even do c >= '0' && c <= '9' when we have std::isdigit()? But it would be much slower, right? Wrong, it's actually one instruction shorter; somehow it manages to avoid one of the zero-extension instructions. So this is not a premature optimisation, it's a premature pesimisation. (My test code is at the end of this message.) Now, is_digit is just about the simplest thing in the parser; Vinnie has also implemented his own code for parsing numbers, and then we come to parse_field. Please have a look at this (around line 666 of basic_parser.hpp). Note that it calls find_fast() near the top of that file, which uses some Intel SIMD instruction to, I think, skip forward over the header field name, and then over the field value to the CRLF. Not that there are any comments in find_fast to explain what it does, for those of us who don't know what _mm_loadu_si128 and _mm_cmpestri do. Has this code actually been benchmarked against a much simpler and more obviously-correct version, and found to have a worthwhile performance benefit? (I believe that some of the discussion has used this "optimised parser" as a justification for not making the code more generic, i.e. to work with any iterator pairs. I believe that to be flawed, since (a) I don't think this optimisation is useful, and (b) even if it were, the code could use it for any contiguous iterators, and fall back to "unoptimised" code in other cases. I think that having the "unoptimised" code present would be useful for documenting what the parser is trying to do, in any case.) Could it be that the reason why the scope of the library seems so limited is that Vinnie has spent his time fiddling with this optimisation, rather than adding useful features? My opinion: having looked at the implementation, reject. Test for is_digit: #include <cctype> bool is_digit_1(char c) { return static_cast<unsigned char>(c-'0') < 10U; } bool is_digit_2(char c) { return c >= '0' && c <= '9'; } bool is_digit_3(char c) { return std::isdigit(c); } Aarch64 assembler output from g++ 6.3.0 -O3, with the uninteresting bits removed: _Z10is_digit_1c: uxtb w0, w0 sub w0, w0, #48 uxtb w0, w0 cmp w0, 9 cset w0, ls ret _Z10is_digit_2c: uxtb w0, w0 sub w0, w0, #48 uxtb w0, w0 cmp w0, 9 cset w0, ls ret _Z10is_digit_3c: uxtb w0, w0 sub w0, w0, #48 cmp w0, 9 cset w0, ls ret Regards, Phil.

6 7

Outcome v2 is feature complete
by Niall Douglas 11 Jul '17

11 Jul '17

I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from two months ago, has reached feature completeness. Outcome provides a STL-quality `result<T, EC>` and an `outcome<T, EC, E>` implementation of success|failure value transports, and is expected to pass a second Boost peer review and be submitted for C++ standardisation as the lowest level of an overall framework as proposed by: * http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf C++ Monadic interface * http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A proposal to add a utility class to represent expected object (Revision 4) The idea is that result/outcome are the extremely lightweight struct-like success|failure value transports suitable for usage in public APIs, whereas expected is the much richer variant-like monadic success|failure value transports, and everything participates together under P0650R0. A detailed changelog over v1 can be found at https://github.com/ned14/outcome/blob/master/Readme.md. The main changes are the removal of lots of stuff which was in v1, and we now replicate `std::variant<...>` constructor API. v2 is an “absolute bare minimum” implementation with no frills. Outcome v2 is passing the modified v1 test suite handily, and v1 code should port to v2 easily enough. But as an all-new codebase it lacks: * Maturity * Polish * Use experience * Documentation (a class synopsis can be found at https://ned14.github.io/outcome/synopsis/) My hope is to return Outcome v2 for Boost peer review by October. If you are using an internal Expected-like object, or Outcome v1, I’d hugely appreciate it if you tried porting your code to using v2 and giving me feedback on how it went for you. Minimum compilers needed are GCC 6 or clang 4. Help with documentation and testing is also hugely appreciated. My thanks in advance! Github: https://github.com/ned14/outcome Docs (highly incomplete): https://ned14.github.io/outcome/ Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 19

icl and C++17
by Duarte Nunes 11 Jul '17

11 Jul '17

Hi, Boost icl doesn't compile using GCC 7.1 with -std=gnu++17. There's a pull request solving the issue[1], but icl seems non-maintained. It would be great if someone could upstream that change so that projects depending on icl can get upgraded to C++17. Thanks, Duarte [1] https://github.com/boostorg/icl/pull/9

1 0

Re: [boost] [Boost-users] Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 11 Jul '17

11 Jul '17

On Tue, Jul 11, 2017 at 4:06 AM, Raffi Enficiaud via Boost-users < boost-users(a)lists.boost.org> wrote: > Le 11.07.17 à 02:14, Marshall Clow via Boost-users a écrit : > > The second release candidates for the 1.65.0 beta release are now >> available at: >> >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.7z >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.tar.bz2 >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.tar.gz >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.zip >> >> The SHA256 checksums are as follows: >> >> d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 >> boost_1_65_0_beta1_rc2.7z >> 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b >> boost_1_65_0_beta1_rc2.tar.bz2 >> 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 >> boost_1_65_0_beta1_rc2.tar.gz >> 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 >> boost_1_65_0_beta1_rc2.zip >> >> >> This RC contains a single fix to the stacktrace library. >> >> As always, the release managers would appreciate it if you download >> the candidate of your choice and give building it a try. Please report >> both success and failure, and anything else that is noteworthy. >> >> Thanks! >> >> -- The release managers >> > > Hi, > > I have this error during the build on OSX. Built with: > ./b2 cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" > --without-log --layout=versioned install > > > ...on 14200th target... > common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi > common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa > darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa/pin_thread.o > libs/fiber/src/numa/pin_thread.cpp:23:10: warning: pin_thread() not > supported [-W#pragma-messages] > # pragma message "pin_thread() not supported" > ^ > 1 warning generated. > darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa/topology.o > libs/fiber/src/numa/topology.cpp:23:10: warning: topology() not supported > [-W#pragma-messages] > # pragma message "topology() not supported" > Given these two messages, I suspect that is deliberate. I see that too in my tests. -- Marshall

1 0

Fwd: [beast] (In)formal review
by Michael Caisse 11 Jul '17

11 Jul '17

Forwarding to the list: Received 1:19 AM my time... still July 10th in Hawaii ... and I'm still up reading Beast reviews so it seems good enough for me. Thanks for the review! -------- Forwarded Message -------- Subject: [boost][beast] (In)formal review From: Rüdiger Berlich ------------------------------------------- Dear Michael, dear Vinnie, having read the very lively discussion during the review, I am not sure I can add much to the technical side. Please feel free to either count this voice or leave it out, as you see fit, particularly as this mail didn’t come in time for the formal review. Hence I am sending this as PM. In my own applications, I limit myself to Boost as an external dependency. Having Websocket-functionality as part of Boost (the „pure“ HTML-side is of less significance to me) would be a god-send and would save me countless hours, allowing me to focus more on what I’m good at. Currently I just build directly on ASIO. I feel that Beast fills a very big niche and, having followed the development of the library for a while now, I am also confident that it is sufficiently advanced to be included into Boost. Thus, from a mere user’s perspective, I’d like to strongly vote in favor of ACCEPT. ============== - What is your evaluation of the design? I have worked with ASIO for a while and appreciate that Beast follows the same principles. - What is your evaluation of the implementation? I have browsed though some of the code and feel that it is well structured and certainly easier to read than some of the other Boost-code I have come across - What is your evaluation of the documentation? Beast does not intend to be a high-level library, and for the intended audience, the documentation is well-designed and complete. I would hope that, if and when Beast becomes part of Boost, there’ll be more tutorial-like information similar to what Boris Schaeling does in his books (e.g. here: https://theboostcpplibraries.com — could well become part of that). - What is your evaluation of the potential usefulness of the library? Immense. C++ is lacking a LOT of functionality on the library side, and this is one of the essential building blocks needed by people intending to create the higher-level libraries. I believe that we will see many new library proposals on top of Beast. - Did you try to use the library? With which compiler(s)? Did you have any problems? I have followed the development of Beast for a number of months and have „played“ with it in different contexts. I am in the process of integrating it into my own (client-server type application). In comparison to other libraries, it seems to be much more vivid and fast-paced. I have used it on MacOS and Linux (—> clang and g++). - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? No in-depth study, but in summary there is certainly more than a day of involvement. - Are you knowledgeable about the problem domain? Having done quite a bit of „do it yourself“ on top of ASIO for my own application, I appreciate what Beast can do for me (on the Websocket side) and am in dire need of this functionality. As a library-USER, I actually do not intend to be an expert for the implementation side and would be very thankful if it became available as part of Boost. I’d like to thank Vinnie for the huge amount of work that went into Beast and the Boost-community for the superb collection of libraries that have kept C++ alive. Kind Regards, Beet P.S.: I do not like the name „Beast“, but do not think it is important. Certainly this is up to the author to decide :-)

1 0

Encoding address-model in library names
by Peter Dimov 11 Jul '17

11 Jul '17

I have prepared the pull requests necessary to encode the address-model (32 or 64) in the library names, which allows placing the 32/64 libraries into the same stage/install directory, and building with address-model=32,64 in one go. These are https://github.com/boostorg/boost/pull/147 and https://github.com/boostorg/config/pull/159 This being a Serious Change, the prudent thing to do is to wait out 1.65, then proceed. On the other hand, experience shows that this kind of change is only tested when a release goes out anyway; delaying it for four more months would not help much. Therefore, I'm calling for opinions; would people want this to go into 1.65? Into 1.66? Not at all?

16 50

Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 11 Jul '17

11 Jul '17

The second release candidates for the 1.65.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1_rc2.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1_rc2.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1_rc2.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1_rc2.zip This RC contains a single fix to the stacktrace library. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

1 0

[mpl] [bug] Bug on python script
by Alessandro Marzialetti 10 Jul '17

10 Jul '17

Hello, I cannot open a ticket on the website due to an error OperationalError: could not extend file "base/19263/19289": No space left on device HINT: Check free disk space. Anyway, I found a bug in the library. The file is mpl/preprocessed/boost_mpl_preprocess.py a script that creates the headers required to have more than 50 types on a template. Basically the problem is on the string substitutions, with some values the output is wrong. I made a pull request that fixes the problem making a temporary substitution of the values https://github.com/boostorg/mpl/pull/29

2 1

[review][beast] Five-days Remaining
by Michael Caisse 10 Jul '17

10 Jul '17

Hi all - We are half-way through the review and have some great involvement and exchanges and a few reviews already. I hope if you haven't written a review yet that you still will. Please provide whatever effort you can afford toward the review process. Boost depends on community involvement. You might have noticed that I have solicited input from you regardless of your experience with the domain. I personally think it is a mistake to have input only from domain experts. True innovation often comes from "outsiders". If you have no experience with Asio or with HTTP, how approachable is this library? Were you able to understand the documents? Could you use the examples? Were you able to build something of your own? Domain experts -- you know the dark corners of the domain. The hard parts that have caused you hours of lost sleep and the need to hack around an existing library or to write your own. How does Beast address your concerns and the problems you have experienced in the past? Is it flexible enough to be put into your tool chest? So far we have reviews from: * Marcel Ebmer * Peter Dimov * Artyom Beilis * Zach Lain * Nik Bougalis * Klemens Morgenstern * Glen Fernandes If I missed a review from you, please let me know! Happy Coding! michael -- Michael Caisse Ciere Consulting ciere.com

6 13

[beast] Review
by Jens Weller 09 Jul '17

09 Jul '17

This is my review of the beast libary. First, I find the name quite fitting, but also we clearly need a "cage" library to make the internals of beast more useful for the endusers. I spend a few days on and off reviewing examples, and documentation. I used the library as an example for a fuzzing experiment on the weekend. What is your evaluation of the design? The design is very boost like, the library fits well into boost. One thing the library shares with asio is the buffer concept, which I never really liked. Buffer feels to me to abstract, to far away from the usual type vocabulary one is used to from standard C++. But once you're used to the concept, its ok. So no big deal. The dependence on Asio was already mentioned during the review and I am not sure about this. Surely a nice goal to have, but also not an easy one. But replacing asio with an abstraction that allows for pluggin in other socket implementations would be very powerful. Its nice that the library is header only, but over asio you get the dependency to boost::system for error_code. I'd love to be able to exchange boost::error_code dependency to the std::error_code one. As the beauty of header only really shines when you don't need to link to other non header only libraries... What is your evaluation of the implementation? Fuzzing. I spend this weekend some time to fuzz beast with libFuzzer. The basic_parser and the websocket::stream were fuzzed. A bug (buffer overflow) in basic_parser was found, and is already fixed. What is your evaluation of the documentation? Boost typical. Its good, helps with getting the library to know. What is your evaluation of the potential usefulness of the library? This library could be the foundation of many things to come. The internet is the basic building block for so much today, that beast is a nice improvement upon asio in providing the vocabulary to use boost in the internet age. As I already mentioned, I think that other libraries are needed in order to make this library really useful for most end users. But the scope the author aims at, beast fits very well. Did you try to use the library? With what compiler? Did you have any problems? Fuzzing was based on clang 5.0, but I also used the library with GCC 5.4 to generate example data for the fuzzing. I plan to use the library to write a small http server and clients for my own usage. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? My time for this review is limited, but as the author mentioned on this list, that the library hasn't been fuzzed, I aimed for doing this instead of implementing an http client/server. I still had to write code in order to reach the parts in beast to be fuzzed, this gave a more detailed tour of beast, then one would need for simple example exploring. Are you knowledgeable about the problem domain? A little, I am mostly a high level user of various HTTP libraries, but not at the low level beast covers. I found it interesting to get a glance at the details. And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I think that this library should be ACCEPTED into boost. It is an important improvement on asio, in order to offer a more detailed networking stack in boost. The library has the exact right scope to do this, widening the scope into providing client/server implementations would not be good. I see this in another library. thanks, Jens Weller

3 4

Boost 1.65.0 Beta 1 Release Candidate 1
by Marshall Clow 09 Jul '17

09 Jul '17

The release candidates for the 1.61.0 release are now available at: https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.7z https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.bz2 https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.gz https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.zip The SHA256 checksums are as follows: cd7429340bb4aae38e0ad2e9f59c39e66335302c41577956123e55fc1e2a28ee boost_1_65_0_beta1_rc1.7z fda076f7b3c994524d9cd41926c72f4a9b7c017bef310a055956fdd0bed7c358 boost_1_65_0_beta1_rc1.tar.bz2 0d1473041f7a9fa9ce1e256c870cc52af6f98abf723cf4f1ac61c2b45f45d38a boost_1_65_0_beta1_rc1.tar.gz f45bbb75b84cdc0c66f8a571d77c518cfbac076d7a6fc7937c4812f0f242a792 boost_1_65_0_beta1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

4 5

[Safe Numerics] Review
by John Maddock 09 Jul '17

09 Jul '17

OK, here's my review of Robert's library. By way of something different, I've tried to not read the docs (though I ended up scanning them in the end) and just tried to use the library. Here's what I've found: 1) Using: safe<int>(-1) & 1 I get a hard assert failure at safe_base_operations.hpp:1373. I'm assuming that this is a mistake, and the usual error handlers should be called? Bitwise or has the same issue. More tests required ;) 2) I'm not sure if this is an msvc issue but in: constexpr safe_base operator~() The static assert is triggered for *unsigned types* and not for signed. Even if this is a compiler issue, it indicates a missing test case or two. 3) If I assign a float to an integer, then I get the error: "conversion of integer to float loses precision" which isn't quite what you meant to say. More particularly, for float conversions I would expect: * Conversion from a float holding an integer value that's within the range of the target type to always succeed. * Conversion from a float holding a non-integral value to conditionally succeed (with trunction) depending on the policy in effect. * Conversion *to* a float may also fail if the integer is outside the range of the float (no checking may be required if the number of bits in the integer is less than the number of bits in the float). 4) Is constexpr arithmetic supposed to be supported? I tried: constexpr boost::numeric::safe<int> j = 0; constexpr boost::numeric::safe<int> k = 3; constexpr boost::numeric::safe<int> l = j + k; Which generates an internal compiler error for msvc, and for gcc-5.3 I get: ../../../include/safe_base_operations.hpp:332:35: error: call to non-constexpr function ‘void boost::numeric::dispatch(const boost::numeric::checked_result<R>&) [with EP = boost::numeric::throw_exception; R = int]’ dispatch<exception_policy>(r); Similarly if I try to add a literal to a safe<int>. Again as the tests all pass, so I'm assuming they're missing constexpr tests? 5) What is the purpose of class safe_literal? constepxr initialization seems to work just fine without it? 6) In the docs, the example of using error handler dispatch is nonesense (top of page 41)? 7) Related to the above, I see the need to be able to define your own primitives which behave just like yours. The example I have is for bit-scan-left/right which has as precondition that the argument is non-zero, but there are other bit-fiddling operations (bit count etc) which some folks may require. A "cookbook" example would be good. 8) In the tests, you have an undocumented function "log" in the library. Not sure if this is intended to be part of the API or not, but IMO it's misnamed. ilog2 seems to a semi-standard name for this. 9) By way of testing the libraries performance I hooked it into the Millar-Rabin primality test in the multiprecision lib (test attached, it counts how many probable primes there are below 30000000), here are the times for msvc: Testing type unsigned: time = 17.6503 seconds count = 1857858 Testing type safe<unsigned>: time = 83.5055 seconds count = 1857858 Testing type 32-bit cpp_int: time = 36.9026 seconds count = 1857858 and for GCC-MINGW-5.3.0: Testing type unsigned: time = 17.1037 seconds count = 1857858 Testing type unsigned: time = 18.4377 seconds count = 1857858 Testing type unsigned: time = 21.0592 seconds count = 1857858 I'm surprised by the difference in times between msvc and gcc, also deeply impressed that there is effectively no performance penalty with GCC (I was expecting there should be some!) 10) I don't find the scope of the library over-broad, in fact I probably find it about right wrt the policies etc. 11) There were a few traits and such that it would be nice to have, the problem as ever, is what to call them and where to put them: * A trait for extracting the underlying type of a safe<> - use case for example where you enable_if a function on is_safe so don't have the template argument list to safe<>. * Do we need a function for extracting the underlying type of a safe<>? Or is casting to the underlying type optimal? Actually, maybe having a function would negate the need for the above trait, as we could just write 'auto x = mysafe.value();' ? * Do we need traits equivalent to is_signed/is_unsigned/make_signed/make_unsigned? My gut feeling is yes we do, the issue is what to call them, and where to put them - we're not allowed to specialize the type_traits versions (either boost or std), but we would need a central "one true trait" version that can be specialized by other libraries as well (Multiprecision for example). We've backed ourselves into a corner over this I fear! 12) When calling boost::integer::gcd/lcm the sub-optimal(?) non-binary versions are called for safe<> - you might want to look into seeing what traits need to be defined to ensure that the same version as the underlying type is called. Those are all the issues I can see for now... in conclusion, as for whether the library should be accepted, yes I believe it should be, modulo the issues above. Regards, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 14

Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
by Vinnie Falco 09 Jul '17

09 Jul '17

On Mon, Jul 3, 2017 at 9:54 AM, Emil Dotchevski via Boost <boost(a)lists.boost.org> wrote: > ... > The question is must Beast be coupled to Asio, not can it be used without > something like Asio. And I don't mean just in the case of someone using > serializer/basic_parser and nothing else. > > In my opinion, arguing that coupling is necessary should begin with > defining an interface which Beast can use, which can be trivially > implemented in terms of Asio. In designing this interface the only concern > should be avoiding the coupling; specifically, performance considerations > should be completely ignored. Only then we can have a reasonable discussion > is it worth it. Regardless, in my experience this kind of exercise always > improves the design of a library. The question is, can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams, instead of being tied to Boost.Asio? First lets imagine what such generic concepts might look like, independent of Beast. We will start with the synchronous case which is the easiest. In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code The following synchronous stream operations are defined: /** Read data from a stream synchronously `stream` The stream to read from `buffers` The buffers to read into `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size read( Stream& stream, Buffers const& buffers, Error& error); /** Write data to a stream synchronously `stream The stream to write to `buffers The buffers to write from `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size_t write( Stream& stream, Buffers const& buffers, Error& error); This looks pretty generic and at this point users familiar with Boost.Asio might raise their hands to tell me that the interfaces look identical. This is just a coincidence because, lets face it - synchronous interfaces don't come in that many varieties. I don't think synchronous interfaces are particularly interesting and Beast could certainly be made to use something like this but even with simple interfaces some issues come up: 1. What is the concrete type of Error? Or is Error a template parameter that meets certain requirements? 2. HTTP stream read algorithms need to know when the stream, is closed, what error code represents End-of-File? 3. What are the requirements of Buffers? Beast could be written against generic concepts, but in order to do so the questions above need to be answered (points 1 through 3). Otherwise there is no specification and thus, no way to write an algorithm. We will come back to these questions, but now on to the next topic. We want Beast to also provide HTTP operations on asynchronous streams, so we need to have a generic concept against which to work. There are many models of asynchronous computation. For example there are futures, coroutines, callbacks, and queues (I can't really think of any others at the moment). Lets imagine what callback-based generic asynchronous stream read and write operations might look like: In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code * `Callback` is a type which is Callable with the signature `void(Error, std::size_t)` The following asynchronous stream operations are defined: /** Begin an operation to read data from a stream asynchronously `stream` The stream to read from `buffers` The buffers to read into `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_read( Stream& stream, Buffers const& buffers, Callback const& callback); /** Begin an operation to write data to a stream synchronously `stream` The stream to write to `buffers` The buffers to write from `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_write( Stream& stream, Buffers const& buffers, Callback const& callback); Now anyone who knows Asio is going to stop me and say, hey! This looks a lot like Asio! But that's a side issue because this generic interface I have provided has some defects. Or rather, you can say that it is under-specified. We have the same questions about the requirements for the types Error and Buffers, and the value representing End-of-File. But now there are even bigger questions with significant ramifications: 1. Upon which thread is the callback invoked? 2. Who invokes the callback and how is it invoked? 3. How is access to the `stream` synchronized? 4. What about futures and coroutines? The simple generic free function signatures alone which I provided above are not sufficient to describe a complete model for asynchronous operations on streams. We also need provisions to answer the questions above. Does the implementation provide the threads, or are they provided by the user? Does synchronization use mutexes? Lock-free programming? Queues? Back to this in a moment... Some folks who either dislike callbacks or just happen to love futures may raise an objection that the callback-based generic model I have described does not capture their use case. Actually, Christopher Kohlhoff (author of Boost.Asio) demonstrates how the callback-based model is a proper superset of all other asynchronous computation models. And he shows that callback-based models provide the greatest opportunity for performance and efficiency by doing away with unnecessary synchronization points. This is explained in his paper N3896 "Library Foundations for Asynchronous Operations" and shows how initiating functions like `async_read` and `async_write` above may be trivially modified to support not just callbacks but also futures, coroutines, and user-defined types. Beast fully supports this system and even comes with tutorials and helper classes which let you implement the model yourself in your own initiating functions. "Library Foundations for Asynchronous Operations" (N3896) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3896.pdf> "Writing Composed Operations" (Beast) <http://vinniefalco.github.io/stage/beast/review/beast/using_networking/writ…> Thankfully this solves one piece of our puzzle. N3896 allows us to say with certainty that our hypothetical generic network model should use callbacks as the foundational notification mechanism for the completion of asynchronous operations. Perhaps we can look towards the author of N3896 for more solutions? Drumroll... Working Draft, C++ extensions for Networking (N4588) a.k.a. "Networking-TS" <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4588.pdf> What is this you ask? Well... this is a working draft which describes a proposed set of C++ extensions for Networking. It has TCP/IP sockets and UDP streams, serial ports I think (?) but lets not worry about that. Most importantly, the Networking-TS defines a generic model for synchronous and asynchronous stream-oriented I/O operations! This means that: Synchronous and asynchronous algorithms written against Networking-TS concepts will work with any stream types that meet the requirements ** Yes, Networking-TS comes with generic stream concepts. Lets restate the original question: "Can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams?" The answer is: Yes. Beast is already written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams. These are provided by Boost.Asio. Specifically, these concepts: SyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> SyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> AsyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.read> AsyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.write> Its not the responsibility or goal of Beast to invent a new generic model of synchronous or asynchronous networking. That's already been taken care of. Beast follows it. It is the job of authors to make sure their network implementations meet the requirements of the various Networking-TS stream concepts. Once they do that, then any algorithms written against the concepts can now work with these implementations. Again folks might raise their hand and say "but Beast depends on Boost.Asio!" and they would be right. The reality is that Networking-TS has not entered the standard and is not uniformly available across compiler vendors. Boost.Asio is the closest thing to the standardized version of Networking-TS, so Beast is written against that. Its not perfect, but it is the best we can do and the runner-up is not even in the race (are there any other generic stream designs?). I believe that the burden of proof rests with those who claim that Beast should be written against a different generic stream design. Please show me one such design that is mature, well-specified, and in-use, other than Boost.Asio. tl;dr; Boost.Asio's models of synchronous and asynchronous buffer-oriented streams are already generic, and Beast is written against Boost.Asio. Thanks

2 1

Re: [boost] Boost 1.65.0 Beta 1 Release Candidate 1
by berne＠notadragon.com 09 Jul '17

09 Jul '17

Hi, I've been playing aournd with boost coroutines2 and maybe I'm just confused about where this project is, but with 1.65 coroutines2 doesn't seem to be buildable out of the box any longer: I've tried looking through mailing list archives for anything about the status of coroutine2 to no avail, and coroutine still spits out warnings to use coroutine2 when used. I'm not sure where in the build system things hook in to fix this. Here's the output on my system: berne@Bugg:~/tmp$ tar xzf boost_1_65_0_beta1_rc1.tar.gz berne@Bugg:~/tmp$ cd boost_1_65_0/ berne@Bugg:~/tmp/boost_1_65_0$ ./bootstrap.sh --with-toolset=clang Building Boost.Build engine with toolset clang... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html berne@Bugg:~/tmp/boost_1_65_0$ ./b2 --with-coroutine2 error: wrong library name 'coroutine2' in the --with-<library> option. Thanks. - Josh

2 2

[beast] Review
by Gyorgy Szekely 09 Jul '17

09 Jul '17

Hi, Some background: this is my first Boost library review. I followed the discussion on Beast and I'm probably not as experienced as others on this topic. I started learning Beast along with Asio and it was a really good experience. After understanding ASIO concepts, I could get an async multi-threaded http server running in a few hours. I leave it up to the review manager whether to take this a formal review or just informal feedback (impressions of newbie :)) *** What is your evaluation of the design? The library in my opinion is very well designed. I doesn't try to offer too much. I understand the author's position: HTTP is vast and Beast is a low-level library. Still, while using it I felt with a few additional bits it would be more complete. What I was missing is parsers/serializers for uri and cookies. I think Beast should provide these (even in a separate namespace), as they are not higher level functionality than parsing/serializing http headers. (I implemented them in my application, and I'm sure my code is neither correct regarding corner cases, nor standards compliant. I'm also sure that I'm not alone with this, so there's a place for this in either Beast, or as the author suggests a higher level lib.) Though the library is heavily templated, as a user I'm not forced to write templated code, implementing the most common use-cases is simple and straightforward. That's a big plus. I really like the symmetric client/server design. My application is http/websocket server, being able to use the the same classes and functions in unit tests made reasoning about the code and tests much easier. Finally there's was a lot of debate whether being ASIO and stream concept based is a good idea or not. For me (as a newcomer) seamless integration with ASIO helped getting started really fast, though I didn't do awfully complex stuff. *** What is your evaluation of the implementation? I did not review all the implementation. While using the library, I looked into some of the files, and my impression was that the code is high quality. The test coverage is also high, and issue fixes are accompanied with rigorous tests. The library is mostly composed of templates, which makes a bit harder to understand its internals, but I didn't mind it at all given the benefits (composablity, customization points). *** What is your evaluation of the documentation? The documentation is well structured and plenty. Sections from the Intro up to the Reference are a good read by themselves. Design decisions and library scope are clearly stated. There're lots of examples in form of code snipets highlighting a particular use-case, as well as fully functional programs demonstrating these in action. I liked that the documentation is similar to ASIO's and I could use them together. *** What is your evaluation of the potential usefulness of the library? It's super useful. Even with its (current) dependency on ASIO and some other Boost libs Beast is small while providing both client and server side foundations for Websocket and HTTP. NodeJS and Java makes it so simple to create REST services, this should be hard in C++ either with standards based (NetTS) solutions. Beast is a step in the right direction. *** Did you try to use the library? With which compiler(s)? Did you have any problems? I'm actively using the library in the Http/Websocket <-> ZeroMQ gateway since Oct 2016 on Ubuntu 16.04 with GCC5, C++14. We've run extensive performance and stability tests on the HTTP interface and we're quite satisfied with the results. I migrated our codebase to newer Beast versions multiple times, and during this I reported a few minor issues or requested new features. The library author was really responsive and fixed/implemented them quickly. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours this time, but I've read the documentation and the public API reference multiple times in the last months. I didn't go through the implementation, but peeked into it here and there to understand some of the details. *** Are you knowledgeable about the problem domain? Not really. I've implemented some NodeJS and Java Spring REST services, but that's all. My conclusion: Beast should be ACCEPTED. Regards, Gyorgy Szekely

1 0

[sort] pdqsort mini-review
by Steven Ross 08 Jul '17

08 Jul '17

The (mini) review for pdqsort will start tomorrow 6/21, and run through 6/30. I will manage the review; Orson Peters is the author. The proposed boost source is here: https://gist.github.com/orlp/24f27aada1ed724d1809b372c33eb92e Documentation is here: https://github.com/orlp/pdqsort#pdqsort And a draft paper is here: https://drive.google.com/open?id=0B1-vl-dPgKm_T0Fxeno1a0lGT0E If you're interested, please answer these questions: 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort?

7 10

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

[beast] Missing documentation link
by Bjorn Reese 08 Jul '17

08 Jul '17

The link to example/common/file_body.hpp in the Examples section has gone missing. Please fix this ASAP. All links in the Examples section point the the master branch instead of the review branch.

2 2

[bootstrap] [b2] [install] Intel 17.0 & b2 cmd file for intel64 & vs2017
by Robert 07 Jul '17

07 Jul '17

Hello Everyone, I have had zero responses on the boost-build list since posting June 23, 2017. Hopefully there will be some here. This is most definitely not urgent. There is a chance that a solution in this thread may be important enough to add to a 1.65 jam file. There are many details in order to fully describe the situation. Executive Summary: In order to correctly build Boost 1.64 with the Intel 17.0, Update 4, C++ Windows compiler, in conjunction with Visual Studio (VS) 2017, Update 2, a symbolic link is necessary. The link shortens the VS installation root path for b2.exe to execute correctly. There is a question regarding the correct implementation to modify one or more jam files. The b2.exe automatic detection of the new and different Visual Studio 2017 paths is not working correctly. Details: I have succeeded constructing the b2 complete install for Intel 17.0, Update 4 on Windows 8.1 Pro, 64-bit, in conjunction with Visual Studio 2017, Update 2 (e.g. 15.2 (26430.12), in the About Microsoft Visual Studio dialog). The zlib source and Python 2.7 libraries are also incorporated into the x64 Boost by Intel build. In order to achieve a successful outcome, I create a symbolic link with the mklink command to considerably shorten the value for the VS2017INSTALLDIR environment variable. The value VS2017INSTALLDIR is first set to is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise The content above triggers two, "input is too long," messages when executing the .\b2 install --prefix=C:\Boost command. The execution never creates the respective b2 cmd file (file name listed below). The Intel supplied batch file is looking for the VS2017INSTALLDIR environment variable, when the vs2017 option is passed to compilervars.bat: compilervars intel64 vs2017 The location of the compilervars.bat is in something similar to: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.4.210\windows\bin Please review https://software.intel.com/en-us/articles/building-boost-with-intel-c-compi… for the recent details from Intel, to build Boost with the Intel compiler on a Windows operating system. The symbolic link is C:\v7 pointing to: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise When the VS2017INSTALLDIR environment variable is C:\v7, then the execution of b2 install at <boost root>\tools\build creates the 32-bit and 64-bit b2_intel-win_17.0_iclvars... command files in C:\Users\<username>\AppData\Local\Temp. I would like to understand whether the b2 constructed output for the file named: b2_intel-win_17.0_iclvars_intel64 vs2017.cmd should have its internal DevEnvDir variable value as this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ or this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ If the answer is the latter, then what is the correct modification(s) to the intel-win.jam, user-config.jam, and/or msvc.jam to enable the automatic detection to find the correct location for VS2017's devenv.exe? In order to use the 14.1 Visual Studio version string value, the 1.64 intel-win.jam file has been modified accordingly near the last line: .iclvars-17.0-supported-vcs = "14.1 14.0 12.0 11.0 10.0" ; .iclvars-version-alias-vc14.1 = vs2017 ; I have manually replaced the following strings of the b2_intel-win_17.0_iclvars_intel64 vs2017.cmd file to use the new Visual Studio 2017 paths. For example, the following older VS 2015 paths are equivalent to the following new VS 2017 paths (using the C:\v7 symbolic link above). Note that some paths are very long in VS2015. The VS2017 equivalent can be longer. The replacement string is preceded by the "==>" character combination. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VC\ ==> C:\v7\Common7\IDE\VC\ C:\Program Files (x86)\MSBuild\14.0\bin\amd64 ==> C:\v7\MSBuild\15.0\Bin\amd64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 ==> C:\v7\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages ==> C:\v7\Common7\IDE\VC\vcpackages C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE ==> C:\v7\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools ==> C:\v7\Common7\Tools C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64 ==> C:\v7\Team Tools\Performance Tools\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools ==> C:\v7\Team Tools\Performance Tools\ C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow ==> C:\v7\Common7\IDE\CommonExtensions\Microsoft\TestWindow C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ ==> C:\v7\Common7\IDE\PrivateAssemblies\ The affected cmd variables are: DevEnvDir INCLUDE LIB LIBPATH Path VCIDEInstallDir __VSCMD_PREINIT_INCLUDE __VSCMD_PREINIT_LIBPATH __VSCMD_PREINIT_PATH Thank you for your time and attention. It is greatly appreciated. Sincerely, Robert

1 0