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

[beast] Review
by Marcel Ebmer 07 Jul '17

07 Jul '17

Here's my Review: DESIGN ====== The design of concepts, data structures and algorithms is mostly done well, with only minor concerns: - The smell of two-phase initialization. Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital. The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields, my program may - in the worst case - appear to work correctly. - Inconsequent application of automagic. WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. Also, the very first WebSocket example in the docs makes it clear that while a close from the peer is handled automagically under the above condition, a close from my side is quite tedious to write. There should be a utility in the library to do the draining for me. - The naming of BodyReader and BodyWriter initially got me confused. In my mind, I 'read' a body FROM a stream/buffer, I 'write' it INTO a stream or buffer. The library uses the terms in the reverse sense. This is not incorrect of course, but my initial confusion may be a sign of suboptimal naming. IMPLEMENTATION ============== Didn't look in-depth. DOCUMENTATION ============= The documentation is very well structured. It is complete in many, but not all places. - A minimalistic HTTP server example would have helped me get started. Just something very, very basic. Reply to each request with "your request was". - In some places, non-self-explanatory function names suddenly pop up without being first introduced. For example, in the section "Using WebSocket"."Send and Receive Messages", text() and got_text() could use some explanation. In the same section, the reference to set_option() seems out-of-place and makes me wonder what I missed. - Since the documentation features comparison with other libraries, it may be worth comparing pion (https://github.com/splunk/pion) as well. - Many reference pages could use some prosaic explanation. For example, my uncertainty concerning message.prepare_payload() might have been alleviated, were it more clear what the function is intended for and what the effect of omitting it would be. SCOPE ===== Since the FAQ is quite defensive in regard to the library's scope, I feel this is worth some discussion. I found the scope to be just right for now, but with future potential. As it is, the library takes away all the tedious protocol stuff, while leaving all important design decisions to the user. It feels like an extension to ASIO. However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design. It would, however, make the library user's life a whole lot easier, and probably attract more users as well. USEFULNESS ========== See SCOPE. Very valuable, could be even better. HOW MUCH EFFORT & TRIED TO USE ============================== I invested about a day into the review, read the documentation and ported a small REST-like service from pion to Beast. I may be biased towards Beast due to temporal proximity, but I feel the latter made the code easier to reason about and, at the very least, did not hurt performance. I used gcc 7.1 and clang 4.0. On the review branch, none of the two had any issues. I deliberately did NOT follow the discussion on the mailing list, in order to remain as unbiased as practicable. HOW KNOWLEDGABLE AM I? ====================== I have worked on several HTTP servers and experimented with writing an HTTP server library a few years back. I have no practical experience with WebSockets. IN ONE SENTENCE =============== Beast should be ACCEPTED into Boost. Marcel

2 3

[build] No output until an action completes?
by Tom Westerhout 07 Jul '17

07 Jul '17

Greetings! I've run into a problem that a Boost.Build action produces no output until the command returns. For example, in my Jamfile I have rule do-measure ( test-name : sources * : requirements * ) { ... some preparation work ... } actions do-measure { $(COMMAND) $(ARGS) } notfile ha : @do-measure : ... : ... ; COMMAND is a Python script that runs for a long time and produces some debug information. But b2 does not print this output until COMMAND returns. This is really unfortunate because Travis requires a command to produce output at least once per 10 mins or something. Otherwise it thinks the command has stalled and terminates it. Is there some configuration parameter or a trick to make b2 print the debug info COMMAND produces? or maybe some dummy output so that Travis allows it to run longer than 10 mins? Any help is highly appreciated! Tom

2 2

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[CallableTraits] Review results
by Louis Dionne 07 Jul '17

07 Jul '17

Dear Boost, I am pleased to announce that the CallableTraits library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Bruno Dutra: Yes - Emil Dotchevski: Yes - John P. Fletcher: Yes - Klemens Morgenstern: Yes - Peter Dimov: Yes - Zach Laine: Yes The following people also participated to the review by providing informal feedback: - Edward Diener - Gavin Lambert - Niall Douglas - Paul Fultz II - Tim Song I also based my decision on previous experience I've had using the library, and some issues we faced in the Standard Committee where we could have used CallableTraits. I'd like to thank everyone who participated to the review for their feedback, and also Barrett Adair for his submission. The following lists the conditions for acceptance, and also summarizes the general feedback received during the review. GitHub issues are leveraged to make the tracking of these comments easier. Below, whenever I refer to #XYZ, the corresponding ticket can be found at https://github.com/badair/callable_traits/issues/XYZ To see all the issues that were discussed during the review, you can search for tickets labeled with `review` on GitHub (please allow some time for Barrett to update the new issues I just filed): https://github.com/badair/callable_traits/issues?page=1&q=+label%3Areview Conditions for acceptance ------------------------- The following are points that must be addressed for the library to be accepted. Once all of the associated GitHub issues are closed, I ask that the author post to this list with links to the closed issues. Unless major problems (having to do with the closed issues) are raised at that time, the library will be automatically accepted into Boost, no additional review required. - The library needs to clearly document the advantages of CallableTraits over FunctionTypes. Concrete examples must be given (at least one, preferably two). See #117. - The level of C++ conformance required for the whole library needs to be clearly stated in the documentation. Individual components should only document divergences from that base level of conformance. The current state of things is quite confusing for users. See #118. - The "algorithmic" parts of the library must be removed, since they are out of scope. This has already been partly done in issue #114, but the following algorithms must be discussed too (let's follow up in #114): + args_at + clear_args + pop_front_args + push_front_args + expand_args_right + expand_args_left - The lazy metafunctions and predicate traits should be SFINAE-friendly, just like the aliases are. I think this inconsistency is a big deal, enough to be a condition for acceptance. See #134. Summary of the feedback received -------------------------------- The following is a compilation of other points that were made during the review, but which are not requirements for acceptance. I trust, but do not require, that all of those points will be considered by the author: - There is a loss of information with the `args` metafunction. For example, `void(T)` and `void(T, ...)` both give the same result. See #132. - Consider adding a way of obtaining the parameter list of a function without the type of `*this`. See #133. - The documentation uses the terms of art "implementation defined" and "undefined behavior" incorrectly. See #103 and #131. - The non-reference documentation should present at least one real-world use case. See #116. - The library should handle top-level cv-qualifiers. See #106. - Consider supporting different calling conventions (e.g. `__cdecl`). See #102. - Consider adding a pre-C++17 implementation of `is_invocable` and friends. See #119. - The documentation should clearly state that the library can be used without the rest of Boost. See #99. - Consider combining `expand_args` and `args` into a single metafunction with a default "output" parameter of `std::tuple`. See #126. - Consider adding `make_fn` and `make_mem_fn` metafunctions to construct a signature from a return type and a tuple of the arguments. See #113. - Consider renaming some traits, like `is_reference_member`. See #108. - Reword some parts of the documentation that look odd due to the use of passive tense. See #105. - Consider adding a version of `apply_member_pointer` which carries cv-qualifiers. See #138. - Consider adding `remove_member_cv_ref` and `copy_member_cv_ref`. See #139. - Why does `qualified_parent_class_of` always returns a const& for PMDs? See #112. - Why does `qualified_parent_class_of` return a ref-qualified type even for unqualified PMFs? See #112. A few of my own comments: - Consider using alphabetical order in the table of contents of the reference. See #135. - Consider renaming `apply_member_pointer` to something like `make_member`. See #136. - Consider dropping the `parent_` in `parent_class_of`, or adding a note to justify the name. See #137. Again, thanks to everyone who participated in the review, and congratulations to Barrett for his work! Regards, Louis Dionne

2 3

[beast] Chunking example
by Bjorn Reese 06 Jul '17

06 Jul '17

How would an example of receiving a chunked transfer using the synchronous API look? In pseudo-code, I want to do as follows: establish connection while not closed read chunk print chunk

4 25

Boost Master branch is now closed for the beta
by Marshall Clow 06 Jul '17

06 Jul '17

Except with explicit permission by a release manager. Do whatever you want on develop, just don't change master. We'll re-open master after the beta. -- Marshall Upcoming release schedule: 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release -- Marshall

4 3

Fwd: [review][beast] Review of Beast
by Michael Caisse 06 Jul '17

06 Jul '17

I received this review as a private email from Stanislav who has indicated that I may share it on the list. -------- Forwarded Message -------- Subject: [boost] [review][beast] Review of Beast Date: Thu, 6 Jul 2017 20:23:26 +0300 From: Stanislav Karchebnyy <hidden> To: mcaisse-lists(a)ciere.com Good day! I'm not a very good writer in english, so i tried to keep it short and to the point. - What is your evaluation of the design? I believe it fits well with asio style. - What is your evaluation of the implementation? I like the modularity and composability of the library, e.g. various buffers that comply with asio interfaces. Also use of helpful typedefs makes code a lot easier to read. Code style is almost declarative (which is a good sign in my book). - What is your evaluation of the documentation? Documentation is good, although some methods are documented a little short and a bit tautologically. This is not specific to beast however, seen it in many other boost libraries. - What is your evaluation of the potential usefulness of the library? It is immensely useful as it is already. See below for the example. - Did you try to use the library? With which compiler(s)? Did you have any problems? Currently I’m developing with Beast on latest OSX with clang. It compiles cleanly and runs quite well. The aim is to later use it also on Linux with gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I’m in process of converting our POCO-based networking code for HTTP/HTTPS client and Websocket client to Beast. I started with Websocket and it was a pleasant and rather quick conversion from POCO-style ActiveDispatcher methods (which are ugly with binds and tuples for argument packs) to truly asynchronous beast websocket implementation. We use own protocol running on top of websocket frames, and with beast it was really easy to implement. That beast is a construction framework and does not have unnecessary boilerplate made it quite easy to plug our own parsing engine directly on top of websocket frames. Code became much cleaner as a result. I did not do speed benchmarking yet, as I’m still in development phase, but I’m much more concerned about maintainability in this project and beast made it a lot better - unfortunately I cannot share the code, but now I can trace the state transitions with a glance, instead of digging through bunch of POCO tuple-ridden methods. Another improvement is the fact that POCO websocket uses a dedicated listener thread for input, while beast utilises proper asio design. Beast comes with quite good examples, that covered about 90% of my questions during transition, the rest was answered by Vinnie himself. He is very responsive and helpful as a library maintainer. - Are you knowledgeable about the problem domain? Yes, I know how http and websocket things are supposed to work. My overall impression with the library and its author helpfulness suggests that ACCEPT to boost is a reasonable move. -- Sr. Software Engineer twilio <http://www.twilio.com/?utm_source=email_signature> EMAIL hidden

1 0

[beast] Response alias?
by Bjorn Reese 06 Jul '17

06 Jul '17

Is it possible to provide a HTTP 200 response alias for Beast? This is needed for SHOUTcast internet radio servers. See for instance: https://curl.haxx.se/libcurl/c/CURLOPT_HTTP200ALIASES.html

2 1

string_view versus string_ref
by Andrzej Krzemienski 06 Jul '17

06 Jul '17

Hi Everyone, I would like to understand the situation with these two templates: basic_string_view and basic_string_ref. The official, advertised library is string_ref: http://www.boost.org/doc/libs/1_64_0/libs/utility/doc/html/string_ref.html At the same time we have string_view: http://www.boost.org/doc/libs/1_64_0/boost/utility/string_view.hpp But the latter is never mentioned in the documentation, except in Boost.Log: (see http://www.boost.org/users/history/version_1_61_0.html) The support for boost::basic_string_ref and its specializations is > deprecated; users are encouraged to switch to boost::basic_string_view. > The support for boost::basic_string_ref will be removed in future > releases. > My question: is there any official position of Boost about having these two templates? Regards, &rzej;

4 3

[beast] Looking for ongoing Code Review!
by Vinnie Falco 05 Jul '17

05 Jul '17

Time for a realistic self-assessment. The feedback that I've gotten about Beast thus far has been pretty great, thanks to everyone for taking the time to get familiar with it. Seems like people are overall approving of the technical quality, but there is a recurring theme with the complaints. Specifically that there are small quality of life issues and deviations from best practices. For example, the two-phase initialization, missing verification on SSL client, verbose or missing examples, confusing or missing parts of documentation. Someone suggested that I solicit assistance from the list. I would like to have ongoing code review of everything in Beast before it gets merged. It would benefit the library greatly and thus benefit its users. As new features get developed ("in-scope" items such as file_body) having an extra set of eyes to make sure I don't do something silly or obviously unpleasant would be helpful. This also reduces the possibility that a future version of Beast may require a breaking change. I'm looking for volunteers to provide regular ongoing code review of branches in Beast's pull request queue! I realize this is a big ask, especially because I have a knack for producing quite a bit of code and change over time. Still, its worth asking. Ideally this review will come from stakeholders (i.e. users of the library). Any Beast users who are out there, please consider participating in code reviews. Its easy just subscribe to the repository using the button on the right of its GitHub page and then when you see new pull requests jump in there and add comments on anything you love/hate. I'll take whatever I can get though, so anyone is welcome! Email me if you want to discuss it, <vinnie.falco(a)gmail.com> or just open an issue on the repository: <https://github.com/vinniefalco/Beast> Thanks! |

1 0

[beast] Platform proxy settings, SSL verification
by Phil Endecott 05 Jul '17

05 Jul '17

Here are just a few quick comments re Beast: 1. It's a terrible name, but I believe others have already mentioned that. 2. I don't believe there is any integration with platform proxy settings. I'll explain: I have my own basic HTTP client and server code that I've used in a handful of projects. There are a few features that it lacks that have caused me problems. In particular, when I tried to use my HTTP client code in an iOS app, it worked on WiFi networks but not on some cellular networks. After much remote debugging I realised that some cellular carriers in some countries require that HTTP traffic goes via a (non-transparent) proxy. If you use the iOS http client then this is handled for you, but my code knows nothing about it. For me to test a fix for this I would have had to fly to another continent.... This is the sort of thing that is particularly valuable in a Boost library: I try to write portable code, but I don't know the details of every platform that it will run on or even have test systems available to me. Having a library that knows about the platform-specific details, and which has been tested on a wide variety of those platforms, is very valuable. (And a library that instead just does the "easy parts" is something that I could have written, or already have written, myself.) 3. Finally a comment about the SSL example at https://github.com/vinniefalco/Beast/blob/master/example/http-client-ssl/ht… This says stream.set_verify_mode(ssl::verify_none); Please correct me if I'm wrong, but I think that means that it does not do any sort of certificate verification. As a matter of principle, I think that the *first* SSL example should show how to establish a properly-secure connection. See for example http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf (""The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software") and e.g. https://lwn.net/Articles/522111/ for discussion. A quick look at http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/ssl.html suggests that this might add as few as two more lines to the code. Regards, Phil.

2 4

[release] Release notes for 1.65.0 beta
by Daniel James 05 Jul '17

05 Jul '17

Hi, If you haven't done so yet, please write your release notes for 1.65.0 beta. You can create a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_65_0.q… Or if you'd rather you can send them to me, and I'll add them for you. thanks, Daniel

1 0

[build] header-only lib need dir 'build'?
by Oliver Kowalke 05 Jul '17

05 Jul '17

Hi, does a header-only library require sub-directory 'build' (especially if the lib depends on another, non-header-only library)? In other words; is it safe to remove sub-directory 'build' from boost.coroutine2? thx, Oliver

2 2

[beast] write_some EWOULDBLOCK/EAGAIN error recovery non-blocking operations
by Artyom Beilis 04 Jul '17

04 Jul '17

Have been Beast tested with non blocking sockets? I hadn't found a single reference to asio's non_blocking_io? One of the common use cases is when I want to push a small message to stream (chunk). In 99% of cases the operation will not block so I want to handle this as an optimization for not returning to even loop and creating a callback. According to the reference I didn't find how write_some will behave? I expect to get EWOULDBLOCK kind of error and start asynchronous operation. However I didn't find any reference to the code to non_blocking_io so I wonder if it is supported at all. On same note - how do I run unit tests using b2 - Beast ins't fully Boostified which BTW is also bothering me. Artyom

4 6

[xpressive] Merge PR for fixing MSVC 14.1
by Andrey Semashev 04 Jul '17

04 Jul '17

Hi, There is this PR from Daniela Engert to fix Boost.Xpressive compilation failure with MSVC 14.1: https://github.com/boostorg/xpressive/pull/4 It replaces the removed std::unary_function with the equivalent typedefs. The change looks rather harmless. Could this PR be merged before 1.65 is out? Thanks.

1 1

[iterator][range] BoostIteratorTraversalConcepts-aware boost::advance/distance
by Michel Morin 04 Jul '17

04 Jul '17

Hi, The Boost iterator traversal concepts have not been adopted by the C++ Standard. Because of this, some of RandomAccessTraversalIterators (Boost's concepts) are treated as InputIterators (Standard's concepts) by the stdlib. IMHO, Boost.Iterator should provide BoostIteratorTraversalConcepts-aware `boost::advance` and `boost::distance` to avoid the inefficiencies. However, neither of them are implemented. (Boost.Range has `boost::distance` for ranges, but it just calls `std::distance`.) I'm attaching files that implement `boost::advance` and `boost::distance`. Would these functions be useful additions? Regards, Michel

4 13

[beast] Review
by Peter Dimov 04 Jul '17

04 Jul '17

This is my review of the Beast library. I. DESIGN --------- The design of the library is very good and appears mature. The concepts are well specified, well documented, well thought out. The use of concept checks is a nice touch and a mark of professionalism. I think that basing the library on ASIO (resp. the Networking TS) is a fine decision. This does mean that if one finds an ASIO/NetTS concept less than ideal, one has to live with it, but that's an acceptable tradeoff. Severing the ties with ASIO based on the yet-hypothetical "structured blobs in, structured blobs out" model may sound good in theory, but in practice, a supermajority of the potential users of Beast need to produce a working HTTP or Websocket server, and the library as it stands addresses this need. The design is not perfect; at times the library makes it much too easy for asymptomatic mistakes to be introduced by the omission of a required member function call. For example, if one forgets to set the Content-Length, everything will still appear to work; or if one forgets to initialize the .result of the response, it remains uninitialized. (Note that these, and subsequent, observations appertain to the library as submitted for review; they may no longer be relevant since the author is very quick with the fixes.) There is, at times, unnecessary verbosity, even in the two storefront examples in http://vinniefalco.github.io/stage/beast/review/beast/quick_start.html that are supposed to show the library in the best possible light. For instance, // Set up an HTTP GET request message http::request<http::string_body> req; req.method(http::verb::get); req.target("/"); req.version = 11; Every request will need a method and a target, so having to call members to set them feels unnecessary. A constructor ought to have been provided. Similarly, in the next example, // WebSocket says that to close a connection you have // to keep reading messages until you receive a close frame. // Beast delivers the close frame as an error from read. // beast::drain_buffer drain; // Throws everything away efficiently for(;;) { // Keep reading messages... ws.read(drain, ec); // ...until we get the special error code if(ec == websocket::error::closed) break; // Some other error occurred, report it and exit. if(ec) return fail("close", ec); } the drain loop is basically a requirement for every correct program, so it should have been encapsulated into a helper function. (Even though the example as written does illustrate the use of a drain_buffer.) I'm not particularly fond of the design decision to declare parts that in practice every user of the library will need as "out of scope". People should not be made to reinvent these wheels. I understand the aim of producing a standard library proposal, and that some of these wheels would not be suitable for standardization, but there's nothing easier than just including the suitable wheels in the formal proposal and omitting the unsuitable ones. In practice, these necessary parts end up as examples, so one has to #include "../example/wheel.hpp" instead of "beast/wheel.hpp". It would be better, in my opinion, if one includes, say, "beast/ext/wheel.hpp", with it being known that ext/ is where "out of scope" things go. The ASIO coupling did leave me with one question, whether it would be possible for the library to accommodate OS-specific file to socket transfers such as the one provided by TransmitFile: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).… The idea here is that the OS kernel can dump the file to the socket without involving user mode, which has the potential of much increased performance. For the median user, this would not make much of a difference, but it's an interesting design question, and perhaps an argument that the example file_body class ought to be part of the library proper. ("Is in scope", to use the preferred terminology.) II. IMPLEMENTATION ------------------ I did not pay close attention to the implementation. A random sampling reveals that it's professionally written, and it appears to work, which is good enough for me. The tests run when `b2` is invoked in `test`, have good coverage, and pass with MSVC 14.0 and 14.1. Travis/Appveyor are put to good use. The library provides a doc/Jamfile, which is a plus, but this Jamfile fails, which is a minus. The file reference.qbk has its own separate build script, and this would need to be fixed one way or another when the library is integrated into the Boost documentation build. III. DOCUMENTATION ------------------ The documentation is good. The non-reference parts are very good, the examples are informative. The reference is very good at times, and not so much at others. This is caused by the fact that to get to the good parts one needs to drill down a level or two. For instance, looking at http://vinniefalco.github.io/stage/beast/review/beast/quickref.html I noticed the "async_teardown" function in the WebSocket section, so I clicked on it to see if I need to call that to tear down a WebSocket connection. This lead me to http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket_… which only says "Start tearing down a boost::asio::ssl::stream/connection/boost::asio::ip::tcp::socket." Googling told me that I'm not the only one left not entirely satisfied with these descriptions: https://github.com/vinniefalco/Beast/issues/274 The confusion here stems from the fact that would I, and the issue submitter, have clicked on one of the async_teardowns in that page, we would have reached f.ex. http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket_… which is indeed fine, and mentions that the implementation calls this function, not the user. This is a general pattern with the reference. The leaves are perfectly fine, but the upper levels are often uninformative. IV. PRACTICAL USE ----------------- As part of conducting this review, I ported two existing servers of mine to Beast, one HTTP, one WebSocket. The HTTP server can be seen at https://github.com/pdimov/beast_tpc_server and the WebSocket one is at https://github.com/pdimov/beast_ws_async_server The experience was pleasant and things went more or less as expected, with virtually no nasty surprises. The author was very helpful. The library proper worked exactly as advertised, and the servers were both easier to write than the originals, and became more robust. I only wish that more out of scope things (target parser, basic authorization handling) become in-scope, because their absence is being felt. V. VERDICT ---------- Beast should be ACCEPTED. It's useful, it works, it serves a legitimate need, and I see no design or implementation problems that would preclude acceptance.

2 1

[gil::io] Compilation issue
by Christian Henning 04 Jul '17

04 Jul '17

Hi all, my metaprogramming zen is failing me and I like to ask for some help. Using gil's updated develop branch the following code creates a compilation error with Visual Studio 2015 Update 3. #include <boost/gil/extension/io/tiff_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { gray1_image_t img; write_view( "", view( img ), tiff_tag() ); return 0; } The compiler output is here: https://pastebin.com/raw/d1AB9QMz I think the error is in https://github.com/boostorg/gil/blob/develop/include/boost/gil/premultiply.… but I'm not sure what to do. Any help would be very helpful! Thanks, Christian

1 1

[Beast] Review
by Artyom Beilis 03 Jul '17

03 Jul '17

Hello, This is my formal review of Boost Beast. > What is your evaluation of the design? Also the general design is solid provides generic API that does the job it defined. The most problematic issue with Beast is it total reliance on static polymorphism. This comes to sometimes very painful issues like: Having the object code duplicated for different variants HTTP/HTTPS code Having all the implementation in headers increasing compilation time Adding complexity to end user since he needs to propagate the templates to various places. Virtually all concepts could be done with classic interfaces and virtual functions. Using of static polymorphism does not provide there performance advantage but reduces code maintainability and adds lots of headache to end user. Note: it does not contradict of using ASIO but lots of stuff could be pimpled or hidden having only few forward declarations of the relevant classes. > What is your evaluation of the implementation? >From what I seen didn't find may flows besides thous mentioned before (content-length - that was fixed) and non-blocking sockets aren't covered by tests. However I didn't look too much since the code is quite hard to read being too template heavy. Second major issue is that it puts all the heavy work on end user providing tiny parsing messaging layer that to be honest is the simple part of HTTP handing. It significantly limits its usability to virtually void. > What is your evaluation of the documentation? Documentation is OK - similar to ASIO - I think more examples should be needed and tutorials regarding how to do common tasks. > What is your evaluation of the potential usefulness of the library? VERY limited. The library does too little to be useful for real development. I don't really see a real need for a library that could potentially be used to create CURL or could potentially be used to write web framework that users will work over them. As a user of this library you need to deal with: - User has to have deep knowledge of HTTP protocol itself and be highly aware of various security related problems on WWW. - Protocol itself and know it up to the small details, timeouts and much more. - Being able to parse all parameters passed from getting query string, parsing multipart/form-data (a.k.a. file upload format) parse percent encoding, cookies. I suggest to drawing the line at some point when library becomes useful for somebody who for examples needs to implement RESTful service or send some post data to a form. The separation line that was drawn does not suite the needs of too many of potential users. I understand it is huge task to do but if first lines in your FAQ and many other talk about what the library doesn't do than probably something goes wrong. And please note I don't talk about sessions, url mapping, but much more basic stuff like multipart parsing, url-encoding. URL parsing, > Did you try to use the library? With which compiler(s)? Did you have any problems? Tried to compile several examples no problem. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? At least 10-12 hours of reading documentation, code, running some examples. Notifying potential problems. > Are you knowledgeable about the problem domain? Yes, I'm myself an author of CppCMS C++ Web Framework - fully featured web development platform for C++ that works in both synchronous and asynchronous modes, I implemented HTTP and FastCGI protocols, networking engines myself. Designed high performance services and more. > Should the library be included to Boost? Unfortunately NO. Two major reasons: - Abuse of static polymorphism where classing object oriented design with virtual functions can do better job. - The scope of the library is way too limited that it brings the question of its usability for real users. I fully acknowledge the huge high quality work the author did - something that kept me reviewing the library and providing the comments, but the library as it is today IMHO doesn't suit Boost Best Regards and Good Luck, Artyom Beilis

1 0

[Beast] HTTP/1.0 Protocol compatibility
by Artyom Beilis 03 Jul '17

03 Jul '17

I can't find there an (sami)automatic way to manage HTTP/1.0 vs HTTP/1.1 compatibility? Example I have a client that supports HTTP/1.0 only and I need to transfer an unknown amount of data. Now as one who writes the server I need to check the clients protocol and choose chucked transfer encoding with possibility to keep connection keep alive or close one after data transfer using socket shutdown. Shouldn't this kind of stuff should be handled automatically or sami-automatically? Keep alive semantics between HTTP/1.0 and HTTP/1.1 is tricky and it is very easy to make a mistake. Also note I tested some of your examples and found that they responding with HTTP/1.1 on HTTP/1.0 requests. Artyom

2 1

[property_tree] Is Boost.Property_tree maintaner active?
by Александр Зайцев 03 Jul '17

03 Jul '17

Hello. I see on Boost.Property_tree's Github repo a lot of PR. And I want to know, is maintainer active or not.

1 0

[beast] Asynchronous examples
by Phil Endecott 03 Jul '17

03 Jul '17

Hi, Do any of the Beast examples show its use in asynchronous mode? I'm wondering how difficult it is to achieve this: future< vector< byte > > data = download(url); Regards, Phil.

2 2

[beast] thread per connection example?
by Peter Dimov 02 Jul '17

02 Jul '17

Suppose that I want to implement an HTTP server that uses the thread per connection model. What example should I use as a starting point?

2 2

[beast] Wy does message<> store Body::value_type?
by Peter Dimov 02 Jul '17

02 Jul '17

Why does message<isRequest, Body, Fields> store Body::value_type, using Body::reader and Body::writer to manipulate it, instead of the more straightforward approach of storing Body, which would have allowed making `get` and `put` members of the Body directly, instead of using intermediate classes?

3 3

[beast] Automatic content-length?
by Peter Dimov 02 Jul '17

02 Jul '17

In this code, extracted from one of the examples in the documentation, // Set up the response, starting with the common fields response<string_body> res; res.version = 11; res.set(field::server, "test"); /*...*/ // We return responses indicating an error if // we do not recognize the request method. res.result(status::bad_request); res.set(field::content_type, "text/plain"); res.body = "Invalid request-method '" + req.method_string().to_string() + "'"; // Send the response write(stream, res, ec); field::content_length isn't set. Will Beast insert Content-Length based on the body size, or will it send the response with the field missing? The reason I ask is that I foresee forgetting the content_length to be a common mistake, and an asymptomatic one.

2 7