August 2015 - Boost - lists.preview.boost.org

[Polygon] trait register on derived class
by Lechuan Xue 21 Aug '15

21 Aug '15

Hi, Currently, if I have one custom geometry and a few further derived custom geometries, I need to do trait register on all of them. Like: class derived_point1 : public base_point {}; class derived_point2 : public base_point1 {}; namespace boost { namespace polygon { struct geometry_concept<base_point> { typedef point_concept type; }; struct geometry_concept<derived_point1> { typedef point_concept type; }; struct geometry_concept<derived_point2> { typedef point_concept type; }; } What I want is to register all custom geometries in one step. Like: template<typename T> struct geometry_concept<T, typename std::enable_if<std::is_base_of<base_point, T>()>::type> { typedef point_concept type; }; To do that, I need to add a dummy template type to all the trait classes to enable SFINAE. Attached is the patch (based on boost 1.57.0_1). Is this something we can consider? Thanks, Leo Xue

1 0

Transfer ownership of DLL into boostorg
by Antony Polukhin 19 Aug '15

19 Aug '15

Hi, I'd like to transfer Boost.DLL library ( https://github.com/apolukhin/Boost.DLL) into the boostorg. What's the current procedure for that? -- Best regards, Antony Polukhin

3 6

[http] Boost.Http formal review is finished
by Bjorn Reese 19 Aug '15

19 Aug '15

The formal review of Boost.Http is finished, and I would like to thank all who participated. The following reviews have been recorded: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No Please let me know if I have missed any. The final review results will be posted later.

5 8

[core] Determining interest for two new classes: readonly and newtype
by Sam Kellett 19 Aug '15

19 Aug '15

Hey, I have two classes I've developed that have been used in my own projects that I think could have a place in Boost. They are outlined below. readonly<T>: This is a wrapper class for a type to replace a const-type field in a movable class. It has const access to the type so can't modify except for the move constructor and move assignment operator. This solves the problem that no fields in a movable class can be const which can cloud the intentions of a field. readonly copies the accessor patterns seen in classes such as optional and the smart pointer collection. Example: struct foo { foo() : str("hello world") {} readonly<std::string> str; }; foo f; auto g = std::move(f); static_assert(std::is_move_constructible<foo>{}, ""); std::cout << *g.str << std::endl; g.str->clear() // error: non-const method. ----- newtype<N, T> This is shamelessly ripped off from Haskell and provides strongly-typed typedefs to C++. It actually has two template parameters, one is an incomplete type that provides a unique identifier for this typedef. I've opted to use the name of the typedef with an '_t' suffix, the second is the raw type that it contains. Like readonly the underlying type can be accessed by operator*, operator-> and get() methods. Example: using age = newtype<struct age_t, int>; age a{25}; using byte = newtype<struct byte_t, int>; byte b{42}; // do something with bytes (*not* any old int). void bar(const byte); bar(a); // error: wrong type wanted 'byte' got 'age' bar(b); // okay bar(89); // error: wrong type wanted 'byte' got 'int' assert(*b == 42); Any thoughts on the design and/or their place in Boost would be much appreciated. Cheers, Sam

8 16

[build] Algorithm for setting PATH when a 'run' or 'run-fail'
by Edward Diener 18 Aug '15

18 Aug '15

What is the algorithm for setting a PATH on Windows when the 'run' or 'run-fail' rule occurs in a jamfile ? In running clang on Windows when an executable is created the PATH needs to start with the bin directory of the mingw(-64)/gcc implementation that a particular version of clang uses as its RTL when the program is compiled/linked. It appears that when the 'run' or 'run-test' rule occurs with the clang toolset on Windows that the PATH is adjusted to have the directory of the clang++ executable and not that of the corresponding mingw(-64)/gcc RTL ? Is there any solution to this from within Boost Build ?

2 5

[lclcontext] Any interest in Pythonesque "with-as" statement in C++.
by Mostafa 18 Aug '15

18 Aug '15

I think Python's concept of Context and Context Managers useful and I've adapted, to the best of my abilities, a similar concept in C++. For those not familiar with this concept, I'll quote a brief snippet from the documentation: "Simply stated, this library enables the use of the Pythonesque with-statement construct in C++. More broadly, this library seeks to formalize a generalized version of a subset of the RAII (Resource Acquisition is Initialization) idiom that, for the lack of preexisting terms, I shall refer here to as the STEP (Scope Triggered Event Processing) idiom. The STEP idiom is the commonly occurring use case where for a given block of code some user specified action(s) must execute on entry and on exit, and the failure to do so will result in some deterministic behavior." You can find the library here: https://github.com/m-w-a/WG Documentation is here: https://github.com/m-w-a/WG/tree/master/Local/Docs (In the same repository I've also redid Boost's local_function, but that the subject of another posting.) If there is enough interest from the community for such a library then I will go ahead and "Boostify" it.

3 6

[http] Formal Review
by David Sankel 17 Aug '15

17 Aug '15

> 1. Should Boost.Http be accepted into Boost? Please state all conditions for acceptance explicity. No. This library unfortunately is not complete enough to be in Boost. > 2. What is your evaluation of the design? >From my reading, the design of the low level components that are in the library seems okay. > 3. What is your evaluation of the implementation? Looks okay from what I've seen. > 4. What is your evaluation of the documentation? More tutorials for common use cases are needed. I fear, though, that the only use case of these low-level components is the writing of a higher-level one on top of it that is more widely useful. > 5. What is your evaluation of the potential usefulness of the library? In its current state, I do not find this library very useful. A Boost HTTP library should support both client side and server side. Micro-services are quite commonly used these days and only communicating one direction excludes this library from having full participation. While I very much enjoy and appreciate the exposed lower-level functionality, higher level abstractions are required to scratch the itch most developers have when they want a C++ HTTP library. I could not recommend this library over pion for this reason even though I like this library's design better. In particular, we need really good stories for: a) How to fetch the contents of a website given a URL. b) How to make a static page server. c) How to write code that handles a POST or GET request dynamically based on specified parameters. d) How to write a server that accepts file uploads. e) HTTP/2.0 f) Websockets I would also like to see instances of this library being used in production. That would give some evidence that the design works in practice. There is the argument that we should accept this into Boost now because, once it has more features, it'll be really great. I think that Boost is for libraries that are already really great. I don't see how getting more exposure to an incomplete library helps either Boost or the library, but I do see how it can do damage to the Boost name. > 6. Did you try to use the library? With what compiler? Did you have any problems? I built the library and ran the single example. I used gcc 5.2.0. I didn't run into any problems and was quite happy with this part of the review. > 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a couple hours reading through the documentation and the mailing list discussions. > 8. Are you knowledgeable about the problem domain? Yes. I'm the architect of a large C++-based web framework for the US Government. We currently use pion as our primary server and client low-level library. I've contributed some minor patches to pion. -- David Sankel

