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

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

[concurrent] Fast, lock-based queue implementation
by David Stone 29 Jul '17

29 Jul '17

I have written a new concurrent queue that has a focus on high throughput. You can check it out here: https://github.com/davidstone/concurrent-queue Some highlights of this queue: * The bulk interface is faster than other queues for many common load patterns * Almost any element type is supported with very few requirements * Supports any number of producers * Supports any number of consumers (although it works best with only one) * Can dynamically grow and shrink in memory as needed * The interface allows for very little undefined behavior: for the most part, as long as your special member functions like move constructors do not reference the queue you are inserting into, you are fine * Interface based on the pattern of moving values in and returning values via return, rather than other queues which use reference output parameters * Header-only * Design should be fairly straightforward to verify for correctness * Compiles warning free with a very high warning level on gcc and clang * Does not have any errors under ubsan, asan, or tsan I would like to submit this for inclusion in Boost if people find it interesting and useful, but first I would like to get some feedback on the design, implementation, documentation, tests, etc. I have tested this exact version on Gentoo Linux under clang 4.0 and gcc 6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future to ensure there have not been any regressions. I have run fundamentally the same queue on Visual Studio 2012 (no longer supported due to C++14 features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server 2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat 7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it is a fairly mature design.

2 4

Proposal for moving Boost to CMake
by David Sankel 27 Jul '17

27 Jul '17

