- Boost - lists.preview.boost.org

Re: [boost] Outcome v2
by Groke, Paul 17 Jul '17

17 Jul '17

> From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 > To: boost(a)lists.boost.org > > Ah, now I get it, thanks for the explanation. There *might* even be a > way to get this to work even without memory allocation in the end > (without exception_ptr), but I think this is perhaps missing the point > of returning an error object, which is to be able to interact with it. > Also, reasonably if you could fit the things you need to create the > object into a "small object optimized" buffer, you can probably fit the > object itself into the same buffer. Noexcept already has that, it's the > result<T> object, however it might be too heavy to return up the call > chain one level at a time (it is instead designed for capturing the TLS- > stored object to postpone its handling, perhaps after moving it to > another thread). The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.

3 2

Boost libraries and Travis CI
by Edward Diener 16 Jul '17

16 Jul '17

Evidently to turn on Travis CI testing for a Boost library in Github you need to be the Administrator for that library, and not just a team member for that library. Is an Admin request the way to get Travis CI testing turned on for a library ? If not what is the proper way to turn on Travis CI testing for a Boost library once the .travis.yml file is added to the library ?

2 1

Regression tests on 'develop'
by Edward Diener 16 Jul '17

16 Jul '17

A number of regression tests on 'develop' have not been run for a long time. These includes Linux tests by 'Sandia' and 'teeks'. Does anyone know why these regression tests have not run for quite a while ?

1 0

Preprocessor directive for a sequence that differs only in datatype
by Rishabh Arora 16 Jul '17

16 Jul '17

Hello Everyone, I was trying to use the boost.preprocessor to write some code which otherwise needs to be written for all the cases. Here's the code: https://github.com/BoostGSoC17/dataframe/blob/master/include/df.cpp (line no. 430 and 431). But on compilation it gives the error: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given print_column <BOOST_PP_SEQ_ELEM(type, INNER_TYPE) >(i); I didn't understand the reason as when I wrote: print_column <BOOST_PP_SEQ_ELEM(any_numerical_value(0, 1, ...), INNER_TYPE) >(i); it works fine. Can anyone help me understand the error or provide an alternative way to do the same thing? Thanks in advance, Best Regards, Rishabh

3 6

[stacktrace][1.65 beta1] Problem with reference docs
by Joaquin M López Muñoz 16 Jul '17

16 Jul '17

The following http://www.boost.org/doc/libs/1_65_0_beta1/doc/html/reference.html displays BoostBook-related garbage rather than the real reference for the lib, unlike http://boostorg.github.io/stacktrace/reference.html Best, Joaquín M López Muñoz

4 5

[review][beast] Late review
by Christopher Kohlhoff 16 Jul '17

16 Jul '17