1 0

[lclfunction][local_function] Any interest in a redone version of local_function.
by Mostafa 17 Aug '15

17 Aug '15

I've made a library called lclfunction which is basically a redone version of local_function except for the following important differences: 1. This library allows the function name to be specified at and only at the top of the local function declaration. 2. This library allows local functions to maintain internal state without referencing external variables (via varset). 3. This library allows the use of globally scoped types as macro parameters, i.e., ::std::pair<..., ...>. 4. This library can handle binding array types. 5. IMHO, this library has a cleaner implementation: a) The preprocessor translator is partitioned into a front end and back end. b) A well-defined symbol table bridges the two translation layers. c) It has well-defined error-generating mechanism with a separate error pass before code generation. 6. It uses a different syntax. The main reason I did this redone library is because local_function required putting the function's name in the closing macro and that rubbed me the wrong way, my view is that it should and can be placed in the opening macro. If there is enough interest from the community I will "Boostify" it. Thanks, Mostafa

1 1

boost.org https certificate expired 4 month ago
by Jens Weller 16 Aug '15

16 Aug '15

Hello boost community, I noticed today that the https of boost.org is expired, and should have a new certificate: https://www.ssllabs.com/ssltest/analyze.html?d=boost.org thanks, Jens Weller

11 17

[http] Formal Review
by Antony Polukhin 16 Aug '15