Howdy all, This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback. The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility. * To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this. * There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies. * We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake. I see this progressing with several milestones. 1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed. Although there are many other great ideas floating around (e.g. modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable. One question that is going to come up is "who is going to do all this work?". Once we decide on a direction, I don't foresee a problem making this happen. Between volunteers, the importance this project has for companies, and the Steering Committee reserves, we should have the resources necessary. Another concern is that some authors may resist. Authors have a lot of leeway when it comes to how they maintain their libraries, what conventions they use, and backwards compatibility concerns. However, there are some things that authors need to conform to, such as our current Boost.Build build and testing infrastructure. I liken this to the development of a city: building developers can make their buildings however they want, but the streets, which control transit between buildings, are centrally regulated. Thanks for your consideration. -- David Sankel

29 140

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

09 Jul '17

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

4 14

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

08 Jul '17

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

7 10

[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

[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] Security issue note
by Artyom Beilis 01 Jul '17

01 Jul '17

Looking into parser/body code I noticed: parser: void on_body(boost::optional< std::uint64_t> const& content_length, error_code& ec) { wr_.emplace(m_); wr_->init(content_length, ec); } string_body: void init(boost::optional< std::uint64_t> content_length, error_code& ec) { if(content_length) { if(*content_length > (std::numeric_limits< std::size_t>::max)()) { ec = make_error_code( errc::not_enough_memory); return; } ec.assign(0, ec.category()); body_.reserve(static_cast< std::size_t>(*content_length)); } } Basically I can exhaust the memory of the server and kill it by providing huge content length from several connections and lead to its crash. Reasonable and configurable limit should be provided for content length. Artyom Beilis

2 6

[Beast] Questions Before Review
by Artyom Beilis 01 Jul '17

01 Jul '17

Hello Vinnie Falco, I have several design questions regarding this library before the review. DISCLIMER: My name is Artyom Beilis. I'm the author of CppCMS C++ Web Framework: http://cppcms.com It may seems like it can be in some competition with Beast but I don't see it this way as Beast is too low level library that does not addresses typical problems of developers needing Web API/Site running using C++. CppCMS addresses totally different problems in different way. So there are my design related questions: Header Only Design --------------------------- As somebody who worked with guys who do web development, it was very clear that compilation time is an issue. A simple build of http_server_small.cpp example requires about 6s(!) of compilation time g++ 5.4 http_server_fast.cpp takes 7s In comparison entire message board containing templates code flow SQL and more leads to only 4s - non paralel build. (https://github.com/artyom-beilis/cppcms/tree/master/examples/message_board ) I understand that you work on base of Boost.Asio - which itself has unacceptable compilation times but having for web application development may be serious deal breaker for big projects. Which Leads me to another design Choice Template Meta-programming Based Design instead of classic Object Oriented Design ---------------------------------------------------------------------------------------------------------------- I see that almost every object there is some kind of template object. It almost mimics the API of Boost.Asio which on its way has its limitations. I remember I needed to implement FastCGI over TCP and Unix domain sockets virtually leading to same code besides some initial bind - and it required to create the entire parser using template programming because the socket itself was template object different for UNIX and TCP. I have strong feeling that lots of stuff can actually be done using classic OOP. Example Question: > Can I implement same server code for both SSL and non SSL HTTP protocol > without use of templates in the class itself? And my current final question Who are the potential users of the library? ------------------------------------------------------- If I need to send a simple http request to server it does not seem to do simple enough job (see your FAQ) so I'll probably be better with feature rich libcurl. If I need to implement complex web server/service I don't have cookies, sessions, forms, html? If I need to implement RESTful API do I have all stuff like URL mapping of different paths to callbacks, protocol abstraction http/https (basic stuff - I don't see it there correct me if I wrong) Is it for web server developers? Maybe I'd be happier with simple HTTP protocol parser that I can integrate to any socket API? Can you please give more accurate description of who is this library intended for? Best Regards, Artyom Beilis

5 21

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

01 Jul '17

Due to the strong interest in my previous follow-up, I'm following it up with a more complete implementation of the support required for CMake scenario #1, installing configuration files during "b2 install" such that subsequent "find_package" calls work (assuming a suitably set CMAKE_PREFIX_PATH). You can find it in branch "feature/install-cmake-config" in the superproject (boostorg/boost). In other words, git clone --recursive --depth 64 -b feature/install-cmake-config https://githib.com/boostorg/boost bootstrap b2 headers b2 install cmake//install variant=debug,release link=static,shared runtime-link=static,shared This doesn't yet support installation with more than one toolset, and I'm sure that some libraries don't work, but a simple test using Filesystem and ProgramOptions does. /// CMakeLists.txt: /// cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0) find_package(boost_program_options 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options) /// cmake_demo.cpp: /// #include <boost/filesystem.hpp> #include <boost/program_options.hpp> #include <cerrno> #include <iostream> namespace fs = boost::filesystem; namespace po = boost::program_options; int main( int argc, char const* argv[] ) { po::options_description desc( "Allowed options" ); desc.add_options() ( "help,h", "produce help message" ) ( "path,p", po::value<std::string>(), "set initial path" ) ; po::variables_map vm; try { po::store( po::parse_command_line( argc, argv, desc ), vm ); po::notify( vm ); } catch( std::exception const & x ) { std::cerr << "Error: " << x.what() << std::endl; return 1; } if( vm.count( "help" ) ) { std::cout << desc << std::endl; return 1; } fs::path p = fs::current_path(); if( vm.count( "path" ) ) { p = vm[ "path" ].as<std::string>(); } std::cout << p << std::endl; }

2 1

Does Boost 1.64 support HP-UX?
by 장윤진 30 Jun '17

30 Jun '17

I read about the platform that boost supports on the boost homepage. However, I do not know if it supports HP-UX. http://www.boost.org/doc/libs/1_64_0/libs/log/doc/html/log/installation.htm… Supported compilers and platforms. The library should build and work with a reasonably compliant compiler. The library was successfully built and tested on the following platforms: Windows XP, Windows Vista, Windows 7. MSVC 8.0 SP1, MSVC 9.0 and newer. Linux. GCC 4.5 and newer. Older versions may work too, but it was not tested. Linux. Intel C++ 13.1.0.146 Build 20130121. Linux. Clang 3.2. Does that mean it supports HP-UX?

3 2

Noexcept
by Emil Dotchevski 30 Jun '17

30 Jun '17

The lively debates during the Outcome review show that there is a great deal of interest in solving the problem of error handling in environments where C++ exception handling is unavailable. Noexcept is a new C++11 library that implements a different approach to solving the same problem. Any feedback is welcome. https://zajo.github.io/boost-noexcept/ Emil

12 81

[review] Mp11 review starts in two weeks
by Bjorn Reese 29 Jun '17

29 Jun '17

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

1 0

CMake followup
by Peter Dimov 29 Jun '17

29 Jun '17

In a previous post I identified several scenarios for CMake support, where number one was 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). For this, I said "The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen." but I lied. (Well, not entirely, I had a lot of help.) Here https://github.com/pdimov/boost-cmake-demo is a proof-of-concept implementation that more or less works for our beloved test case of Boost.System. To test (the instructions are for Windows, where I tested), clone the repo, do b2 headers b2 --build-type=complete install as usual, then b2 cmake//install variant=debug,release link=static,shared runtime-link=shared (or whatever combination of options you prefer.) This should install -config.cmake files into $prefix/libs/cmake. Then, in a CMakeLists.txt, cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) #set(BOOST_BUILD_VARIANT RELEASE) #set(BOOST_LINK_TYPE SHARED) #set(BOOST_RUNTIME_LINK STATIC) find_package(boost_core 1.63.0) find_package(boost_system 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::core boost::system) or similar. Ideally, cmake//install would be integrated into the install target (and cmake//stage into stage, respectively.)

1 0

[iterator][utility] Move utility/next_prior.hpp to Iterator module?
by Michel Morin 29 Jun '17

29 Jun '17

Andrzej Krzemienski wrote: >> Do you mean coupling of Boost.Iterator and Boost.Range? I think that would >> be fine, since Boost.Range already couples with Boost.Iterator. >> Boost.Range's `boost::distance` should call Boost.Iterator's >> `boost::distance`. >> > > I meant `next()` and `prior()` that are located in Utility: > http://www.boost.org/doc/libs/1_64_0/libs/utility/utility.htm Ah ok, got it. I think it would be better to move utility/next_prior.hpp to the Boost.Iterator module. After the move, the Boost.Iterator module will have: - include/boost/iterator/next_prior.hpp * Contains the actual code for `next` and `prior`. (Personally, I'd like to add `boost::prev` as a synonym of `boost::prior`.) - include/boost/utility/next_prior.hpp * Just includes <boost/iterator/next_prior.hpp>. This is how utility/declval.hpp was moved to the Boost.TypeTraits module. Regards, Michel

1 0

[beast] Formal "review" branch frozen
by Vinnie Falco 29 Jun '17

29 Jun '17

The "review" branch of Beast is now available and frozen for modifications. It contains the snapshot of the repository which will undergo the Boost formal review starting on July 1 and lasting for 10 days. Currently the review branch is even with the master branch, at version 70. The review branch repository is here: https://github.com/vinniefalco/Beast/tree/review The review documentation snapshot: http://vinniefalco.github.io/stage/beast/review/ Autobahn WebSocket Implementation Test Report: http://vinniefalco.github.io/autobahn/index.html Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocolvocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast empowers users to create their own libraries, clients, and servers using HTTP/1 and WebSocket. Code will be easier and faster to implement, understand, and maintain, because Beast takes care of the low-level protocol details. Please don't forget to "star" the repository on GitHub, the increased exposure will vitalize Beast and Boost with the new generation of programmers! Thanks! -- Follow me on Github: https://github.com/vinniefalco

1 0

Boost MSM attribute sharing problem
by Christophe Henry 28 Jun '17

28 Jun '17

>Hello everyone, > >I have an issue with* Boost MSM*. >Using *Boost MSM eUML* I have created a >state machine. Actually I created *HSM* (Hierarchical State Machine) or >Composite State Machine as second name. >And I faced with issue: How to >share attributes between Parent State Machine and Sub-State Machines >(or Child State Machine) ?? > >I have not found an answer on this question ... >Could anyone possibly help me ? > >*Thanks,* > >*Best RegardsDenis Kotov* Hi Denis, I think the best way is to have your attributes owned by the top-level state machine, then passed to the composite as say, a pointer. The top-level can call get_state, then set the attribute. For example, with eUML, supposing you declared the attribute with BOOST_MSM_EUML_DECLARE_ATTRIBUTE (or without for other front-ends): get_state<Composite&>().get_attribute(some_attribute) = &top_attribute; HTH, Christophe

1 0

Boost.Build and Microsoft C2 clang
by Niall Douglas 28 Jun '17

28 Jun '17

Can someone who has this working right please tell me how they persuaded Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get it to link properly? My GSoC student has tried: - Configuring clang-win, this is a no-go, C2 clang comes in GCC arguments accepting form, not MSVC arguments accepting form. And no there is no clang-cl program supplied by Microsoft. - Configuring mingw gcc but with the C2 clang executable, this compiles code okay but fails at the link stage for some reason, probably it's trying to invoke the mingw linker and we want the Microsoft linker. Any help much appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 17

[thread] Interaction between interruption points and condition_variable
by David Stone 28 Jun '17

28 Jun '17

Assume 1) A thread is waiting on a condition_variable 2) That condition_variable has been notified that its condition is now true 3) The thread has been interrupted Given this, the interruption is processed rather than the condition_variable unblocking normally regardless of the order in which the notify and the interruption occur. That means that this program would eventually fail even though the notify always comes before the interrupt. #include <boost/thread/condition_variable.hpp> #include <boost/thread/lock_types.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/thread.hpp> #include <cassert> struct flag_t { using lock_type = boost::unique_lock<boost::mutex>; void notify() { auto lock = lock_type(m_mutex); m_flag = true; m_cv.notify_one(); } void wait() { auto lock = lock_type(m_mutex); m_cv.wait(lock, [=]{ return m_flag; }); } private: bool m_flag = false; boost::mutex m_mutex; boost::condition_variable m_cv; }; struct test_t { unsigned value = 0; ~test_t() { assert(value != 0); assert(value != 1); assert(value == 2); } }; int main() { while (true) { flag_t flag; test_t test; auto thread = boost::thread([&]{ test.value = 1; boost::this_thread::interruption_requested(); flag.wait(); test.value = 2; }); flag.notify(); thread.interrupt(); thread.join(); } } If we move the `flag.notify()` line before the thread creation, this program never terminates. This is because `boost::condition_variable::wait(lock_type &, function)` is defined as only blocking when the function returns false. The only way this program can terminate is if `thread` begins execution and executes `flag.wait()` before `flag.notify()` is called, then `thread.interrupt()` runs before `thread` is unblocked. It seems more intuitive to me that if a thread is blocked on a condition_variable and it is interrupted that it would unblock normally rather than throwing boost::thread_interrupted. Under that behavior, users who want the current behavior can always check after they leave a condition_variable::wait using `boost::this_thread::interruption_requested()` and throw rather than processing data. Under the current behavior, I do not believe there is any way to process the data in a function that does not have access to the thread object without losing the fact that an interruption was requested. This would only be possible if we had a function like `boost::this_thread::interrupt()`, but that does not exist. I do not know what code (if any) depends on the current behavior of interruptions always taking precedence over notifications, but it appears that the current behavior is undocumented. Is there a justification for the current behavior or is it just the way it happened to be implemented? Is this something we could change, or at least allow users to implement the behavior I outlined?