I realise this is quite late, but Vinnie asked for my opinion, so I asked for special dispensation from the review manager. Hopefully that is ok! In a nutshell, I think Beast should be accepted. Background: Although I may have some use for websockets in the future, my use case right now requires only HTTP (sorry Vinnie!). The use case involves incorporating HTTP protocol support into network applications whose primary purpose is something otherwise unrelated to HTTP. HTTP is used to support monitoring, configuration, and debugging facilities. Unlike typical HTTP use, the protocol is implemented not just over TCP sockets but also over local (UNIX domain) sockets. It is essential that the HTTP implementation minimises runtime overhead to avoid negatively impacting the quality of service for the other protocols. - What is your evaluation of the design? Overall the design is good. The library seems to be structured into several layers: 1. low level stateful parsers and serializers 2. operations to send/receive partial messages (*_some operations) 3. operations to send/receive header 4. operations to send/receive complete messages, using parser/serializer supplied by me 5. operations to send/receive complete messages This is a good thing, because it lets me select the appropriate layer for a particular use case. Whichever of layers 2 - 4 I choose, the best thing is that they all follow the same model for asynchronous operations as in Asio. All four of those layers work with arbitrary Asio streams, which was a requirement of my use case. This made using the library seamless, easily replacing my otherwise quick and dirty HTTP encoding and decoding approaches. The benefit of course is that someone else is taking care of ensuring the messages are well-formed, and doing a much better job of it. Layer 5 is good for simplicity and clarity. Based on my benchmarking, layer 4 seems to be the sweet spot for performance sensitive use cases, as it gives sufficient control of the placement of the "transient" objects used by the asynchronous operations. I use HTTP/1.0 almost exclusively, and one reason for this is that HTTP/1.0 allows the response to be sent without a Content-Length, with the end of content delimited by stream closure. One use for this is an infinite stream of data (e.g. monitoring output). Another use case is the ability to use the file descriptor as stdout for a child process. In both these cases, layer 3 fits the bill where I can send just the response header, and then take over the socket for my own needs. As for layer 2, the documentation for these functions still refers in places to a return value (or additional size_t argument to the completion handler), which is no longer in the code: synchronous read_some has a void return and async_read_some has a void(error_code) handler. Although this is probably vestigial documentation, actually I would prefer it if these lower level operations *did* return something, like the number of bytes transferred in the operation. This would assist in detecting badly behaved or pathological clients (like ones doing everything one byte at a time), and this is probably the main reason I would consider using the layer 2 operations. I haven't yet needed layer 1, but I can imagine how it might be used in transport agnostic code. I guess my main point is that by supplying all these layers, Beast is both powerful and flexible, and meets pretty much all of my likely needs. The body/reader/writer design feels a little awkward, and it seems like there is a more elegant design struggling to get out. However, my primary reason for looking at implementing a custom body was to support serving static files. As Vinnie now plans to include file support in the library itself, I have little reason to work directly with body/reader/writer directly any longer. Consequently, I am less concerned about the design here. However, I'd encourage Vinnie to keep exploring this. On a related note, once file body was added I was pleased to see how straightforward it was to incorporate platform-specific file transmission (TransmitFile, sendfile, etc) in a way that was transparent to the library user. There are some minor inconsistencies in template parameters, e.g.: parser has Allocator where serializer has Fields. I would have expected some symmetry here. The library includes reimplementations of a number of facilities from the networking TS. However, now the TS is done I plan to update Boost.Asio to match. If Beast is accepted then hopefully by the time it is incorporated, it will no longer need to include these at all. I'm not a huge fan of the library including typedefs for names from other boost libraries as part of the documented public interface, e.g. beast::error_code, beast::string_view. However, if it is to retain these, I'd at least like to see them given their own section in the documentation quick reference to make it clear that they are just aliases for external functionality. (Note: I'm just fine with the aliases themselves as a convenience for the library implementer.) - What is your evaluation of the implementation? The implementation is high quality. I do wonder about the implementation approach taken in the basic_fields storage. It uses a set, which is great asymptotically, but does mean allocation of a lot of small objects. In my experience (and in a totally unscientific survey of commonly used websites) the number of headers is usually small -- a dozen or two. In addition, when constructing or decoding a message, one would normally construct the set of fields in one go. Deletion of a field seems like it would be rare. Thus I wonder whether basic_fields could use a storage strategy geared towards the common case, e.g. a single storage blob for the fields themselves (vector<char>) plus an index (vector<size_t> of offsets to each field's beginning) for quick iteration. I don't think this would impact the API, so it's not essential. - What is your evaluation of the documentation? The documentation appears to be comprehensive. As mentioned above I did spot a few stray things that seemed to be left over from previous design iterations. There's also the occasional incomplete specification, e.g. basic_fields::at doesn't way what it does with multiple fields. Probably best to just raise these as issues. - What is your evaluation of the potential usefulness of the library? Very useful. It fits very well with my use cases. - Did you try to use the library? With which compiler(s)? Did you have any problems? Using gcc 6.1 on linux, I spent some time writing and rewriting several small http servers to evaluate the library, and Vinnie has now incorporated some of these into the beast repository as examples. Along the way I did discover some minor opportunities for improvement in the library, and Vinnie was quick to respond. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent many hours examining the library over a period of a few weeks, both before and during the review period. I gave the implementation and examples in-depth study, less so the documentation. - Are you knowledgeable about the problem domain? I hope Vinnie asked me to review Beast because I know a thing or two. However, I must qualify that: my experience in HTTP is almost entirely 1.0 and I only have a passing knowledge of websockets. Many thanks to Vinnie for creating Beast and proposing it for inclusion in boost. It is nice to see the addition of protocol implementations that build on top of Asio's asynchronous model so seamlessly. Cheers, Chris

1 0

Re: [boost] [Boost-users] Boost 1.65.0 Beta 1 [boost.python] issue
by Rene Rivera 15 Jul '17

15 Jul '17

