- Boost - lists.preview.boost.org

[http] Boost.Http review report
by Bjorn Reese 28 Aug '15

28 Aug '15

The outcome of the formal review of Boost.Http is that the library is NOT accepted for inclusion into Boost this time. Below I will first summarize the main themes running through the review, and afterwards I will make some recommendations about how to proceed from here. The following reviews were posted: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No The discussions were constructive and offered much valuable feedback. There was a general consensus that Boost ought have a HTTP library, but that Boost.Http was too incomplete in its present state. Many reviewers mentioned the disconnect between their expectations and what the library offered. There were several suggestions for alternative names for the library to better reflect the feature-set it offers. Boost.Http currently only provides a server-side API, but the reviewers felt that a client-side API would be usable to more users. There was also a recurring request for Boost.Http to be a header-only library. The HTTP parser currently used is not header-only and that is the main obstacle towards a header-only Boost.Http library. Some of the discussion revolved around what level of abstraction would be appropriate for Boost.Http. The views ranged from wanting higher- level APIs all the way down to simply wanting a HTTP parser/generator and then leave all the socket and buffer management up to the user. Regarding the HTTP parser/generator, there is no reason why it cannot be a separate Boost library. However, Vinicius correctly pointed out that this is insufficient for a HTTP server framework that handles multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication it cannot handle HTTP upgrade requests either. Some reviewers also felt that HTTP/2 should be part of Boost.Http, partly because that would demonstrate the extensibility of the current design, and partly because the library would be in a stronger position to attract users if it offers more than its competitors. There was concern about whether or not the Boost.Http API can be extended to HTTP/2. The main challenge with HTTP/2 is fitting multiplexing into the API. Vinicius suggested that there should be a http::socket per multiplexed channel, so it will be transparent to the user if several of his http::sockets to the same remote endpoint are transported via the same TCP socket. This will keep the API clean when extended to HTTP/2. Boost.Http currently creates an associative array for all header fields. One reviewer explored the idea of using an incremental (push or pull) HTTP parser as part of the API to let users decide which header fields to copy and which to discard. There was a general consensus that more examples are needed, and that the tutorial should have smaller examples. The Boost.Http code base currently builds with CMake. This must be converted into Boost.Build before being integrated into the Boost code base. Several other third-party tools were suggested, but as these are not requirements for inclusion into Boost I will leave the decision to the author. As for the future, I hope that Vinicius is not too discourage by the current rejection, and that he will consider re-submitting the library at a later stage. Judging from the reviews, the following additions will make a future submission more likely to succeed: 1. Involve the community more during the development. This will both solicit earlier feedback on the design, and help to align community expectation. 2. Provide a client-side API. 3. Design higher-level APIs on top of the low-level APIs. 4. Better documentation and more examples. I also hope that people in the community will consider contributing to the library. For example, a good opportunity is to help creating the higher-level APIs. Another opportunity is to help with the (header- only, possibly incremental) HTTP parser/generator, which could be a separate library.

4 3

[trac] Adding notification for component
by Edward Diener 28 Aug '15

28 Aug '15

I have a few trac questions. Who is the trac administrator ? How does one change the default person who is assigned a trac ticket for a particular Boost library ? How does one get added as a notification for a particular Boost library activity on Trac ? How do I add vmd as a component/library in trac ?

3 3

[website] [log] Add a patch to 1.59 release notes
by Andrey Semashev 27 Aug '15

27 Aug '15

Hi, Unfortunately, Boost.Log in Boost 1.59 contained a serious bug that affected many users (I got multiple reports already): https://svn.boost.org/trac/boost/ticket/11549 There's a fix in develop, and it went through some testing (including my manual test runs): https://github.com/boostorg/log/commit/7da193fde1a9c1bc925ee980339f4df2e1a6… Is it possible to add a patch from this commit and a link to the ticket to the 1.59 release notes? PS: You can download the patch if you add ".patch" to the above link: https://github.com/boostorg/log/commit/7da193fde1a9c1bc925ee980339f4df2e1a6…

2 3

[filesystem] Relative Draft Proposal RFC
by Beman Dawes 27 Aug '15

27 Aug '15