3 5

Reminder: 1.65 closes for major changes tomorrow
by Marshall Clow 28 Jun '17

28 Jun '17

Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 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

6 12

Testing for ML Admin
by Alexander Zaitsev 28 Jun '17

28 Jun '17

Hello. Â I am simple letter and i want to be a part of boost mailing list. Â Hey, see - i have body. Head and body. Â --Â Best regards, Alexander Zaitsev Â

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev zamazan4ik(a)gmail.com

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev mazahaka2009(a)list.ru

1 0

Interest in another formatting library ?
by Roberto Hinz 27 Jun '17

27 Jun '17

Hi, Is there space for another formatting library in Boost? Anyone interest in this one? doc: https://robhz786.github.io/stringify/doc/html/index.html code: https://github.com/robhz786/stringify

5 11

Cmake
by Peter Dimov 26 Jun '17

26 Jun '17

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios: 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). 2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them. 3. The user uses CMake to install an individual Boost library, which is then available for find_package. 4. The user uses CTest to run the tests of an individual Boost library. 5. CMake is supported as a way to build and install the entire Boost, in place of b2. 6. CTest is supported as a way to run the tests for the entire Boost, in place of b2. At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. 5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works. I've done a proof of concept for (2), which can be seen here: https://github.com/pdimov/boost-cmake-demo-2 This repository uses git submodules in ext/ to bring in Boost.System (our guinea pig) and its dependencies, then uses them via add_subdirectory in https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt The required CMake infrastructure is on branch feature/cmake in those six libraries (assert, config, core, predef, system, winapi.) It consists of CMakeLists.txt in the root: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and supporting .cmake files in cmake/ : https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b6… The goal here is for Boost library developers to be able to remain ignorant of CMake if they so choose; so of those files, only sources.cmake requires their input (it's empty for header-only, so those require nothing at all.) BoostVersion.cmake and default.cmake are common for all libraries and are copied from the superproject. dependencies.cmake is automatically generated with boostdep. There is a Jamfile in cmake/ that updates these three files: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and the intent is for this to be done automatically in a superproject script that invokes "b2 cmake" for the superproject: https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile which in turn invokes "b2 cmake" in each library having "cmake/Jamfile". Copying BoostVersion.cmake and default.cmake, instead of referring to them, allows libraries to be used without a superproject, to support scenarios (2) and (3) above. (Scenario (3) is also supported by default.cmake.) What remains to be done is (a) to extend this to the rest of the Boost libraries, if we decide to do so, which would require figuring out a way to cope with the numeric/ irregular libraries, and (b) support for scenario (1) above. Scenario (1), that is, `b2 install` making the installed Boost available for CMake find_package use, is an entirely separate undertaking, completely independent of what I've done - except for possibly reusing the dependencies.cmake files. It would entail generating boost_libname-config.cmake and boost_libname-config-version.cmake files for each library, and boost_libname-config-<suffix>.cmake subconfiguration files for each build variant (toolset, variant=debug/release, link=static/shared, runtime-link=static/shared, runtime-debugging=on/off, threading=single/multi, and possibly python-debugging=on/off.) This would probably require us to define CMake variables controlling these features, such as BOOST_BUILD_TOOLSET, BOOST_BUILD_VARIANT, BOOST_LINK_TYPE, BOOST_RUNTIME_LINK, and so on, with them having appropriate default values inferred from the CMake environment. Then, boost_system-config-vc141-mt-gd-1_65.cmake will check these values and if BOOST_BUILD_TOOLSET is "vc141", BOOST_LINK_TYPE is SHARED, BOOST_RUNTIME_LINK is SHARED and BOOST_RUNTIME_DEBUGGING is ON, it will declare an imported target pointing to boost_system-vc141-mt-gd-1_65.lib/dll, otherwise it would do nothing. (Not sure how relevant is threading=single/multi today, but in principle, it should also check BOOST_THREADING == MULTI.) Generating these -config.cmake files would ideally be done as part of the `b2 install` procedure and require no changes to the individual libraries. The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen. At this point, I know what needs to be done, but not how to bring it about.

16 67

Re: [boost] What's wrong with top-posting?
by Brian Wood 26 Jun '17

26 Jun '17

David Abrahams writes: > At Tue, 26 Jan 2010 10:09:43 -0800, > Robert Ramey wrote: >> > > I thought I was familiar with the guidelines and never remembered this. >> >> I top-post all the time. It seems much more natural to me when >> it's not convenient to intersperse comments into the previous >> message. Why I like top posting: >> >> a) It means that I don't have to scroll to the bottom of a message >> which is sometimes pretty long. >> b) To me it is more natural to follow the style >> of other communications (artilcle, books, etc) which make >> their point in the main text and refer to footnotes, bibliographies, >> etc at the end of the main text. > > c) You don't confuse or even *upset* (as I've discovered the hard way) > many people in the business world, where top-posting and > overquoting is the accepted standard. Every message drags along > the entire thread history with it, and you keep a record of > everything by storing the final message. (yuck) It's a cultural > thing, and Boost fits into the open-source programmer weenie > culture much more than the business culture. I was getting annoyed by some top-posting here recently, so I dug up this thread. Is an "open-source programmer weenie culture" like a nerdy culture? Anyway, please stop top posting and trim the old parts of the thread that are no longer needed. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3