On Fri, Jul 14, 2017 at 7:23 AM, Raffi Enficiaud via Boost-users < boost-users(a)lists.boost.org> wrote: > As I said in a previous post, I cannot get boost.python to build on > Windows: the target is just ignored (see stack trace below). > Missed that post :-( > I think there is a bug in .\tools\build\src\tools\python.jam A highly probable statement all on its own :-) > concerning the version computation: the variable "major-minor" is not set > properly if "version" is optional. > > In this block: > > ============= ("rule configure") > if $(version) > { > if ! $(version) in [ feature.values python ] > { > feature.extend python : $(version) ; > py$(major-minor[1])-version ?= $(version) ; > ============= > > The variable "major-minor" is empty. > > The "if" in the following block prevents from computing major-minor as > "version" is optional and is not set: > > ============= > local major-minor ; > if $(version) > { > major-minor = [ split-version $(version) ] ; > version = $(major-minor:J=.) ; > } > ============= > > I believe this can be fixed by recomputing "major-minor" in this block, > after "version" has been inferred. > > ============= > if $(cmd) > { > debug-message ...requested configuration matched! ; > > exec-prefix = $(sys.exec_prefix) ; > > compute-default-paths $(target-os) : $(sys.version) : > $(sys.prefix) : $(sys.exec_prefix) ; > > version = $(sys.version) ; > interpreter-cmd ?= $(cmd) ; > cmds-to-try = ; # All done. > } > ============= > Seems reasonable.. Can you put up a PR for that? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

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

14 Jul '17

>> I have just checked and both mingw and mingw-w64 have only fully lower >> case >> headers. I just checked all includes files from boost (1.65.0 beta2) that have upper case character in their names and are present in mingw or mingw-w64 in lower case. Here is what I found: 3 files, Activation.h, Memory.h, Windows.h. Those are in the following files: ./libs/thread/src/win32/thread.cpp:36:#include <Activation.h> ./libs/iostreams/test/windows_pipe_test.cpp:9:#include <Windows.h> ./libs/process/test/bind_stderr.cpp:32:# include <Windows.h> ./libs/process/test/bind_stdin.cpp:34:# include <Windows.h> ./libs/process/test/sparring_partner.cpp:31:# include <Windows.h> ./libs/process/test/bind_stdout_stderr.cpp:30:# include <Windows.h> ./libs/process/test/exit_code.cpp:21:# include <Windows.h> ./libs/process/test/bind_stdout.cpp:32:# include <Windows.h> ./libs/process/test/group.cpp:32:# include <Windows.h> ./libs/process/test/spawn.cpp:33:# include <Windows.h> ./libs/process/test/spawn_fail.cpp:29:# include <Windows.h> ./libs/process/test/system_test1.cpp:38:# include <Windows.h> ./tools/build/src/engine/boehm_gc/MacOS.c:19:#include <Memory.h> ./boost/fiber/detail/futex.hpp:21:#include <Windows.h> ./boost/fiber/detail/cpu_relax.hpp:19:# include <Windows.h> So that is not a lot. For Memory.h, it seems related to MacOS, not Windows. If people really want to keep the upper case letter, we could then have #ifdef __MINGW32__ #include "windows.h" #else #include "Windows.h" #endif Frédéric Frédéric

1 0

[beast] Version 80: code review opportunity
by Vinnie Falco 14 Jul '17

14 Jul '17

Beast version 80 is sitting in the pull request queue if anyone is interested in providing a code review. This contains changes motivated by Bjorne's desire for more control over chunk-encoded output. <https://github.com/vinniefalco/Beast/pull/641> List of changes since beginning of the formal review: -------------------------------------------------------------------------------- * Javadoc tidying * Add basic_dynamic_body.hpp * Shrink buffer_prefix_view * Remove unused file_path * Add basic_file_body.hpp * buffers_ref is Assignable * Shrink chunk header buffer sequence size * Refactor chunked-encoding serialization * Remove spurious fallthrough guidance * Add span * Documentation work * Use make_unique_noinit * Fix warning in zlib * Header file tidying * Tidy up FieldsReader doc * Add Boost.Locale utf8 benchmark comparison * Tidy up dstream for existing Boost versions * Tidy up file_posix unused variable * Fix warning in root ca declaration * Tidy up basic_string_body * Add vector_body * span, string, vector bodies are public * Fix spurious uninitialized warning * fields temp string uses allocator * Add message::keep_alive() * Add message::chunked() and message::content_length() * Remove string_view_body * file_posix works without large file support * Always go through write_some * Use Boost.Config * BodyReader may construct from a non-const message * Add serializer::get * Add serializer::chunked * Serializer members are not const * serializing file_body is not const * Add file_body_win32 * Fix parse illegal characters in obs-fold * Disable SSE4.2 optimizations * Rename to serializer::keep_alive * BodyReader, BodyWriter use two-phase init * Use file_body for valid requests, string_body otherwise. * Construct buffer_prefix_view in-place * Shrink serializer buffers using buffers_ref * Tidy up BEAST_NO_BIG_VARIANTS * Shrink serializer buffers using buffers_ref * Add serializer::limit * file_body tests * Using SSE4.2 intrinsics in basic_parser if available * Add file_stdio and File concept * Add file_win32 * Add file_body * Remove common/file_body.hpp * Add file_posix * Fix Beast include directories for cmake targets * remove redundant flush() from example * Jamroot tweak * Verify certificates in SSL clients * Adjust benchmarks * Initialize local variable in basic_parser * Fixes for gcc-4.8 * basic_parser optimizations * Add basic_parser tests * Refactor header and message constructors * serializer::next replaces serializer::get * Tidy up set payload in http-server-fast * Refine Body::size specification * Newly constructed responses have a 200 OK result * Refactor file_body for best practices * Add http-server-threaded example * Documentation tidying * Various improvements to http_server_fast.cpp * Add websocket-server-async example * Fix extra ; warning * Documentation revision * Fix spurious on_chunk invocation * Call prepare_payload in HTTP example * Check trailers in test * Fix buffer overflow handling for string_body and mutable_body * Concept check in basic_dynamic_body * Tidy up http_sync_port error check * Tidy up Jamroot /permissive- * Fine tune websocket op asserts * Refactor websocket composed ops * Allow close, ping, and write to happen concurrently * Fix race in websocket read op * Fix websocket write op * Add cmake options for examples and tests * Return `std::size_t` from `Body::writer::put` Thanks

3 4

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

14 Jul '17

>> Maybe we could use lower case windows.h only if __MINGW32__ is defined? > > It's still a fudge that might break. Isn't it better to get to the bottom of > the (MinGW-)problem (other headers are affected as well, as Windows.h is not > the only header starting with a capital)? That's right, we could look at all #includes in boost. I have just checked and both mingw and mingw-w64 have only fully lower case headers. Frédéric

1 0

[beast] Formal review
by Bjorn Reese 14 Jul '17

14 Jul '17

I am going to focus exclusively on the HTTP API in the review below because that needs most attention. Furthermore, to keep this review within reasonable bounds, I am omitting issues already reported by others. I. DESIGN --------- Beast offers a well-designed WebSocket API along with a minimal and deficient HTTP API. Beast claims to offer low-level building-blocks that can be used to produce higher-level HTTP server and client libraries. The low-level approach makes Beast minimal. I do not have a problem with a minimal API, other than it diminishes the usefulness of the library. Although this can be solved by adding more functionality over time, if I was to evaluate Beast with its current feature-level, I would only choose it if I needed WebSocket. This, however, is not a precondition for library acceptance. But the low-level approach also means the abstractions must be right. The abstractions that Beast currently offers are deficient, which is best shown by the poor support for HTTP chunking. Chunking can and should be represented more naturally by a HTTP API. HTTP chunking splits a message into several parts, where each part can contain metadata (chunk extensions) and data (chunk.) The metadata is a set of key-value pairs, just like the HTTP headers. During the review period I have described several use cases for HTTP chunking that does require metadata (e.g. radio metadata,) as well as the preservation of chunk boundaries (e.g. event-based publish-subscribe channels.) Conceptually, a normal HTTP message has the following structure: message = start-line metadata* body? A chunked HTTP message can be described in a similar manner as: message = start-line metadata* ( metadata* chunk? )* The Beast message container is designed for the structure of the normal HTTP message, and assumes that chunks are appended the body. The chunk metadata does not fit into this model, and therefore Beast discards them by default. The repetitive structure of chunked messages is not accommodated by the Beast message container. This means that we have to make our own chunk decorator to generate chunk metadata, and our own custom parser to receive chunk metadata. The chunk decorator inserts metadata via a callback mechanism. Its design is poor for two reasons. First, the user must keep track of context to ensure that the correct metadata is applied to the correct chunks. Second, the user must write the metadata in correct HTTP syntax. The latter may sound trivial, but does anybody here know if " ;key=value\r\n" is correctly formatted? (notice the initial whitespace.) The answer is that it is correct according to RFC 2616, incorrect according to RFC 7230, and correct according to RFC 7230 errata. The best approach for handling this situation is to never insert whitespaces, but to always accept whitespaces from others. Users should not have to be bothered with such detail. Receiving chunk metadata rather than having them discarded by default requires a custom parser. The Beast message parser is a push parser (SAX) where callbacks are invoked for each parsed message part. This means that the user must keep track of which metadata belongs to which chunk. The user must also parse the metadata manually. Beast does not even check if the syntax is correct. The custom parser is also necessary if the user needs to receive individual chunks rather than having them appended to the body. I would have expected that a low-level API returns the next message part as soon as it is identified. The current collect-entire-message design is a higher-level design. In summary, 1. Beast should not discard anything by default, but should faithfully forward all information received. 2. Beast should handle all low-level syntax and not leave parts of it to the user. 3. Beast should not break the end-to-end principle unless allowed by the user. As a way forward I am going to sketch another simple message model that does encompass HTTP chunking. Conceptually it looks like this (I am going to ignore that, say, metadata may require different syntax depending on context) message = start-line section* section = metadata* body-part? Building an API around this model should offer read/write functions that handles partial bodies (whether chunked or progressively downloaded.) The current collect-entire-message API could be build on top of that. With this approach there is no need to mess around with custom parsers. This design does require state information to be able to select the proper syntax for both metadata and data. On another topic, the HTTP status codes can be roughly categorized as instructions (the 1xx and 2xx series) and errors (the 4xx and 5xx series.) I recommend that you create two error categories and pass status codes as error_code. Notice that I have no comment about whether or not they should be stored in the message container. What I really want to achieve is to enable the user to easily propagate HTTP errors in the same way that non-HTTP errors (including beast::http::error) are propagated. II. IMPLEMENTATION ------------------ I read the implementation to understand the design, so I did not look for QA issues. My overall impression is that much of the code is well-written, but there are parts that are convoluted and difficult to verify. There are too many goto statements for my taste; I do not mind the goto pattern used in the parser, but the state-machines in read_some_op and serializer looks more like micro-optimization. Furthermore, "case do_body + 1:" looks like an awful hack. The dynamic buffers are useful even by themselves. The code contains several foreign files with different licensing conditions: * include/beast/core/detail/base64.hpp * include/beast/zlib/zlib.hpp * include/beast/websocket/detail/utf8_checker.hpp * include/beast/http/detail/basic_parser.hpp All these include both the BSL and the original license. This should be checked by the Boost legal council. III. DOCUMENTATION ------------------ The documentation is generally well-written (and it looks like the DynamicBuffer section got a little help from Networking TS.) The Reference is missing some concepts, e.g. SyncReadStream. IV. NAMING ---------- The library name must change. "Boost.Beast" sounds like a bad joke. I do not have strong opinions about the new name. V. VERDICT ---------- I recommend to REJECT the library because the HTTP API provides the wrong low-level abstractions as explained in the design section above.

12 46

Follow-up to the follow-up of the CMake follow-up
by Peter Dimov 13 Jul '17

13 Jul '17

In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work. The instructions for trying it out are the same as last time: git clone --recursive --depth 64 -b feature/install-cmake-config-2 https://githib.com/boostorg/boost bootstrap b2 headers b2 install then add the installation prefix to CMAKE_PREFIX_PATH. An example CMakeLists.txt could look like this: cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0 REQUIRED) find_package(boost_program_options 1.63.0 REQUIRED) # disable autolink add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options)

4 8

[review][beast] Review of Beast starts today : July 1 - July 10
by Michael Caisse 13 Jul '17

13 Jul '17

The formal review of Vinnie Falco’s Beast library will take place from July 1 through July 10, 2017. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction: Components are well-suited for building upon. A branch has been made for the review. You can find Beast for review at these links: * Documentation : <http://vinniefalco.github.io/stage/beast/review/> * Source code : <https://github.com/vinniefalco/Beast/tree/review> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/stage/beast/review/beast/design_choices/faq.ht…> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Beast 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> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

24 107

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