There have been requests for a Filesystem library relative function for at least ten years. The requested functionality seems simple - given two paths with a common prefix, return the non-common suffix portion of one of the paths such that it is relative to the other path. In terms of the Filesystem library, path p("/a/b/c"); path base("/a/b"); path rel = relative(p, base); // the requested function cout << rel << endl; // outputs "c" assert(absolute(rel, base) == p); If that was all there was to it, the Filesystem library would have had a relative function years ago. Critical issues: Clashing requirements, symlinks, directory placeholders (dot, dot-dot), user-expectations, corner cases. A paper by Jamie Allsop, Additions to Filesystem supporting Relative Paths, is what broke my mental logjam. Much of [my proposal] is based directly on Jamie's analysis and proposal. The weakly_canonical function and aspects of the semantic specifications are my contributions. Mistakes, of course, are mine. The full proposal is at http://boostorg.github.io/filesystem/relative_proposal.html A preliminary implementation is available in the feature/relative2 branch of the Boost Filesystem Git repository. See github.com/boostorg/filesystem/tree/feature/relative2 The overall plan is to get feedback from boost developers, then merge to develop for boost 1.60, then propose to the C++ committee for addition to the Filesystem TS. Comments welcome. If you are one of the many people who have requested "relative" functionality, does this proposal meet your needs? If not, why? Thanks, --Beman

1 1

[iterator] Regenerating the iterator docs
by Edward Diener 26 Aug '15

26 Aug '15