[outcome v2] Please comment on new result<T, EC> reference API docs
by Niall Douglas 26 Jun '17

26 Jun '17

Dear Boost, I've been hard at work refactoring Outcome to match the peer review a few weeks ago. Much comment at the time mentioned the poor experience of the reference API docs, so can I get a community check of this: https://dedi4.nedprod.com/static/result-v2/doc_result.html This was generated by the new C++ reference docs generator https://github.com/foonathan/standardese. You'll no doubt spot quite a few formatting bugs, Jonathan says he's onto them. But the usage of libclang rather than doxygen's broken C++ parser clearly shows a lot of benefit, it's just standardese still remains quite a lot short in terms of necessary features to make output fully correct. I won't give the changelog for Outcome v2 result<T> over Outcome v1 yet. Let's see how you fare with the above reference API docs first. But as you'll note, there is considerable change over before as we now slot into a niche not occupied by Expected nor EitherMonad, indeed this now looks much more like Robert's or Lawrence Crowl's slimmed down object. This result<T> is approx 0.6 CPU cycles per stack frame unwound slower which I feel is acceptable in exchange for no more variant storage, which in turn released lots of SFINAE budget for me. (FYI v2 outcome<T> isn't done yet, but it will extend v2 result<T>) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 31

[container] includes nonexistent file
by Peter Dimov 25 Jun '17

25 Jun '17

Primary dependencies for container: (unknown): <boost/intrusive/detail/to_raw_pointer.hpp> from <boost/container/detail/to_raw_pointer.hpp> Boostdep says that <boost/intrusive/detail/to_raw_pointer.hpp> doesn't exist, and I indeed don't see it.

2 1

[program_options] behaviour change for implicit options
by Vladimir Prus 25 Jun '17

25 Jun '17

Hi, I have committed, and merged to master, a change making program_option consider subsequent tokens for values of implicit options. For example, if "foo" is implicit option and "bar" is some other option, then: 1. "--foo --bar" will be parsed as option "foo" followed by "bar", and implicit option for "foo" will be used. 2. "--foo bar" will be parsed as option "foo" with the value of "bar" This is the way things worked prior to 1.59, was changed in 1.59, continued to cause confusion, and is now reverted back. For background, see: - http://permalink.gmane.org/gmane.comp.lib.boost.devel/269832 - https://github.com/boostorg/program_options/issues/25 Just in case client code might need to check this behaviour, I've added a feature macro, BOOST_PROGRAM_OPTIONS_IMPLICIT_VALUE_NEXT_TOKEN, which will be set to 1 starting with 1.65. Thanks, Volodya

1 0

Boost MSM attribute sharing problem
by Denis Kotov 25 Jun '17

25 Jun '17

Hello everyone, I have an issue with* Boost MSM*. Using *Boost MSM eUML* I have created a state machine. Actually I created *HSM* (Hierarchical State Machine) or Composite State Machine as second name. And I faced with issue: How to share attributes between Parent State Machine and Sub-State Machines (or Child State Machine) ?? I have not found an answer on this question ... Could anyone possibly help me ? *Thanks,* *Best RegardsDenis Kotov*

1 0

Noexcept improvements
by Emil Dotchevski 25 Jun '17

25 Jun '17

I've completed a second iteration on Noexcept, incorporating valuable feedback from the previous discussions here, and I'd like to thank everyone who participated. https://zajo.github.io/boost-noexcept/ The new result<T> type has a hard value-or-error invariant and can be used to transport errors between threads or to temporarily postpone the consumption of function results, e.g. by storing result<T> objects into a queue (of course, as before, users do not need result<T> just to report a failure from a function.) There is also a new macro, BOOST_NOEXCEPT_CHECK, which makes writing error-neutral functions easier and improves error checking in general. The documentation is also much more complete, including better examples and a new section on programming techniques.

1 0

Fw: [stacktrace] [winapi] header out of place
by Peter Dimov 24 Jun '17

24 Jun '17

The header stacktrace: boost/detail/winapi/capture_stack.hpp should probably either be moved to Winapi, as the name suggests, or renamed to reside in boost/stacktrace/detail. And, as a general rule, libraries should strive to keep their headers under boost/<libname>, with the only exception being boost/<libname>.hpp. We have many legacy libraries not following this requirement, but any new ones and any new headers added to existing ones should. The reason for this requirement is that otherwise it's impossible to perform dependency analysis unless all of Boost is checked out so that the tool can tell in what module boost/random-header-name.hpp resides.

3 2

[review] Boost.Nowide is Accepted into Boost
by Frédéric Bron 24 Jun '17

24 Jun '17

Dear all, I would like to thank all the people who took part in the discussions during the review. All contributors admitted that Boost.Nowide addresses a real issue and solves it, at least partially. Moreover we received 8 official reviews with 6 “accept”, 1 “do not accept as is” and 1 “I am not against it”. So Boost.Nowide is accepted for inclusion in Boost. Congratulation and many thanks to Artyom Beilis for this contribution. However, 2 major issues arose in the discussions and they will have to be fixed before inclusion: 1. handling of ill-formed Unicode input should be improved/clarified 2. the documentation needs improvements In particular, this needs to be fixed: * Design: There was a lot of discussions on what to do with ill-formed UTF-16 strings on Windows, in particular coming from the file system while converting them to narrow UTF-8 strings. Basically, 3 options: 1. allow the roundtrip ill formed UTF-16 > UTF-8 > ill formed UTF-16, this is not possible with UTF-8 encoding, WTF-8 (not a standard) may be an option with some issues 2. issue an error (today’s nowide option, even if the author would like to move to 3.) 3. convert as much as possible to fully conformant UTF-8 with character replacement U+FFFD for invalid input. This is what the NT kernel does with functions like RtlUTF8ToUnicodeN. This would allow cout to continue to work after invalid output instead of failing. After reviewing what was chosen for std::filesystem in C++17, I think 3. is the right think to do: - std::filesystem::path::u8string does not convert strings on Posix. If a conversion is done (on Windows) the output is fully conformant UTF-8. - the roundtrip is not guaranteed in std::filesystem::path conversions (implementation defined) but the roundtrip of a converted paths is guaranteed to work which is the case with Boost.Nowide: once in fully conformant UTF-8, narrow > wide > narrow works fine. - the use of the replacement character U+FFFD is what is done by the NT kernel (question: do you have to reimplement RtlUTF8ToUnicodeN and RtlUnicodeToUTF8N, why not using them)? It should been made clear in the doc that this choice does not guarantees the roundtrip on Windows so that ill-formed filename may not be opened. * Documentation: - the main part of the doc (the non-reference part) should be more detailed - it should be clear to the reader that Windows and Posix platforms are not handled the same; on Windows, we get UTF-8 strings while on Posix platforms, the user should not expect UTF-8 encoding, just narrow strings, even if UTF-8 is today the most common encoding (addressed in Q/A but is probably too far away). It must be clear from the beginning that on Posix platforms, the library does nothing (including no checking of UTF-8 conformance), just forward to the standard library. - review the use of UTF-8 so that it do not let think that narrow strings are always UTF-8 as this is not necessary the case on Posix platform; maybe just use narrow string? - clarify what is converted to what and when: for each function, we need to know precisely what is the output for all possible input; in particular, better explain for each function what the library does with ill-formed input (either UTF-16 input or narrow input), in particular for args and getenv; say clearly what happens (failbit, error, exception, invalid character…) - clarify what is done for Windows and what is (not) done for Posix - explain better what is behind nowide::cout, cin, cerr, what is done? - clarify what does the filesystem integration on Windows vs Posix - check if basic_stackstring::swap needs to swap buffer_ when both strings are on the stack - The doc/ directory is missing a Jamfile, and there's also no meta/libraries.json. * Implementation: - The global BOOST_USE_WINDOWS_H macro should probably be respected. When windows.h is not used, the WinAPI prototypes are declared in the global namespace. This can cause issues when windows.h is also included before/after the Nowide headers, and the prototypes don't match exactly (e.g. short vs. wchar_t). Also it pollutes the global namespace. Nowide should do what other Boost libraries do, and declare the prototypes in a private detail namespace instead. Example in <boost/thread/win32/thread_primitives.hpp>. Need to add a namespace around your definitions. - MinGW gcc: fix warnings in c++03 mode and errors in c++11 and above - Cygwin gcc/clang (errors because of missing ::getenv and friends) - when this is fixed, an error remains: in file included from test\test_system.cpp:11:0: ..\../boost/nowide/cenv.hpp: In function 'int boost::nowide::putenv(char*)': ..\../boost/nowide/cenv.hpp:104:41: warning: comparison between pointer and zero character constant [-Wpointer-compare] while(*key_end!='=' && key_end!='\0') - Under MSYS, one test failed Fail: Error boost::nowide::cin.putback(c) in test_iostream.cpp:17 main - filesystem integration should return somehow the previous locale for potential undoing * Misc: - There are no .travis.yml and appveyor.yml files in the root. - a number of copy/paste references to Boost.System (test/Jamfile) and Boost.Locale (index.html), should be corrected This are just suggestions and are not mandatory for acceptance: - implement stat/opendir/readir - integration with boost::interprocess::file_lock - integration with boost::program_options (in particular for correct line breaks when showing options) Frédéric

3 4

Re: [boost] [review] Review of Nowide (Unicode)
by Groke, Paul 23 Jun '17

23 Jun '17

Hi, this is my official review of the Nowide library. I haven't had much time to look at Nowide, but I have noticed some things that might be of interest, so here we go... > - What is your evaluation of the design? Overall the design looks good. Some things I'd suggest to reconsider: * I'm a big fan of "try" names, so I'd suggest to rename the array versions of widen/narrow to try_widen/try_narrow. Makes it more clear that they can fail without throwing. Also I'm not sure about the benefit of returning the output buffer pointer or NULL. I'd simply return bool instead. * nowide_filesystem... to be honest I'm not sure what this does. If it does something related to UTF-8 on POSIX systems, then I smell a potential problem. If it's only for wide->narrow on Windows, it should be OK. * Also not sure what boost::nowide::cin/cout/cerr do. Do they call SetConsoleCP/SetConsoleOutputCP? Will they work with re-directed input/output streams? What will happen if the user uses them AND std::cin/cout/cerr or stdin/stdout/stderr in the same application? * I'm not a big fan of the basic_stackstring classes. I'd suggest to provide template function overloads for narrow/widen instead. Like: users_favorite::wstring_class wstr; if (boost::nowide::try_widen(wstr, str)) use(wstr); else too_bad(); They could write to the target-string using the usual duck-typing - e.g. via clear/push_back or clear/back_inserter. That way the user can use whatever SSO string class he likes and Nowide wouldn't have to provide string classes -- which IMO isn't its job. As a bonus, the user also gets an exception-free (except bad_alloc) function that doesn't require him to provide a raw array output buffer. * The Windows & invalid UTF-16 thing... I still think invalid UTF-16 should round-trip. > - What is your evaluation of the implementation? Haven't had much time to check the implementation. What I did notice is that when windows.h is not used, the WinAPI prototypes are declared in the global namespace. This can cause issues when windows.h is also included before/after the Nowide headers, and the prototypes don't match exactly (e.g. short vs. wchar_t). Also it pollutes the global namespace. I think Nowide should do what other Boost libraries do, and declare the prototypes in a private detail namespace instead. > - What is your evaluation of the documentation? Incomplete. Too few examples and the reference documentation leaves many things unclear. IMO the reference documentation should unequivocally define the contract of each API. Also I think the documentation should make it very clear what Nowide does and doesn't do on different platforms. Especially that it doesn't do anything Unicode-related on POSIX platforms and that using it does NOT mean the application will only have to deal with UTF-8 strings on POSIX platforms. Also parts of the documentation that suggest or even _state_ that systems like Linux internally use UTF-8 should be fixed. > - What is your evaluation of the potential usefulness of the library? I'd say it's useful. > - Did you try to use the library? With what compiler? Did you have any > problems? No. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Quick reading of the documentation + some very quick glances at parts of the implementation. > - Are you knowledgeable about the problem domain? More or less. I have never used or written a "nowide" layer myself, but I have spent plenty of time "widening" Windows-only applications. > And most importantly: > - Do you think the library should be accepted as a Boost library? Be sure to > say this explicitly so that your other comments don't obscure your overall > opinion. I certainly wouldn't vote against it. I didn't spend enough time to understand every aspect of it though, so I don't feel qualified to vote for it either. I would however suggest to require a major update of the documentation before accepting it. Regards, Paul Groke

4 12

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 23 Jun '17

23 Jun '17

Am 20.06.2017 5:08 nachm. schrieb "Niall Douglas via Boost" < boost(a)lists.boost.org>: >> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and >> that explicit targets are preferred nowadays. > > Niall, can you point me to a reference stating this? Preferably some cmake > documentation telling me what the right(tm) thing to do is. Any cmake construct which requires you to write an if() in a non-root-level CMakeLists is a cmake2-ism. There are a very few places in cmake3 remaining where no good alternative to global variables exist. BUILD_SHARED_LIBS is definitely not one of those. I'll ask again: do you have any reference to those statements? The official cmake docs seem to disagree about this specific case. I would even call it non sensical alltogether. Why should the root cmake be responsible for configuring a specific sub module. This is asking for cluttering everything into one single entity in a (almost) totally unrelated place. Why not keep it local to where it should be used. One concrete example: I have networking layer which supports different transports, say tcp, libfabric, MPI and infiniband verbs. The user of my library doesn't really care about which one is used, so ideally, I would give him a compiled version of my library with the internal settings I believe are best for him. In that case, my network layer module would be configured with one of those options. Naturally, I would think, those options are defined within this very sub project. The root project really doesn't care, nor do I want that this implementation detail leaks into the users CMakeLists.txt. Would you consider that bad practice to begin with? How would you solve this? There are tons of other use cases very similar to that. Having everything clobbering up in the root Cmakelists.txt doesn't sound appealing to me. Shared libraries usually have different settings to static libs and again to header only libs. They have different relationships to their dependencies, different usage requirements for consumers. You can use generator expressions to encode those differences, but then you've hard coded them so external cmake no longer can easily override them. You have just made your non-root CMakeLists hard to reuse by cmake you didn't write nor design. Generator expressions are also hard to write and debug, are overwhelmingly confusing to read, and randomly don't work in some places depending on which build system generator you are using. So best avoid all of that complexity - place no complexity at all outside the rootlevel CMakeLists. Declaration only. Place all custom logic solely in rootlevel CMakeLists only. > Any definite source on what a cmake2ism is or is not would be highly > appreciated. > > > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. I believe Stephen Kelly is negotiating a book deal on this. It'll be some time before that book lands though. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

13 42

[build] Use address-model in library filenames
by Vinnie Falco 23 Jun '17

23 Jun '17

Please add the address-model (32 or 64) into the encoded name which describes a library, so that 32-bit and 64-bit libraries may reside in the same dir. I'd like to avoid a lengthy debate, and if no one wants to do it just provide me with working code for accomplishing it and I'll submit a pull request. -- Follow me on Github: https://github.com/vinniefalco

5 4

Outcome/expected/etc/etc/etc
by Gottlob Frege 22 Jun '17

22 Jun '17

I've now read ALL the emails. Here's some thoughts, in no particular order. - I wonder, Niall, if your uses of the empty state could/should be compared to how people sometimes use -1 or 0, etc - ie "special values as errors". I typically don't like that pattern (yet I've done it anyhow - performance/laziness/etc - but typically only in localized cases, not in "APIs"). So I'm wary about this empty state thing. If we do have an empty state, I like it as a separate type - code needs to deal with it separately. I like the idea of taking a possibly-empty type, checking for empty, and creating a never-empty type, and passing that along so future code need not worry. - I think the narrow and wide contracts should be in the same type, not separate types. This is C++. I suggest "access" if you want long names. ie T & val = oc.access_value(); // possible UB (I almost also suggested "deref" but "deref_value" is wrong - you are deref'ing the outcome, not the value) - I agree with Vicente's concern that functions that behave differently need to be named differently. I haven't looked at the new (or old) API carefully enough, but as a (possibly hypothetical) example: wide_type::value() // returns value, or throw if no value narrow_type::value() // returns value, or UB if no value These functions are not the same, and should not be named the same. Since you thus need different names anyhow (ie value and access_value), why not put them both on the same API? I'm not yet sure if you end up with similar examples with possibly_empty_type::something() and never_empty_type::something(). - I see value in the idea that the narrow contract takes more typing, but I actually *like* using * and -> for the narrow contract because I have 30+ years of training in looking at * and -> and recognizing it as "this may be unsafe, examine the code to see how it is guaranteed". Boost.Optional specifically chose * for that very reason. (on the other hand, I have 0 training on spotting access_value(), but on the third hand, it is easy to grep for) - exception() returns error, error() doesn't return exception, etc: would it be better/easier/clearer if we introduced another name, such as "failure" or whatever? ie exception() only returns the stored exception, error() only returns the stored error(), and then has_failure() would return true in either case, failure_exception() returns exception, generates an exception from error if necessary, etc? - I dislike "exceptions are for exceptional circumstances". Yes it is a common thing, but it is usually wrong. Using Outcome to enable the pattern of "handle errors, but totally cancel the operation on exceptions" might actually turn out to be a useful pattern, but I think this is actually slightly different from the "exceptions are for exceptional cases" camp, as they typically use that chant to choose whether their API will use exceptions or errors, not both in a single API. So I agree with Emil - for most APIs, error-codes vs exceptions" is basically trying to handle the same thing - failure (or "disappointment"). Using both error-codes and exceptions in a single API is somewhat new. And interesting. (There is lots of code that almost-unknowingly uses error-codes and exceptions in the same API, but that is because they don't realize push_back throws or they pretend it doesn't, etc - it isn't really an API design choice) - this ring buffer thing sounds interesting. I haven't looked at it at all, so maybe this makes no sense: should it use thread-local? - I think std::expected should always throw something deriving from std::exception. So if E derives from std::exception, we can throw it. If E is exception_ptr we can (re)throw it. If E is error_code/system_error/etc we can figure out what to throw. If E is user-type, then we wrap it in bad_expected or whatever. (And/or allow user E-to-exception customization somehow). This sounds complicated, but it is easily summarized/taught as "the standard always throws std::exceptions" - I HATE the dual interface of std::filesystem. Worse, there is a chance it is setting a precedent for future std APIs (dual APIs have been proposed elsewhere). Let's please kill it before a dual API strikes again. However, the other problem with trying to "single-fy" the std::filesystem (or any other) API is that users who want error codes sometimes don't want the cost of the extra data (paths, etc). The only way to handle that may be with customizable callback functions that capture the error-info however you like, or something similar to callbacks. - I really look forward to Peter's never-empty variant - and have been hoping for one ever since std::variant was finalized. Not because I dislike std::variant, but just because I think the option should be there for those who need/want it. Regardless, std::variant, in my world, is never empty, since it is only empty when a move operator throws, which should be never and/or when I can't allocate 64 bytes, in which case I'm screwed anyhow. Some days I'm like "man just accept empty, it would be a simple API", but then I think "it is stupid for variant<int, double> to be empty". Other days I think "just double buffer when necessary" (I assume that's your direction Peter?), but then I think "I don't want double-buffering variant<list, vector> to go on/off based on whether I use MS std vs libc++ etc" and also "I don't want double buffering for cases that only happen in theory, not in practice". I like the trade-offs of std::variant. I do agree that Boost should have a variant2 with different choices than std::variant - I think that actually helps the standard - we can choose a direction and instead of telling people "tough luck" when they disagree, we can say "use boost variant2 when you want those properties". - Andrzej: > Actually, now I am thinking not about Boost.Outcome but specifying these > preconditions in the Standard. If you want to std::terminate upon some > condition rather than let the program do random things, you could say. > > *Requires:* `!r` with rescue action `std::terminate()`. This sounds a bit like the contracts proposal - where you get to define what happens when contracts are broken. I'm cautiously hopeful that contracts could help with LEWG's constant struggles with wide vs narrow. - I agree with those who were saying (or thinking) that Boost was - and should again be - the place where APIs go before going into the standard. APIs (mostly) shouldn't bypass boost and go to the standard directly. Or at least an API needs a similar user-base (both in scale and diversity - ie an internal google API has scale, but not necessarily diversity). Since I know a number of LEWG members agree with me on this, don't be surprised to see some push-back from the committee for proposals without that kind of backing, and also don't be surprised if Boost gets flooded with "the committee told me to come here first". Of course I don't speak for LEWG, so maybe none of that happens, we haven't had that discussion yet. I actually probably had more to say - I should have made notes as I was reading all... those... emails. Tony