16 Aug '15

Hi, This is my formal review for Boost.HTTP library. 1. Should Boost.Http be accepted into Boost? No. It has some big architectural issues and a lot of issues in code. 2. What is your evaluation of the design? That's the fatal problem of the library. It seems like the library attempts to get best from ASIO and cpp-netlib and unfortunately fails. Now let's get into details: * ASIO is a low level abstraction over protocol that does not take care about memory management of buffers (in most cases it's the responsibility of user to allocate and keep alive the required buffers). * cpp-netlib takes care of memory management, hides low-level stuff. Boost.Http is stuck somewhere in the middle: sometimes it allocates and extends buffers, sometimes not. Because of that the design does not seem solid. Any attempt to hide all the memory management inside the library will end in an another implementation of cpp-netlib. So it seems right to remove all the memory management from the library internals and make the library closer to ASIO. Here are my recommendations for separation of flies and dishes: * Stick to the idea that http socket must ONLY manage connection without extending the ASIO's send/receive function signatures. That means that http1.0 and http1.1 sockets must be almost a typedef for tcp/ssl socket. Http2.0 socket must be very close to SSL socket. No additional methods (like async_read_trailers or async_write_response) must be provided. * It must be a user's responsibility to provide buffers for messages. Never extend buffers in socket-related methods. * Provide helper classes that parse and generate http * Provide out-of-the-box completion conditions for async_read operation: http::completions::full, http::completions::headers, http::completions::body... Those bullets will allow to write following code (based on http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/tutorial/tutdaytim… with minimal modifications): #include <ctime> #include <iostream> #include <string> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/asio.hpp> std::string make_daytime_string() { using namespace std; // For time_t, time and ctime; time_t now = time(0); return ctime(&now); } class http_connection : public boost::enable_shared_from_this<http_connection> { public: typedef boost::shared_ptr<http_connection> pointer; static pointer create(boost::asio::io_service& io_service) { return pointer(new http_connection(io_service)); } http::socket& socket() { return socket_; } void start() { message_.resize(4 * 1024); boost::asio::async_read(socket_, boost::asio::buffer(message_), http::completions::full(message_), // read until all the whole request is in `message_` boost::bind(&http_connection::handle_read, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } private: http_connection(boost::asio::io_service& io_service) : socket_(io_service) {} void handle_write(const boost::system::error_code& /*error*/, size_t /*bytes_transferred*/) {} void handle_read(const boost::system::error_code& error, size_t bytes_transferred) { assert(!error); // for shortness // `message_` contains the whole request, including headers and body // because http::completions::full was provided { boost::system::error_code e; http::view v(message_, e); // represent buffer as http message assert(!e); // no error occured during parsing assert(v.read_state() == http::read_state::empty); std::cerr << v.version(); // "HTTP1.1" std::cerr << v["Content-type"]; // "plain/text" std::cerr << v.body(); // string_ref("Hello! This is a body content. What time is it?") message_.clear(); // `v` is now invalid to use! } { http::generator resp(message_); // use `message_` for an output resp << make_daytime_string(); // append daytime to body resp["Content-Type"] = "plain/text"; // set some headers resp.version(http::version::HTTP_1_1); // explicitly set HTTP version resp.code(200); // "200 OK" resp.flush(); // explicitly flush to buffer. Done automatically in destructor } boost::asio::async_write(socket_, boost::asio::buffer(message_), boost::bind(&http_connection::handle_write, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } http::socket socket_; // manages the connection only std::string message_; }; class http_server { public: http_server(boost::asio::io_service& io_service) : acceptor_(io_service, http::endpoint(http::all_versions, tcp::v4(), 80)) { start_accept(); } private: void start_accept() { http_connection::pointer new_connection = http_connection::create(acceptor_.get_io_service()); acceptor_.async_accept(new_connection->socket(), boost::bind(&http_server::handle_accept, this, new_connection, boost::asio::placeholders::error)); } void handle_accept(http_connection::pointer new_connection, const boost::system::error_code& error) { if (!error) { if (new_connection->socket().version() == http::version::HTTP_2_0) { // do some more stuff } new_connection->start(); } start_accept(); } http::acceptor acceptor_; }; int main() { try { boost::asio::io_service io_service; http_server server(io_service); io_service.run(); } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } This will also untie Boost.HTTP from ASIO. Now users could use http::generator/http::view to read/generate HTTP data. This significantly extends the use cases of your library (for example on a previous work we had our own network transfer implementation, but we'd gladly use a http parser and generator). Such code is also less intrusive: only minimal chages were required to change a tcp example into the http example. Users will appreciate that, especially in cases when ASIO is already used for HTTP. BTW, after that you could easily implement http::stream (that must be close to tcp::stream by functionality). http::stream would be a killer feature that would be widely used by utility programs (as I remember current Boost's regression testing requires it, but uses tcp::stream with a bunch of workarounds). Please, implement the HTTP2.0 protocol. There are some open source solutions that are licensed under the Boost license and are very close to full implementation of HTTP2.0. Just reuse the code and chat with the authors for better understanding of the problems. 3. What is your evaluation of the implementation? Not perfect. For example https://github.com/BoostGSoC14/boost.http/blob/master/include/boost/http/so… It seems that `std::vector<asio::const_buffer> buffers; buffers.reserve(nbuffer_pieces);` is meant to be here. There are more such places... It seems that some useful features (like custom allocators) are not supported by the library. It's better to be fixed. Some of the implementation issues are because of the library design. For example requesting multiple async operations (async_read_request+async_read_some+async_read_trailers) is performance hit. It's better to read all the data at once (just like in the example from above). 4. What is your evaluation of the documentation? First code snippet in tutorial contains mostly ASIO's stuff and almost no HTTP stuff. That's wired... If bullets from above would be implemented, then I'd rather start with parsing and generating simple http messages. Then an example with sockets could be provided. Also please do not use coroutines at least in first example. coroutines is a new feature in ASIO, many users use old Boost versions that have no coroutines and some users are not familiar with them. So if you start with coroutines user will have to go to ASIO docs and dig into coroutines to understand the very first example. Example without coroutines will be more user friendly. 5. What is your evaluation of the potential usefulness of the library? Library is very useful and required. But in current state it must not be accepted into Boost. 6. Did you try to use the library? With what compiler? Did you have any problems? Have not tryed. 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours digging into docs, about 3 hours looking into the sources, about 3 hours formulising the issues and recommending solutions. 8. Are you knowledgeable about the problem domain? Not an expert, but used ASIO a lot along with cpp-netlib and some other libraries close to the proposed one. 8.3333(3) Review Please, reserve a bigger window when such complex library is proposed for review. It's hard to review it in 10 days. 8.6666(6) For Reviewers I urge other reviewers to take a look at the cpp-netlib. If you treat Boost.Http as an out-of-box solution, then cpp-netlib is more mature, user-friendly and solid. If you treat Boost.Http as a basic building block for HTTP (just like ASIO is a basic building block for networking), then it's better to stick to the ASIO's design and do not *partially* manage memory! P.S.: I hope that this library would be changed according to my recommendations and submitted for a new review. -- Best regards, Antony Polukhin

3 24