I have updated a very small portion of the iterator docs and now I need to regenerate the documentation. Evidently despite iterator having quickbook documentation the actual documentation presented to end-users is created from RST files, python scripts, and make files. But I do not see the process of regenerating the docs explained anywhere so I am wondering if anyone knows how to do it. I tried 'python generate.py' on Windows but this led to the error: > make counting_iterator.html facade-and-adaptor.html filter_iterator.html functio > n_input_iterator.html function_output_iterator.html index.html indirect_iterator > .html pointee.html iterator_adaptor.html iterator_facade.html new-iter-concepts. > html permutation_iterator.html reverse_iterator.html transform_iterator.html zip > _iterator.html iterator_archetypes.html iterator_concepts.html iterator_traits.h > tml counting_iterator.pdf facade-and-adaptor.pdf filter_iterator.pdf function_in > put_iterator.pdf function_output_iterator.pdf index.pdf indirect_iterator.pdf po > intee.pdf iterator_adaptor.pdf iterator_facade.pdf new-iter-concepts.pdf permuta > tion_iterator.pdf reverse_iterator.pdf transform_iterator.pdf zip_iterator.pdf i > terator_archetypes.pdf iterator_concepts.pdf iterator_traits.pdf > executing: 'make counting_iterator.html facade-and-adaptor.html filter_iterator > .html function_input_iterator.html function_output_iterator.html index.html indi > rect_iterator.html pointee.html iterator_adaptor.html iterator_facade.html new-i > ter-concepts.html permutation_iterator.html reverse_iterator.html transform_iter > ator.html zip_iterator.html iterator_archetypes.html iterator_concepts.html iter > ator_traits.html counting_iterator.pdf facade-and-adaptor.pdf filter_iterator.pd > f function_input_iterator.pdf function_output_iterator.pdf index.pdf indirect_it > erator.pdf pointee.pdf iterator_adaptor.pdf iterator_facade.pdf new-iter-concept > s.pdf permutation_iterator.pdf reverse_iterator.pdf transform_iterator.pdf zip_i > terator.pdf iterator_archetypes.pdf iterator_concepts.pdf iterator_traits.pdf' > make: Nothing to be done for `counting_iterator.html'. > make: Nothing to be done for `facade-and-adaptor.html'. > make: Nothing to be done for `filter_iterator.html'. > make: Nothing to be done for `function_input_iterator.html'. > make: Nothing to be done for `function_output_iterator.html'. > make: Nothing to be done for `index.html'. > make: Nothing to be done for `indirect_iterator.html'. > make: Nothing to be done for `pointee.html'. > make: Nothing to be done for `iterator_adaptor.html'. > make: Nothing to be done for `iterator_facade.html'. > make: Nothing to be done for `new-iter-concepts.html'. > make: Nothing to be done for `permutation_iterator.html'. > make: Nothing to be done for `reverse_iterator.html'. > make: Nothing to be done for `transform_iterator.html'. > make: Nothing to be done for `zip_iterator.html'. > make: Nothing to be done for `iterator_archetypes.html'. > make: Nothing to be done for `iterator_concepts.html'. > make: Nothing to be done for `iterator_traits.html'. > make: Nothing to be done for `counting_iterator.pdf'. > make: Nothing to be done for `facade-and-adaptor.pdf'. > make: Nothing to be done for `filter_iterator.pdf'. > make: *** No rule to make target `function_input_iterator.pdf'. Stop. > Traceback (most recent call last): > File "generate.py", line 30, in <module> > syscmd('make %s' % ' '.join(all)) > File "C:\Programming\VersionControl\modular-boost\libs\iterator\doc\syscmd.py" > , line 14, in syscmd > repr(s), err) > SystemError: command: 'make counting_iterator.html facade-and-adaptor.html filte > r_iterator.html function_input_iterator.html function_output_iterator.html index > .html indirect_iterator.html pointee.html iterator_adaptor.html iterator_facade. > html new-iter-concepts.html permutation_iterator.html reverse_iterator.html tran > sform_iterator.html zip_iterator.html iterator_archetypes.html iterator_concepts > .html iterator_traits.html counting_iterator.pdf facade-and-adaptor.pdf filter_i > terator.pdf function_input_iterator.pdf function_output_iterator.pdf index.pdf i > ndirect_iterator.pdf pointee.pdf iterator_adaptor.pdf iterator_facade.pdf new-it > er-concepts.pdf permutation_iterator.pdf reverse_iterator.pdf transform_iterator > .pdf zip_iterator.pdf iterator_archetypes.pdf iterator_concepts.pdf iterator_tra > its.pdf' returned 2 Is this process only successful under Linux ? I have a 'make' as the GnuWin32 package installed on Windows. But something is missing in this process.

8 24

[vmd] Adding to boost master branch
by Edward Diener 26 Aug '15

26 Aug '15

In an effort to get vmd as a submodule of the boost superproject master branch I submitted a PR against Boost on master ( https://github.com/boostorg/boost/pull/93 ). In this PR I added vmd to .gitmodules and also to the status/jamfile.v2 for testing. But looking at the Travis CI build of this a failure occurs: 0.01s$ cd status The command "cd status" exited with 0. 2.13s$ ../b2 -n -d0 error: Unable to find file or target named error: '../libs/vmd/test/' error: referred to from project at error: '.' There is most definitely a jamfile and tests at libs/vmd/test on the master branch. Is there something else I have to do to get vmd added to the master branch ?

3 5

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:30, Robert Ramey wrote: > > There is precedent for this: Boost.Fiber was provisionally approved > > here as a C++ 98 library with condition of a mini-review before > > entry. Boost.Fiber is now a C++ 14 library and sufficiently different > > from the library originally reviewed it may require a second > > mini-review if during its first mini-review it is felt still lacking. > > This is a precedent - a bad one which I hope to avoid a repetition of in > the future. A library which is accepted should be close enough to it's > final state so that it can be finished up on the order of a couple of > months and will result in a final version which is close to what > reviewers actually reviewed. > > We can't have a library pass a review, then have the package morph into > something significantly different then have it accepted. This make the > original review a farce. I've been watching Fiber closely since we reviewed it. As far as I know, the public API has barely changed. The documentation has improved in all the areas the review recommended. Just because the internal implementation is radically different does not mean it has morphed into something significantly different. For example, Oliver is considering making boost::fiber::future<> based on my Monad/Outcome Concurrency TS custom future framework as why bother duplicating the work. If he did, even then the public API reviewed and accepted into Boost remains exactly that which was reviewed and accepted. You don't really need to know or think about Monad/Outcome for boost::fiber::future<> to work as a C++ 11 type future. > All > > these changes to AFIO are almost entirely driven by changes since > > 2012 to the various WG21 technical standards. If they hadn't changed > > and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't > > have changed. > > > It's very similar for Fiber, which had to be refactored > > in the face of substantial changes in C++ 14. > > I seriously doubt that a package which compiles and passes tests and > reviews with C++03 cannot do these things when C++11 comes out. What > really happens is that the author sees opportunities with C++11 that he > didn't have before then starts incorporating them after the original > review. I guess this would be called feature creep or implementation > creep. In any case, it indicates that the original acceptance was > premature. I think he saw a chance to make his internal implementation code vastly simpler and easier to maintain yes. Same as me. We're going to be supporting this thing for a decade or so, it makes sense to invest in saving ourselves work. > Ultimately it hinges on what "acceptance into Boost" means. To me it's > a library ready - with a few straight forward / uncontroversial changes > which is ready to be incorporated into the boost distribution. It's not > acceptance of an idea for a library, a prototype for a library, or that > a developer is certified to add a library in the future. I agree. But I draw the line between API and design and then the internal implementation. If it's just the latter which has changed and the API and design is identical, I think a mini-review is enough. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

boost.test documentation header
by Raffi Enficiaud 25 Aug '15

25 Aug '15

Hi, Boost.test 1.59 documentation header is not the same as the other boost libraries. In particular, the green header is missing: http://www.boost.org/doc/libs/1_59_0/libs/test/doc/html/index.html vs for instance: http://www.boost.org/doc/libs/1_59_0/libs/assert/assert.html I would like to know how to include this header and what I am missing in the documentation generation. Those headers are also mentioning the latest available version of the doc. Thanks, Raffi PS.: sorry for cross-posting, but I cannot get an answer on boost-doc ML/

3 4

Boost Social Event at CppCon
by Jon Kalb 25 Aug '15

25 Aug '15

Boosters, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now regulars. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 20th and 25 and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² I hope to see you at CppCon. Jon

1 0

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:37, Paul A. Bristow wrote: > 1. Should Boost.AFIO be accepted into Boost? Please state all > conditions for acceptance explicity. > > Provisionally, yes. > > Requirements: > > . Major restructuring of documentation. (Not re-writing!) > > . Completion of Boost.Was_Called_Monad and APBind. > > . Creation of a TODO list. > > . Mini-review before going into a release (perhaps of all together?). > > . More documentation of examples to explain what they demonstrate. Thanks for the review Paul. I pretty much agree with all of it. This review process has been particularly useful for helping me see the documentation as others see it - I had no idea it was so confusing! - and I'm going to try raising with the Standard C++ Foundation in Seattle next month the idea of them funding professional copy writers to take passes at C++ library documentation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Did Boost 1.59.0 change the meaning of "using python : 3.4 : ..." in user-config.jam?
by Jonathan Wakely 24 Aug '15

24 Aug '15

Hi, I'm trying to update the Fedora rawhide package to Boost 1.59.0 and the build fails with the output below (ignore the MPI warnings). We build with the following in user-config.jam: # This _adds_ extra python version. It doesn't replace whatever # python 2.X is default on the system. using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Is that comment no longer true? Did something change in Boost 1.59.0 so that that line now sets the only allowed python version? I can make the build work with the following but I'd like to understand the change: using python : 2.7 : /usr/bin/python2 : /usr/include/python2.7 : : : : ; using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Build failure: + echo ============================= build serial ================== + ./b2 -d+2 -q -j4 --without-mpi --without-graph_parallel --build-dir=serial variant=release threading=multi debug-symbols=on pch=off python=2.7 stage MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/feature.jam:494: in feature.validate-value-string from module feature error: "2.7" is not a known value of feature <python> error: legal values: "3.4" /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:276: in validate1 from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:302: in property.validate from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:216: in convert-command-line-element from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:154: in build-request.from-command-line from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build-system.jam:583: in load from module build-system /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/modules.jam:295: in import from module modules /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /builddir/build/BUILD/boost_1_59_0/boost-build.jam:17: in module scope from module

2 8

Unicode characters in filenames
by Tom Kent 24 Aug '15

24 Aug '15

Recently there was a thread that ended up changing the boost guidelines so that Unicode characters are now allowed in C++ source files. http://lists.boost.org/Archives/boost/2015/06/223822.php However, in the 1.59 release, there was a filename that had unicode characters in it: libs\preprocessor\doc\Appendix A An Introduction to Preprocessor Metaprogramming.html. Which, HTML encoded, actually looks like: Appendix%20A%20%C2%A0%20An%20Introduction. Note the %C2%A0 character (Hex C2A0, Octal: 302240, Windows displays: ┬á)? Since this seems like a mistake, I've created a pull request for this in pre-processor. However, it begs the question: Should we support unicode codepoints for filenames in the boost distribution? I would like for this answer to be 'no' as there are still lots of tools out there that don't correctly handle unicode filenames. However, it is worth bringing up the discussion. Is there a reason we would want unicode file names? I would guess that tests uses them (especially the filesystem tests), however I would also expect that these tests generate the files on the fly, and that they aren't part of what is distributed. Thoughts? Tom Kent

5 9

"Simple C++11 metaprogramming"
by Peter Dimov 22 Aug '15

22 Aug '15

I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/ which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.) Ordinarily, any such experiments of mine leave no trace once I abandon them and move on, but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-) http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html

17 55

cache size runtime detection
by Joel FALCOU 22 Aug '15

22 Aug '15

We have a bunch of cross-platform CPU cache size and cache line size detection that we want to offload into boost in preparation for the first reviewable version of Boost.SIMD. It's rather smallish in term of API but the code is non-trivial. I think it's a bit broad to be in utility/core, doesn't really fit in align and IIRC there is no "general memory related" library in Boost. Questions: 1/ would there be interest to have such utility in Boost ? 2/ here should we put it ? Is Boost.Memory a viable solution or could it be hosted somewhere non-trivial ? Regards

10 25

[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

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Niall Douglas 16 Aug '15

16 Aug '15

On 7 Aug 2015 at 19:29, Vinícius dos Santos Oliveira wrote: > > I do not believe Http is ready for peer review for these reasons, and > > I personally would urge you withdraw it until you have fixed these > > issues and then come back to us. If you do not withdraw it, I will > > vote for rejection. > > Can I persuade you to review the Boost.Http design? I'd reject myself if > you find any fundamental flaw on the design and even if you're going to > reject the library because the lack of tooling (not directly related to > design or documentation, which are the most important items on any > library), it'd be useful to know what needs to be addressed on the design > before I submit again (in the case the submission is rejected). I think my earlier email was poorly phrased now I've slept on it. I made my objections seem like they were about portability, when they were really about design and intent of Http. What I should have said was this: Standalone ASIO is the reference Networking TS implementation for standardisation. Http is currently a set of extensions to Boost.ASIO specifically when it *should* be a set of extensions to the reference Networking TS implementation for C++ standardisation. This is why your current design and architecture is flawed, but luckily there isn't too much work to fix this by finishing the port of Http to the Networking TS. The Internet of Things tends to involve lots of small somewhat underpowered internet devices where C++ is likely going to play a much more important role than historically in embedded systems. The chances are that any Networking TS in C++ will be very extensively used in such IoT applications. If there were also a high quality set of extensions adding HTTP support to the Networking TS, I think your chances are good that your Http library would be seriously considered by WG21 for standardisation. *This* is why I very strongly believe that Http needs to cleave itself tightly to the Networking TS reference implementation, and not to Boost.ASIO. Moreover, if you make Http an extension of the Networking TS, you get Boost support with that for free - Http becomes dual use. > About C++03 support, it's not required for Boost acceptance, so I can add > later. I want to increase tests coverage a lot before porting code to > C++03, so I don't introduce accidental bugs in the process. As a strong advocate for C++ 11 over 03 I can understand. However, IoT developers tend to be stuck on some pretty ancient toolsets for longer than others. 03 support I think would greatly increase your potential userbase. > In the case the abstractions I need enter on the C++ standard, maybe your > APIbind will help me. I actually would advise you to choose ASIO's STL abstraction machinery over my own alternative APIBind in this instance. > But I just don't find any reference to BOOST_ASIO_HAS_STD_SYSTEM_ERROR > outside of config.hpp. Even if it was used, it is undocumented, which means > it is an implementation detail that won't be guaranteed to be there forever > (accidental behaviour versus a documented guarantee). I'm pretty sure that implementation detail won't change in a hurry. STL abstraction machinery changes as quickly as a STL does i.e. every decade or so. > > https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a7.SAFETY:S > > tronglyconsideranightlyorweeklyinputfuzzautomatedtestifyourlibraryisab > > letoacceptuntrustedinput > > That's why this first implementation uses a proven-parser that is very well > tested. The buck always stops with the top most layer, not internally used third party libraries. You NEED to fuzz test untrusted inputs when parsing HTTP. For all you know, your STL implementation could be the thing with the overflow bug, or the way in which you use it. > > * I don't understand why you cannot issue more than one async read at > > a time nor async write at a time. In something like pipelined HTTP > > that seems like a very common pattern. I smell a potential design > > flaw, and while the docs mention a "queue_socket" I can't see such a > > thing in the reference section. > > > > Too much synchronization and buffering. > > The pipeline has the following requests: > > A => B => C > > If I were to allow replies to request B, the design would be more complex, > increasing the difficult to implement alternative backends and everyone's > life. Also, the reply to request B cannot actually be sent while the reply > to request A is on hold. This means that the whole response to request B > would need buffering and if response B is a video live stream, this means > an implicit (the user cannot know) crash after an unfortunate memory > exhaustion. I couldn't claim a **lightweight** server if this excessive > buffering was to occur. I couldn't claim the project is appropriate for > embedded devices if I had chosen the buffering approach. It's a trade-off. > I should write about it in the "design choice" of the documentation. > > HTTP/2.0 does have proper multiplexing and it can be more useful to respond > several requests without "head of line blocking". Ok, let's accept that HTTP before 2.0 can't multiplex (not my experience personally, but I agree it's got big gotchas before 2.0). You need a user facing API for Http which lets user code multiplex where that is available, and not multiplex when that is not available. In other words, identical code written against Http must automatically be optimal in either connection case. You're probably going to ask how I might implement that right? I think my first guess is you need two completion handler layers and therefore two completion dispatcher reactors: the bottom layer is the same as ASIO's and uses the ASIO reactor, whilst the top layer which users of Http sees is a reactor operated by Http and is disconnected, though operated by, the ASIO reactor. > A queue socket is a concept, I don't provide one. I can look into how make > the documentation less confusing by adding a page exclusively dedicated to > explain the problem it solves. Would that work for you? It could be this queue socket concept of yours is exactly what I just proposed as two completion handler and reactor layers. In either case, I don't think queue sockets should be a concept, I think they need to be the core of your library's user facing API. If power users wish to bypass that user facing API layer for less hand holding and less latency, that should also be possible. But I think HTTP multiplexing should be assumed to be the default starting point for Http applications. Once HTTP 2.0 is more common, it will seem madness that Http's user facing API is _not_ 100% multiplexing. > * Your tutorial examples use "using namespace std;" at global level. > > That's a showstopper of bad practice, and you need to purge all of > > those. Same for "using namespace boost;" at global level. > > > > The tutorials should be as small as possible to not scary the users. > > But I can put a comment "you should avoid using namespace". Does it help? using namespace is fine at local scope. It's not fine at global scope. Replacing all global using namespace with local using namespace is all you need to do. > * Your reference section is one very long thin list. You might want > > to use more horizontal space. > > > > I'd be happy already if I knew hot to remove the TOC from the reference > page. It'd be much more clean already. Personally in AFIO I hack the CSS to make the list into columns. ASIO employs a table. There are many solutions. > * I personally found the design rationale not useful. I specifically > > want to know: > > > > 1. Why did Http choose ASIO as my base over leading competitor X > > and Y? > > 2. What sacrifices occurred due to that choice? i.e. things I'd > > love weren't the case. > > > > I assume I don't need to reply these questions during the review, given the > reviewers may already be experienced on the answers. Well ... I'm not sure that's actually the case. It's not we don't have opinions on the answers, it's whether our answers are different to your answers. You'll see this during the AFIO review later this month - I have some really weird opinions no one else shares like choosing my own custom lightweight monadic future-promise implementation over async_result. That will be the source of much criticism I'm sure. > 3. What alternatives may be better suited for the user examining > > Http for suitability and why? i.e. make your documentation useful to > > people with a problem to solve, not just a howto manual. > > > > I don't quite understand this point. What I'm really asking is for details of when before starting Http you reviewed the options available and the designs they used, and exactly why you chose the design choices in Http you did with reference and comparision to prior art. Like a literature review, but for programming libraries. Does this make sense? It's partially for us to help us understand your choices, but also to help those examining Http to see if it's useful to them to figure out the best solution to their problem (which may be to use an alternative to Http). Documentation which is useful over documentation which is reference. > * Benchmarks, especially latency ones which are important for many > > uses of HTTP are missing. I'd particularly like to know confidence > > intervals on the statistical distribution so I know worst case > > outcomes. > > > > These values will change when I replace the parser used now. Also, they can > change based on the buffer sizes and parser options, which the user is/will > be able to change. > > Nevertheless, I do want to do some serious benchmarking, specially because > it'll give me a reference point when I write my own parser and want to > compare performance speedup. I can do some poor benchmark this weekend and > show the results. That would be interesting, but don't go crazy on it. Also, please do enable the undefined behaviour sanitiser permanently including in release mode and with full stack smashing protection before running benchmarks. Anything parsing malicious input should have all those turned on where available. > I hope all the above isn't too disheartening Vinícius. > > Not at all. I think you're the second person to dedicate more time > reviewing my work and this isn't disheartening at all. Just that your > feedback is usually around tooling and not the design itself (everybody has > its preferences). That's because I like the design a lot and have little bad to say about it. I've also been subscribed to your github since the beginning, and I have been reviewing your code on and off as you wrote it. You're a talented programmer. > > Jamfile for the main library build, > > Consider this done. I won't integrate into Boost without removing CMake > first. This was already partially stated in the Bjorn's announcement (but > somehow implicit, to be fair). I have no problem at all with dual build systems if you're happy keeping both maintained. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6