10 75

[review] Review of Nowide (Unicode) starts today
by Frédéric Bron 22 Jun '17

22 Jun '17

Hi Everyone, The formal review of Artyom Beilis' Nowide library starts today and will last until Wed. 21st of June. Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

11 70

[cmake] Minimum viable cmakeification for Boost
by Niall Douglas 22 Jun '17

22 Jun '17

I've finished the mockup which can be studied at: https://github.com/ned14/boost-bmv-cmake Just Boost.System was cmakeified. Extensive comments are throughout to explain every single line of cmake and why it's there. A small sample program is in the root of the repo to show how this cmake would be used by end user programs. Readme.md follows for those who don't like clicking on links: --- cut --- This is a mock up of a **bare minimum viable** cmakeification of the Boost C++ libraries for the community to study and evaluate. It only cmakeifies Boost.System alone, its upstream dependencies are stubbed/faked. A demo program which shows how one would link against Boost.System is in this directory (`example_client_program`) and it demos linking against boost::system as a header only library, as a static library and as a shared library. # Specific design goals of this mock up: - Modern, **highly reusable by unknown third party cmake** cmake3 only throughout. - Minimum possible cmake complexity, no cmake innovating, even at the cost of extra boilerplate. - No custom macros, functions, nor custom build logic. Only vanilla cmake3. Keep the learning curve for the build system as gentle as is possible. - **Strict** separation of non-fixed configuration and build. Child CMakeLists must only EVER define build and *fixed* configuration like "I need C++ 11 minimum". *Variable* configuration like naming, directory layout for outputs, optimisation flags etc is ALWAYS defined in the **rootmost** CMakeLists. NEVER in child CMakeLists. - All custom build logic should always be placed in rootlevel cmake scripts (command line programs written in cmake, runnable using `cmake -V`, these can take args etc) or rootlevel CMakeLists, or combinations thereof. # Stuff in there we might yet remove: - This cmake mockup explicitly documents dependencies between Boost libraries in cmake, and so when I link against say Boost.System, cmake will also link in the things Boost.System depends against. Moreover this is minimal, so ONLY the stuff minimally necessary to fulfil the need for Boost.System is built. - We allow those Boost libraries support it to present header only, static and dynamic linkage editions of themselves. This does complicate the CMakeLists however. # What we don't do: - Test the boundaries of cmake or push any limits of what's possible. - Bespoke libraries of common functions dragged in wherever. - Complex custom build logic which needs to be documented and learned off by library developers. - Do anything which gets in the way of CMakeLists reuse by any arbitrary third party cmake written by any Boost user. --- cut --- The code should be fairly self explanatory. Yes there are no tests support. We are limiting the scope of discussion to build only for now. Technical questions are welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 50

[review] Beast review coming up!
by Michael Caisse 22 Jun '17

22 Jun '17

The Boost formal review of Vinnie Falco’s Beast library will take place July 1 - 10, 2017. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. This library will be familiar to programmers that have used Boost.Asio or the Networking TS. Users who wish to use asynchronous interfaces should already know how to create concurrent network programs using callbacks or coroutines. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction. Components are well-suited for building upon. Beast can be found here: * Documentation : <http://vinniefalco.github.io/beast/> * Source code : <https://github.com/vinniefalco/Beast> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/beast/beast/design_choices/faq.html> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> If you find an obvious bug or problem with the library, please open a GitHub Issue <https://github.com/vinniefalco/Beast/issues>. Vinnie has a track record of resolving issues quickly. Please feel free to take an early look at the library and ask questions. Maybe even click that github Star button! The actual review will be against a non-mutating branch starting July 1st. -- Michael Caisse Ciere Consulting ciere.com

2 1

[build] Use full compiler-version in library filenames
by Deniz Bahadir 22 Jun '17

22 Jun '17

Hi list, While reading Vinnie's mail (regarding the Boost library filenames which should additionally contain the address-model) I remembered another problem existing with library filenames. That is, that Boost libraries built with newer GCC versions (since GCC 5) never add the compiler-version into the library filenames. Building with GCC 5 and newer only adds "gcc" into the filename to determine the toolset, while building with earlier versions of GCC (e.g. GCC 4.9 or GCC 4.8) additionally adds the compiler's version (e.g. "gcc49" or "gcc48"). I assume this might be due to the fact that the version-scheme of GCC changed since GCC 5 and somehow the logic in Boost.Build no longer works because of this. But in order to install boost-libraries built by different GCC versions side-by-side in the same directory the version-number is really required in the filename. Maybe someone can fix this again? A bug-report on Github which addresses this issue already exists: https://github.com/boostorg/build/issues/191 Thanks in advance, Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Stephan Schröder Board of Management: Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 1

[review] Review of Nowide has finished
by Frédéric Bron 22 Jun '17

22 Jun '17

Thanks for you interest and the discussion. Please be patient, it will take a few days for me to compile all the discussions and give the result of the review. Kind regards, Frédéric

1 0

1.65 closes for new libraries and breaking changes this Friday
by Marshall Clow 22 Jun '17

22 Jun '17

[ The calendar says today, but I forgot to send this out, so we're pushing the deadline back two days. ] Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 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

1 0

Re: [boost] [review] Review of Nowide (Unicode)
by Yakov Galka 21 Jun '17

21 Jun '17

Dear all, Here is my review of the library. - What is your evaluation of the design? > I welcome the UTF-8 approach on Window. However, the fact that Nowide does not handle invalid UTF-16 transparently is an issue that has to be addressed. - What is your evaluation of the implementation? > Going through the code I can't spot any implementation issues. > - What is your evaluation of the documentation? > It's clear. No issues found. > - What is your evaluation of the potential usefulness of the library? > I already use this approach through a different implementation. Even though I wouldn't bring Boost just for that single library, for projects that already use Boost it might be a valuable addition. I do think that Nowide offers a superior solution to encoding issues compared to Boost.Filesystem. > - Did you try to use the library? With what compiler? Did you have any > problems? > I did try it years ago when it was first submitted to Boost. I didn't try the recent version, so NO. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > 30 minutes reading the code + mailing list discussions. > - Are you knowledgeable about the problem domain? > I rate myself as an expert. I'm a co-author of utf8everywhere.org. DISCLAIMER: I met Artyom a couple times IRL. > - Do you think the library should be accepted as a Boost library? Be > sure to say this explicitly so that your other comments don't obscure > your overall opinion. > Conditional acceptance, subject to transparent invalid UTF-16 resolution. -- Yakov Galka http://stannum.co.il/

4 3

[review] Last day to send your review of Nowide (Unicode)
by Frédéric Bron 21 Jun '17

21 Jun '17

Dear all, This is the last day to submit your review of Artyom Beilis' Nowide library. So far, 12 people participated to the review (not counting the author and the review manager): - Andrzej Krzemienski - Chris Glover - Degski - Edward Diener - Gavin Lambert - Niall Douglas - Norbert Wenzel - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 8 reviews where received including * 6 reviews said nowide should be accepted (with conditions): - Degski, - Peter Dimov - Andrzej Krzemienski - Chris Glover - Norbert Wenzel - Yakov Galka * 1 review did not choose between accept/do not accept: - Paul Groke * 1 review said nowide should not be accepted as is: - Zach Laine Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

[sort] Timsort review result
by Steven Ross 21 Jun '17

21 Jun '17

After reviewing the responses, I have rejected Timsort. Here are the reasons: 1. No author/maintainer responses to the questions on boost (except for forwarding some documentation links). We need a maintainer for all our source, and I'm not volunteering to maintain new functions as complex as Timsort. 2. There was no response on the Timsort bug reported during the review, nor any tests for it. 3. We need better tests. 4. Francisco is including a more efficient stable sort as part of his additions to the library, including handling special cases like Timsort handles better than stable_sort does. Francisco will maintain his code. I'd like to note that many people THINK they are experts on sorting because they covered it in class or may have read about it in a textbook, but most do not understand hybrid sorts well. As a specific example, I saw O(N*log(N)) mentioned as the worst-case speed limit of general-case sorts, when in fact Spreadsort beats that as described in its docs: http://www.boost.org/doc/libs/1_61_0/libs/sort/doc/html/index.html#sort.ove… Many people also don't carefully analyze for worst-case performance, which can be tricky. With regards to future sorting library reviews, I'll get at least a one-page doc describing the algorithm for the review in advance, but the boost documentation formatting is an unreasonable request for a simple sorting function, and I don't see the value it adds for these simple reviews. It is useful for a full library, but we'll be integrating the documentation into our full library after a new function is accepted. It isn't accurate to call it a mini-review (as described here: http://www.boost.org/community/reviews.html#Fast-Track) because it's reviewing completely new source we're talking about adding to the library. That said, do you still want me to a call the upcoming one for pdqsort a "mini-review"?

3 3

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 2:17 nachm. schrieb "Niall Douglas via Boost" < boost(a)lists.boost.org>: On 20/06/2017 07:27, P F wrote: > >> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost >> <boost(a)lists.boost.org> wrote: >> >> I've finished the mockup which can be studied at: >> >> https://github.com/ned14/boost-bmv-cmake >> >> Just Boost.System was cmakeified. Extensive comments are throughout >> to explain every single line of cmake and why it's there. A small >> sample program is in the root of the repo to show how this cmake >> would be used by end user programs. > > Here some feedback, I have: > > - Having things like `::hl` or `::sl` is quite strange. In cmake, I > set `BUILD_SHARED_LIBS=On` when I want a shared library or I set it > to `BUILD_SHARED_LIBS=Off` when I want a static library. There should > only be one target `boost::config` or `boost::system` that I use. BUILD_SHARED_LIBS is a cmake2-ism and should not be present in modern cmake. Moreover, cmake now supports header only libraries, and BUILD_SHARED_LIBS causes problems with eventual C++ Modules support. The ::hl suffix means "link against the header only library edition", the ::sl suffix means "link against the static library edition" and the ::dl suffix means "link against the dynamic library edition". Err, I tend to highly disagree here. As a library author, I can not know if my users need a static or shared library. For a header only library, this hardly matters. Having those different conventions greatly increases the complexity for consuming your library (which do I need again in which circumstances?) so we need to depend on variables to link against the right target (so much for cmake2isms). Some bikeshedding over those names occurred off list. They don't hugely matter, they could be boost::system::header, boost::system::static and boost::system::shared if you wanted. Some bikeshedding also occurred over what boost::system with no suffix should mean. I recommend "whatever library edition the maintainer recommends as the best one" which is NOT necessarily the header only edition. For example, in the future with C++ Modules support the additional suffixs ::hlm, ::slm and ::dlm will be needed. Or longer named, boost::system::header_module, boost::system::static_module and boost::system::shared_module. So if C++ Modules were available, the maintainer might recommend the ::dlm variety, but recommend the ::hl variety if they weren't available. I think that will hugely vary per library as C++ Modules won't necessarily be always a win. Also, end users may wish to assemble all of Boost into a single C++ Module. We don't want to get in the way. > - Each project do things like > `include("${CMAKE_CURRENT_SOURCE_DIR}/../../cmake/BoostVersion.cmake”)` > which is broken when built on its own. That was intentional. Some bikeshedding occurred over that too with respect to which Boost library guaranteed to be a dependency for all other libraries ought to host the version setting script. Boost.Config is most likely. So the above is a placeholder. > - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does > not have to exists to be able to link against it. Plus, it should > call `find_package(boost_assert)` to bring in the target for when its > not built in the superproject. That part is there solely to enable modular build. If you don't want to bother with modular build as this is a bare minimum viable cmakeification, you can eliminate it. > - There is no installation of the targets Not necessary right now, so out of scope. > - Doing `target_include_directories(boost_core-hl INTERFACE > "include”)` is wrong as this will only add the include directories > for the build. The include directories should be added for the build > and for the installation. As I've repeatedly explained now, installation logic is best implemented by a rootmost CMakeLists. Not in the per-library CMakeLists. We do tell cmake what targets are used by installation via install(TARGETS ...). That's the bare minimum needed for other cmake to implement the remaining installation logic. (On wider picture stuff, install paths need to be absolute I've found, whereas build paths can usually be relative. Relative paths are much nicer during build. In a rootmost CMakeLists which implements some installation logic, you'd iterate the targets for the Boost libraries and configure each programmatically for the appropriate install for that library and that type of library. All the metadata you need to make decisions is available) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 5