October 2017 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

[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

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

MSVC 15.5 support
by Olaf van der Spek 05 Dec '17

05 Dec '17

Hi, 15.5 Preview has been released: https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-v… > Unknown compiler version - please run the configure tests and report the results How do I do this? Could this message be updated to indicate it comes from Boost? Gr, -- Olaf

4 7

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

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

[devector] optimum growing/insertion policy
by Joaquin M López Muñoz 08 Nov '17

08 Nov '17

Hi, Much an worthy discussion has taken place with respect to growing and insertion policies of boost::double_ended::devector. I think I can justify what the optimum policy is when the overall goal is to minimize number of element movements. What follows is *not* a formal optimality proof, though it's my hunch one could be provided relatively easily. Assumptions * The cost of allocating new memory is negligible when compared to the cost of moving elements around (either intra-buffer or when migrating to a new buffer); so, the growing/insertion policy should focus on minimizing number of elements moved. This implies fully occupying free space before reallocation is *not* the primary goal of the growing/insertion policy. * For the purposes of our discussion, we consider an ever-growing devector without intervening erasures --erasures can be accomodated later as we will see. * Element insertion is modelled as a process where each new insertion happens at a random position within the current devector. The minimal characterization (i.e. its 1st moment in stochastic process theory terminology) is just the percentage R of insertions that happen within the right half of the devector --we call these *right insertions*; left insertions happen then with a frequency L=1-R. push_back is a right insertion, push_front a left insertion. Facts * When a right insertion arrives, if there's free back capacity the optimum insertion policy is to shift elements to the right, as this involves fewer movements than the other way around. The symmetrical applies for left insertions. * If a right insertion at position N arrives and there's no free back capacity (but there is free front capacity), we have only two options: A. Reallocate to get back free capacity. B. Shift elements to the left. The key observation here is that A is cheaper in the long run: as the scenario is one of an ever-growing sequence, reallocation will happen eventually and we can just amortize it in our analysis, so reallocating early saves us the extra movements incurred when left shifting on a right insertion, namely N - (size()-N) = 2*N - size() movements. In fact, we save more than that as insertion is done simultaneously with reallocation, hence no shifting occurs additionally to the (amortized) reallocation cost. All this analysis applies symmetrically to left insertions, of course. * The optimum growing policy is that which maximizes the probability that *both* front and back free capacities get exhausted at the same time. With our 1st moment characterization of the insertion random process, this implies that when reallocating a percentage R of the new space should be devoted to the right side, and a percentage L to the left side. Description of resulting policy * Fix the growing factor to G (this can be 1.5 or 2 or anything greater than one, the actual figure is orthogonal to the discussion). * Maintain a counter right_ of right insertions that gets incremented when a right insertion occurs and *decremented* when an erasure is issued past the middle of the devector. * Right insertions trigger right shifting except when there's no back free capacity, in which case a reallocation is performed. * Left insertions trigger left shifting except when there's no front free capacity, in which case a reallocation is performed. * Reallocation reserves space for G*size() elements: of the resulting G*size()-size() free space, a fraction right_/size() is devoted to back free capacity, the rest to front free capacity. In practice, we may want to keep some minimum space at each end as determined by some empirical threshold. And that's it. Comments welcome. Joaquín M López Muñoz

6 37

[optional] Regression in develop
by Andrzej Krzemienski 06 Nov '17

06 Nov '17

Hi Everyone, Over the weekend I added changes to Boost.Optional in develop which caused regression in Boost.Beast and maybe more libraries. I would like to ask for your input as to how to best approach this. The change was: for trivial `T` use a different specialization of `optional<T>` which is trivially-copyable. For this, I need the ability to declare defaulted functions, and to detect that a given type is trivial. Boost.TypeTraits do not have `is_trivial` trait, so I compose it form `has_trivial_move` and the like. But it seems there are compilers for which Boost.config and Boost.TypeTraits report support for deleted functions/triviality detection, but where this support is buggy. The following is a test case in type_traits by Vinnie Falco: https://github.com/boostorg/type_traits/pull/52/commits/9779157a787620d1633… In addition, the deadline for changes in release 1.66 is getting nigh. I can see a couple of ways to fix this: 1. Fix Boost.Config and/or Boost.TypeTraits so that they only report support for the features in question when it is supported without bugs. But I do not know if there is enough time for this given the deadline. 2. Disable my feature on the compilers with buggy support. But I would need a help from someone who knows all the compilers and their bugs in implementation of trivial type traits so that I can put the wight `#ifdef`s. 3. Just revert my changes to Optional, which is also an option, but would also be a loss. Any input from Boost experts would be appreciated. Regards, &rzej;

5 13

Building Quickbook docs from source code in HTML format
by Kolya Kosenko 31 Oct '17

31 Oct '17

Hello, I'm trying to build QuickBook HTML Boost library documentation from source code. I got *.docbook file, but there is no HTML files at all. For example I built stacktrace library docs: ./b2 -a libs/stacktrace/doc/ And I didn't get any HTML, only stacktrace.docbook: $ find . ./doc ./doc/gcc-5.4.0 ./doc/gcc-5.4.0/debug ./doc/gcc-5.4.0/debug/stacktrace.xml ./doc/gcc-5.4.0/debug/stacktrace.docbook ./doc/none ./doc/none/gcc-5.4.0 ./doc/none/gcc-5.4.0/debug ./doc/none/gcc-5.4.0/debug/autodoc-xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/classboost_1_1stacktrace_1_1basic__stacktrace.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_3516969ce87a02a0560c741857e33749.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_c8984f1860c11f62f47abb6761e46c1e.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/combine.xslt ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace_2stacktrace_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/classboost_1_1stacktrace_1_1frame.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/compound.xsd ./doc/none/gcc-5.4.0/debug/autodoc-xml/index.xsd ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace__fwd_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/index.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost_1_1stacktrace.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost_1_1stacktrace_1_1detail.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_72bdf9838375a891eaf35cbacea5f7be.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/frame__decl_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/frame_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/safe__dump__to_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml.doxyfile ./doc/none/gcc-5.4.0/debug/autodoc-xml.xml-dir ./doc/none/gcc-5.4.0/debug/autodoc-xml.boostbook ./doc/none/gcc-5.4.0/debug/autodoc-xml.doxygen But I need something like this: http://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace.html I have used quickbook install instructions for Ubuntu: http://www.boost.org/doc/libs/1_65_1/doc/html/quickbook/install.html#quickb… It looks like docbook to html conversion is required using some xsl file but I don't know how to do it and what files are used. There is some XSL files in boost/tools/boostbook/xsl folder but I don't know how to use it with b2 build. PS. I have installed xsltproc, docbook-xsl, docbook-xml packages. $ cat ~/user-config.jam using boostbook ; using xsltproc ; using boostbook : /usr/share/xml/docbook/stylesheet/nwalsh : /usr/share/xml/docbook/schema/dtd/4.2 ; using doxygen ; ----- Regards, Kolya.

2 4

[GitHelp] Getting boost stable release from GitHub after git clone
by Kostiantyn Ponomarenko 31 Oct '17

31 Oct '17

Hi, guys. I would appreciate little help in understanding what is the right way of switching to the latest stable boost release after git repository is cloned. My intention is to clone boost, because then, with new releases, I can easily update it with git and switch (checkout) to the next "current" release. PS: I like that boost uses git =). --- Kostia Kyiv, Ukraine

2 2

[contract] differentiate regressions with libc++
by Lorenzo Caminiti 31 Oct '17

31 Oct '17

Hello all, Another question on the regression tests. How am I supposed to differentiate GCC 6.0 between CrystaX-apilevel-19-armeabi-v7a-gnu-libstdc++ and CrystaX-apilevel-19-armeabi-v7a-hard-llvm-libc++? http://www.boost.org/development/tests/develop/developer/contract.html They both use the same toolset name "gcc-gnu-6", but when libc++ is used instead of libstdc++ Boost.Contract tests give these linker errors: ../boost/smart_ptr/detail/sp_counted_impl.hpp:146: error: undefined reference to 'operator delete(void*, unsigned int)' /home/cislave/.crystax/ci-boost/regression/android-19-armeabi-v7a-hard-llvm-develop/tmp/crystax-ndk-10.3.2/sources/cxx-stl/llvm-libc++/3.6/libcxx/include/sstream:189: error: undefined reference to 'operator delete(void*, unsigned int)' ../boost/iostreams/detail/streambuf/indirect_streambuf.hpp:50: error: undefined reference to 'operator delete(void*, unsigned int)' /home/cislave/.crystax/ci-boost/regression/android-19-armeabi-v7a-hard-llvm-develop/tmp/crystax-ndk-10.3.2/sources/cxx-stl/llvm-libc++/3.6/libcxx/include/sstream:740: error: undefined reference to 'operator delete(void*, unsigned int)' collect2: error: ld returned 1 exit status I wanted to mark the link errors for libc++ as expected failures while leaving libstdc++ unmarked (because there are no link errors for libstdc++). However, I don't know how to do that because the toolset name is the same "gcc-gnu-6" for both runs with libstdc++ (column 6) and with libc++ (column 10). Should the toolset names be unique instead? For example, should names like gcc-gnu-6~libstdc++ and gcc-gnu-6~libc++ have been used in this case instead of using just gcc-gnu-6 for both runs? Thank you. --Lorenzo

1 1

fuzzing boost at OSS-Fuzz
by Kostya Serebryany 31 Oct '17

31 Oct '17

Hi, I would like to invite boost developers to use OSS-Fuzz, a continuous automated fuzzing service. https://github.com/google/oss-fuzz https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.ht… I've made the initial set up that fuzzes boost::regex and it found 8 bugs there, see https://svn.boost.org/trac10/ticket/12818#comment:7 3460 boost: Integer-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3464 boost: Integer-overflow in boost::re_detail_NUMBER::perl_matcher... 3469 boost: ASSERT: jmp->type == syntax_element_jump 3471 boost: Stack-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3472 boost: Stack-overflow in boost::re_detail_NUMBER::perl_matcher… 3478 boost: Stack-buffer-overflow in boost::re_detail_NUMBER::perl_matcher... 3479 boost: Null-dereference READ in boost::re_detail_NUMBER::basic_regex... Vinnie Falco pointed me to Jens Weller's blog post about fuzzing beast: https://www.meetingcpp.com/blog/items/fuzzing-beast.html . Jens used libFuzzer, which is one of the two fuzzing engines used by OSS-Fuzz. Adding a boost library to OSS-Fuzz will look very similar to this blog post. For those of you who are at CppCon this week: we can discuss this face to face. --kcc

1 1

property_map/compose_property_map get() return type
by Brook Milligan 31 Oct '17

31 Oct '17

I am trying to understand the logic behind the get() function for the Boost compose_property_map, which is defined in boost/property_map/compose_property_map.hpp. The document states the following: This property map is an adaptor that composes two property map. The new property map will of the same model as FPMap. I interpret these two sentences to mean that the category, value_type, and reference types of the composition will be the same as those for FPMap, while the key_type will be the same as for GPMap. Thus, I expect that get(composition,gkey) should return the same type that get(fpmap,fkey) would. However, the implement does not follow this expectation, which leaves me puzzled. The following is the relevant portion of the code: template <typename FPMap, typename GPMap> class compose_property_map { public: typedef typename boost::property_traits<FPMap>::reference reference; // return type of get(): // if (reference is not a ref) // value_type // else if (reference is const) // reference // else // const value_type& inline friend typename boost::mpl::if_< boost::mpl::not_< boost::is_reference<reference> >, value_type, typename boost::mpl::if_< boost::is_const<reference>, reference, const value_type& >::type >::type get(const compose_property_map &m, const key_type &k) { return get(m.f, get(m.g, k)); } Notice the comment and the selection of the return type. The result is always a value_type or _const_ reference, irrespective of the reference type of FPMap. Consequently, the information advertised as the reference type, which is the same as that of FPMap, is incorrect, and get() does not return a simple composition of the two property maps as described in the documentation. What is the rationale for this behavior? It seems that there must be a reason to go to the great lengths to second guess what FPMap is doing, rather than simply doing what the documentation says should occur, but I fail to see it. I look forward to any clarification. Thanks a lot. Cheers, Brook

1 0

[review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Thorsten Ottosen 31 Oct '17

31 Oct '17

Dear users and members of Boost, I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html

24 159

[boostbook] Building documentation with generate.consistent.ids
by Daniel James 30 Oct '17

30 Oct '17

Hi, This was originally sent to the boost-docs list, but it doesn't seem to be working, so I'm sending it here. Sorry if you receive it twice. A while ago Gregor Jasny suggested building with the generate.consistent.ids option to reduce the changes between snapshots (as many elements in the documentation had random id numbers). I've tried turning it on for the develop documentation build, and tweaked boostbook a little to take advantage of it as well. With this setting generated ids can change when the documentation is edited, but not on every build. If you have standalone documentation and you want to use this feature, you need to use '<xsl:param>generate.consistent.ids=1' in the boostbook rule in your jamfile. This mainly affects boostbook reference documentation, such as: http://www.boost.org/doc/libs/1_65_1/doc/html/boost/accumulators/as_feature… This page gets a new location in every build. With consistent ids it has the consistent, although admittedly uglier, URL: http://www.boost.org/doc/libs/develop/doc/html/boost/accumulators/as_featu_… The advantage is that this will only change when the accumulators documentation is changed (btw. the text part of that url is probably truncated more than it needs to be, I might try to fix that). Other documentation won't be affected so much, as sections usually have explicit ids (quickbook always generates them). An example where a section doesn't is: http://www.boost.org/doc/libs/1_65_1/doc/html/idp22435328-bb.html I suggest you should probably add an explicit id to something like that (I've done so in that case). Daniel

1 0

[review][DoubleEnded] Review Results
by Thorsten Ottosen 30 Oct '17

30 Oct '17

Dear users and members of Boost, I'm happy to to announce that Benedek Thaler's Boost.DoubleEnded is /conditionally/ accepted into Boost provided that it can be integrated smoothly with Boost.Container. There are several other conditions, some major and some minor which I will outline below. For now, I would like to thank everyone that participated with reviews and comments. We didn't have that many reviews, but the reviewers did spend a lot of time both on review and the following discussions. Special thanks also goes to Benedek for his hard work. It is not too often that a GSOC code ends with something of this quality. Two of the world's expert C++ container developers used phrases like "solid" and "everything looks clean and beautiful" about the implementation, "tests look very good, corner cases and all", "The reference section is very good". Congratulations, Benedek. ============== A path forward ============== Ion has most kindly accepted the idea of merging the library into Boost.Container. This consists of A. taking selected elements from batch_deque and adding them to boost::container::deque. B. putting devector into boost.container after changes have been applied to code and documentation C. back-porting the devector code to C++03 (C) does not need to happen immediately, that is, we can have a release where devector is available in a C++11 version. Ion has also most kindly agreed to help with this process. I will help write a new introduction that focuses on the main principles of devector. We also have a number of benchmarks which we can gather and use for a small section of on that topic. I'll leave it to you and Ion to work out the details. ========================== Detailed comments devector ========================== Apart from the merging with Boost.Container, the most heard complaint was about the "fat", the non-essential parts if the interface, that could be removed. This includes -- Remove the direct support for small buffer optimization form devector. When the time comes, provide small_devector similar to the way we have vector/small_vector (there is no requirement that small_devector is provided). -- remove all of the following: - all constructors that uses reserve_only_tag, - all constructors that uses unsafe_uninitialized_tag, - void unsafe_uninitialized_resize_front(size_type); - void unsafe_uninitialized_resize_back(size_type); - unsafe_push_front(...); - unsafe_push_back(...); -- add instead - constructors that uses default_init_t like boost.container - resize versions that uses default_init_t - T& unchecked_emplace_back(...) noexcept(...) - T& unchecked_emplace_front(...) noexcept(...) At some point, I hope we can upgrade default_init_t to mean no construction for all trivially copyable types. There was a wish for more symmetry in devector and so functions that break symmetry or can appear ambiguous should be removed. This means we should remove: -- capacity() There is no need for front_capacity() and back_capacity(). We could remove reserve(), but then we can't use devector with a flat_set. Reserve() should not be an alias for reserve_back() though, but controlled by the policy. We could remove resize(), but even deque has it where it means resize_back(). I totally agree it would be ideal to remove all of reserve(),resize(),capacity(),clear(), but I see no easy way we can use devector with flat containers if we remove the first and the last. Unless we start deprecating stuff in boost::deque/boost::vector and provide new consistent alternatives, we will never get a 100% satisfactory solution. At the end of the day, we need to be pragmatic, so if deprecation is not on the table, this seems the best we can do. Since we don't want two allocations implied by calling reserve_back() and reserve_front(), you can add a mechanism for doing that. That is, you can provide -- reserve( new_capacity ); -- reserve_front( new_front_capacity ) -- reserve_back( new_back_capacity ) -- reserve( new_front_capacity, new_back_capacity ) or, since reserve() is such a weird beast, simply provide -- reserve( new_capacity ); // for flat containers -- anticipate_front( new_front_elements ) -- anticipate_back( new_back_elements ) -- anticipate( new_front_elements, new_back_elements ) to get rid of the funky -- container.reserve_front( container.size() + new_front_elements ) dance. There were suggestions for shrink_back/front_to_fit, but since we are trying to remove fat, I suggest that we wait for a use-case. There were also suggestions that clear() should be amended. As the growth (or resizing policy) mandates what clear does, we need a way to escape. The minimal change that allows that is to provide -- clear( front_free_capacity ) which gives full power to the user. You may provide clear_back() as clear(0) and clear_front() as clear(c.size()+c.front_free_capacity()+c.back_free_capacity()). Ideally, clear() would have been removed entirely like capacity()/resize(), but like reserve(), it just seems like impossible when we start using it with flat containers. Other minor comments: - drop strong exception safety guarantees and do it like boost.container - prefer to make iterator a type (should be easy with reuse from boost::container::vector - allocator should not be inherted from - make clear O(1) amortized gurantees depend on growth policy - consider calling growth policy for resizing policy - make sure SFINAE works properly with constructors - make the default growth factor 2 (as we heard from Sean Parent: no factor below 2 is empirically good) - consider renaming front_free_capacity to free_front_capacity. Rationale: "front_capacity" is a concept, noun, and "free" is the adjective. Ditto for back_free_capacity. - remove size_type from growth policy and take it from the allocator - make the allocator template argument the 2nd argument - fix remaning TODO in code - documentation should not sell devector as drop-in replacement for vector, but rather stress it is not - the allocator supports needs to be improved. I guess doing it the Boost.Container way ensures that (ask Daniel James for help) - exception-safety issues pointed out by Ion - postconditions of insert/erase needs to specify behavior to front_free_capacity/back_free_capcity - use of local containers should be avoided - rotate should be avoided - delegate range move operations to those defined in Boost.Container - make sure all functions excepting non-overlapping range uses memcpy (not just memmove). This includes: - range constructor - copy-constructor - copy-assignment - range-assignment - range insert - destructor should used std::has_trivial_destructor to avoid loop in that case to make sure all compilers optimize it away (similar for erase). There is one final puzzle and that is the growth policy. I hope we can finalize that by testing Joaquin's and Ion's suggestions over the coming weeks. ============================= Detailed comments batch_deque ============================= For deque, the comments were similar, although there was far less to discuss than for devector. All agreed that one should be able to control the segment size. - stable_insert was not needed. - segment iteration was good, but should be usable with range-based for loop. The segment iterator should return a segment type if possible, and the segment should have begin(),end(),size() members. - since boost::deque already has a resize with default_init_t, that should be sufficient to provide fast serialization load for trivial types. No need for - resize_front - resize_back - unsafe_uninitialized_resize_front - unsafe_uninitialized_resize_back - reserve - shrink_to_fit() - capacity() The following are still needed for optimal code (or code that can be known not to reallocate, or for better locality in deserialization, avoiding double initialization) - free_front_capacity; - free_back_capacity; - reserve_front - reserve_back - unchecked_emplace_front - unchecked_emplace_back Boost.Container's unit-tests should be extended with those from batch_deque where it makes sense. Since segmented iteration was somewhat faster, it should be use internally where it makes sense. In particular - copy-constructor - copy-assignment - destructor As for devector, all constructor/functions that iterate over non-overlapping ranges should use memcpy. destructor should use is_trivially_destructible to ensure it is optimized away (similar for erase). ====================== Serialization comments ====================== I suggest that the default versions just do what Boost.Serialization does, perhaps just replacing resize with resize with default_init_t. That ensures it works correctly for all archive types. It also needs to use make_nvp() so the output is identical to std::vector. We will then talk to Robert about how we can take advantage of the binary archive in a correct fashion. ====================== kind regards Thorsten, review manager

8 12

PSA: Travis OS X bottleneck, <cxxstd> new Boost.Build feature
by Peter Dimov 30 Oct '17

30 Oct '17

Travis's OS X resources for open source projects seem to be insufficient, so OS X jobs are very slow and seem to be falling further and further behind. Therefore, library authors are encouraged to keep the OS X jobs to the minimum necessary. Spawning many OS X jobs takes hours (~25 minutes waiting time per job at a quick estimate). On a not entirely unrelated note, Rene Rivera has added a new feature <cxxstd> to Boost.Build that controls the C++ standard in use. So for instance, instead of the old b2 libs/mylib/test toolset=gcc cxxflags=-std=c++11 one can now use b2 libs/mylib/test toolset=gcc cxxstd=11 In addition to being more convenient, this also allows several invocations to be combined into one: b2 libs/mylib/test toolset=clang cxxstd=03,11,14,1z which can be leveraged to cut down on the number of jobs. An example of using cxxstd in .travis.yml can be seen here: https://github.com/boostorg/system/blob/develop/.travis.yml

7 13

Adapting boost::grid_graph vertex descriptors to Boost Geometry
by Brook Milligan 30 Oct '17

30 Oct '17

Generally Boost Graph vertex descriptors are opaque types with limited means of constructing them; they may be default constructed or constructed with the null_vertx() function, by dereferencing vertex iterators, calling source()/target() on an edge descriptor, or by calling the add_vertex() function. It is never expected that one will construct a vertex descriptor directly with a non-default constructor. The Boost grid_graph is similar, with the exception that vertex descriptors may additionally be constructed from a vertex index. However, a vertex descriptor for an n-dimensional grid_graph is quite naturally an n-dimensional point. Consequently, it should be possible, without breaking the abstraction, to construct one (and perhaps use one) as a point. Given that this use is not documented in any way, doing so breaks the abstraction. At least three solutions are possible: - #include <boost/geometry/geometries/adapted/boost_array.hpp> in grid_graph.hpp: boost::array<> is the implementation of the grid graph vertex descriptor, so this would immediately make vertex descriptors model Boost Geometry points. - Add a boost/graph/adapt_grid_graph_to_geometry.hpp (better name needed) file that includes the same file so that the selection is optional. - Add a boost/geometry/geometries/adapted/grid_graph.hpp file that includes the same file, again making the selection optional. Since the contents of boost/geometry/geometries/adapted generally refer to external libraries (e.g., Boost Array), the last option seems the most appropriate, although it suffers in case the vertex descriptor is changed but not the adaptor. That however applies to all the adaptors equally. Any of these solutions differs from using boost/geometry/geometries/adapted/boost_array.hpp directly in user code, because that requires unpacking the nature of the vertex descriptor and leaves open the potential for breaking changes in user code if the vertex descriptor changes. Because a vertex descriptor is opaque, breaking the abstraction seems inappropriate, even here. Thus, I suggest the following: - add boost/geometry/geometries/adapted/grid_graph.hpp which includes boost/geometry/geometries/adapted/boost_array.hpp. - add the new adaptor to the Boost Geometry documentation - add a note to the Boost Graph grid_graph documentation indicating that it is possible to adapt the vertex descriptor and use it as a point. Thoughts? Cheers, Brook

2 2

[contract] help marking regression test expected failures
by Lorenzo Caminiti 27 Oct '17

27 Oct '17

Hello all, I need some help with marking some Boost.Contract regression tests as expected failures. I don't understand why my explicit-failures-markup.xml: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… Doesn't math the expected failures I see on the regression report: http://www.boost.org/development/tests/develop/developer/contract.html For example, the following from explicit-failures-markup.xml (around line 887) should marked old-if_copyable test as an expected failure on msvc-11.0: ... <mark-expected-failures> <test name="old-if_copyable"/> <test name="old-if_copyable_macro"/> <toolset name="gcc-gnu-4.7.2"/> <toolset name="gcc-gnu-4.7~c++11"/> <toolset name="gcc-mngw-gnu-4.6c+"/> <toolset name="gcc-mngw-gnu-4.7c+"/> <toolset name="msvc-10.0"/> <toolset name="msvc-11.0"/> <note author="Lorenzo Caminiti"> Test fails because this complier version does not properly implement SFINAE causing incorrect errors on substituion failures for private and protected members (this seems to be fixed in GCC 4.8 and MSVC 12.0). </note> </mark-expected-failures> ... But the old-if_copyable test still shows up as a failure on the regression test report: http://www.boost.org/development/tests/develop/developer/output/teeks99-08-… Any idea what I am doing wrong? Thank you. --Lorenzo

5 19

path length too long for 64 bits builds
by Vicente J. Botet Escriba 27 Oct '17

27 Oct '17

Hi, we have an issue since we have added threadapi= . On 64 bits windows machines we are seen Austin Beer said in https://github.com/boostorg/thread/pull/188#issuecomment-339829423 "FYI, the 64-bit Windows builds are failing due the unit tests exceeding the 260 character filepath limit on Windows. Every filepath includes |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|. Do you know if there is an easy way to shorten this? On the 32-bit builds the filepaths don't have |\address-model-64| which is just enough to keep them under the 260 character limit so they don't fail." Is there a workaround to this issue without changing the specific part of the test files folder structure? Best, Vicente

3 3

Boost::iostreams dual-use seekable filter
by Jonathan Biggar 26 Oct '17

26 Oct '17

I see dual-use filters and seekable filters, but I can't find an example of a dual-use seekable filter. Any help digging me out of template error heck would be appreciated.

1 0

Seems like I need write-access to merge a PR
by Fernando Cacciola 25 Oct '17

25 Oct '17

Hi, It's been a lifetime since I last worked on Boost, and I'm lost as to the current procedures with the repository. I've been looking into this open ticket: https://svn.boost.org/trac10/ticket/12972 and noticed this open pull request: https://github.com/boostorg/numeric_conversion/pull/7 but even though I'm logged with my Github account, it appears I don't have write-access to merge this PR. I tried the wiki but seems to have way too much information. Can you simplify the steps needed, these days, to fix a bug on a library? specially if someone else already created a PR as in this case? TIA -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

7 17

Help wanted: Open pull request reminders
by Beman Dawes 25 Oct '17

25 Oct '17

As a library maintainer, I'd like to get periodic reminders of open pull requests for libraries I maintain and perhaps some other libraries I'm interested in. I'd like a email reminder, but others might prefer Slack or other forms of notification. A related need is for anyone to be able to find the total number of open pull requests for Boost as a whole, and perhaps get a sorted list of the per library counts. Or maybe we should just show today's count on the web site? Googling for "github open pull request reminders" shows that lots of others feel the same need. Would someone like to volunteer to review what others are doing to meet this need, and recommend an approach suitable for Boost? --Beman

9 12

Re: [boost] Boost.TR1 silently removed with 1.65?
by Guido Trentalancia 25 Oct '17

25 Oct '17

On the 9th of September 2017 19:38:43, Tim Rakowski <tim.rakowski_at_[hidden]> wrote: > Hi, > > I noticed that boost 1.65 does not contain the tr1 folder and found that > the documentation was updated accordingly: > http://www.boost.org/doc/libs/1_64_0/ contains > http://www.boost.org/doc/libs/1_64_0/libs/tr1/, while > http://www.boost.org/doc/libs/1_65_0/ has no > http://www.boost.org/doc/libs/1_65_0/libs/tr1/. > But http://www.boost.org/users/history/version_1_65_0.html > <http://www.boost.org/users/history/version_1_65_0.htmldoes> does not > mention this. > Even if it was deprecated, shouldn't this be mentioned somewhere? Googling > "site:https://lists.boost.org/Archives/boost/ 1.65 tr1" didn't yield > anything either :/ > Regards, > Tim Hello ! I am experiencing the same problem... Software packages using boost require the TR1 header files in order to build, but the TR1 header files are no longer available in version 1.65.1 ! What is going on ? Regards, Guido

5 5

[regression tests] feature request: UI integration of bjam requires clause
by Joaquin M López Muñoz 25 Oct '17

25 Oct '17

Hi, Boost regression tests as run by run.py can be explicitly disabled through two different mechanisms: 1. By marking the disabled toolsets with <mark-unusable> in status/explicit-failures-markup.xml. 2. By adding a requires clause in the corresponding Jamfile.v2 file. For instance, in Boost.PolyCollection C++11 is mandated through project : requirements [ requires cxx11_noexcept ] # used as a proxy for C++11 support ... (https://github.com/boostorg/poly_collection/blob/develop/test/Jamfile.v2 ), which results in non-C++11 toolsets being effectively disabled. The problem is that both mechanisms show very differently in the HTML report: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… Toolsets disabled through markup appear grayed out wth a "n/a" legend and an (optional) link to an explanation of why the toolset doesn't work, whereas tests blocked by Jamfile's requires just show a blank column. Would it be possible to modify the regression test HTML reporting utility so that Jamfile-blocked toolsets show also as "n/a" in gray or something similar? The possibility of also adding a link to a custom explanation would be a boon, but I guess this is much harder. This would greatly increase the readability of the reports, particularly by non-savvy users who are likely to deem blank columns as just missing tests that might eventually be filled up. Many thanks, Joaquín M López Muñoz

2 2

Release Note responsibilites for maintainers
by James E. King, III 24 Oct '17

24 Oct '17

The upcoming release of 1.66.0 will be my first release in a maintainer role. How are the release notes generated and what are maintainer's responsibilities during each phase of the release cycle? Thanks, Jim

2 1

RFC.. Steering Committee Bylaws Proposal
by Rene Rivera 24 Oct '17

24 Oct '17

It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1]. The Bylaws hopefully address some key issues that I feel are at the core of the current problems: * Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2]. [1] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/Boost%20Steering%20Committee%20Bylaws.md> [2] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/2011-05-20%20Boost%20governance%20annotated.pdf> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

13 35

boost timer, warnings, backlog
by James E. King, III 24 Oct '17

24 Oct '17

I'm seeing a warning for use of "long long" in a lot of builds, originating in Boost.Timer. I like warning-free builds, so this is something I would like to see resolved. There's an issue in Boost Trac for it: https://svn.boost.org/trac10/ticket/12996 There's a pull request open since April for it (and 3 more going back a couple years): https://github.com/boostorg/timer/pull/4 Is this module still actively maintained? Thanks, Jim

5 6

[Outcome] WG21 papers of interest to Boost and Outcome
by Niall Douglas 24 Oct '17

24 Oct '17

This October's mailing has lots and lots of WG21 papers related to Outcome which were strongly influenced by the peer review here in May. Boost members who contributed to the Outcome v1 review in May should please take a bow and accept thanks for spurring so much discussion and debate regarding these potential future C++ features. Thank you. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf Utility class to represent expected object 2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r1.pdf C++ Monadic interface 3. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0762r0.pdf Concerns about expected<T, E> from the Boost.Outcome peer review 4. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0779r0.pdf Proposing operator try() (with added native C++ macro functions!) 5. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0786r0.pdf SuccessOrFailure, ValuedOrError and ValuedOrNone types 6. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0824r0.pdf Summary of SG14 discussion on <system_error>: towards exception-less error handling Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[timer][msvc] Universal-Windows advice needed
by Beman Dawes 23 Oct '17

23 Oct '17

Pull request https://github.com/boostorg/timer/pull/3 is a fix for Universal-Windows: "universal-windows: GetProcessTimes is not supported". Does anyone have a clue whether the P/R is correct and the best solution? Is the stated problem a temporary one that Microsoft will likely fix, and will it likely be a permanent limitation? Thanks, --Beman

1 0

[system] Header-only Boost.System by default ?
by Damien Buhl 23 Oct '17

23 Oct '17

Dear Boost, Is there any reason why Boost system couldn't be set to be header only by default ? Defining both macros allows it : - BOOST_SYSTEM_NO_DEPRECATED - BOOST_ERROR_CODE_HEADER_ONLY This ease, speeds up and reduces binary size greatly, that it's sad that non-aware Boost User needs to link to some dll/so/dylib of Boost.System per default. It has been in many releases of Boost, wouldn't it be good to set it to be the default for a next release ? Cheers, -- Damien Buhl Software Developer +33 6 77 43 10 05

10 25

[BoostBook] how to automatically test code examples?
by Hans Dembinski 19 Oct '17

19 Oct '17

Hi everyone, I am using BoostBook to prepare the documentation for the proposed histogram library https://github.com/HDembinski/histogram I have written a good deal of the documentation already, and it compiles fine with bjam (thanks to Klemens who showed me how). It says in the BoostBook documentation http://www.boost.org/doc/libs/1_65_1/doc/html/boostbook.html "The BoostBook format allows testcases to be generated by weaving together program fragments from example programs in the documentation. This capability is integrated with testsuite generation so that example programs are normal tests in BoostBook." That's awesome, I would love to use this feature, but the documentation is not explaining how to actually do that. I found the element "testsuite" which probably does what I want. I went on to scan the Boost repository for this BoostBook element, but couldn't find an example to copy from. Could someone help me out? How do I modify my BoostBook and Jam files to generate tests out of the code examples in the documentation? Best regards, Hans

6 14

[msvc] #warning preprocessor directive
by Beman Dawes 17 Oct '17

17 Oct '17

I find it very irritating that VC++ does not support #warning, and have opened a feature request: https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20… The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link. The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++. --Beman

6 20

Merged #149, "Encode architecture and address model in versioned layout names"
by Peter Dimov 17 Oct '17

17 Oct '17

I've just merged https://github.com/boostorg/boost/pull/149, "Encode architecture and address model in versioned layout names", into the develop branch. Let's see how this goes. Welcome to 2005. :-)

6 10

How to build boost on windows with Clang/LLVM
by degski 17 Oct '17

17 Oct '17

With the latest snapshot builds of clang, thin LTO is supported on Windows. This thin LTO gives very interesting (speed) results. I would therefore like to start to build boost with clang and no longer with msvc. I have msvc 15.4 installed (the latest incarnation). I made a project-config.jam: =============start=============== import option ; using clang : 6.0 : clang++.exe : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1911 <linkflags>-fuse-ld=lld <linkflags>-flto=thin ; option.set keep-going : false ; ==============end=============== I call: bjam -a -d+2 cxxflags="-O0" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=debug instruction-set=haswell threading=multi link=static runtime-link=static --prefix=%PREFIX% --build-dir=c:\boost-build address-model=64 architecture=x86 toolset=msvc --without-python --without-mpi --disable-filesystem2 install This does not work. What is the proper way to compile boost on windows using clang++.exe or clang-cl.exe for use with VS2017. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 7

Looking for a task to contribute to boost
by vivek pandya 17 Oct '17

17 Oct '17

Hello Boost Developers, I am Vivek. I contribute small patches to LLVM project. I wanted to work for boost open source project to enhance my C++ knowledge. Could someone suggest some project to me? I will be able to complete task suitable for Google Summer of Code with help and guidance form community. Please also suggest required assignments as I am not a frequent user of Boost libraries. Thanks, Vivek

3 2

Recommend dropping test coverage on msvc-7.1 and msvc-8.0
by James E. King, III 16 Oct '17

16 Oct '17

MSVC 7.1 and MSVC 8.0 are currently listed as "tested" in the Boost 1.65.1 release notes however there are a lot of projects that do not seem to support them well, if at all: http://www.boost.org/development/tests/master/developer/issues.html <http://www.boost.org/development/tests/develop/developer/issues.html> It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit. Appveyor only supports back to Visual Studio 2010 at this point, so our ability to get pre-commit checks on compilers before msvc-10.0 is solely based on maintainer effort. I suspect this effort is no longer justified based on the age of the compilers. Thanks - Jim

13 31

Bjam broken on windows with VS2017?
by degski 16 Oct '17

16 Oct '17

My lappie has vs2017 installed, latest (15.4) version, from some days ago. I did the following: 1. Put a clean copy of the boost 1.65.1 source in c: root. 2. issue 'bootstrap.bat' in c:\boost_1_65_1\ (ordinary prompt, no vs thingy). This creates a project-config.jam msvc file. 3. Copied (overwrote project-config.jam) the below contents as project-config.jam to c:\boost_1_65_1\ =======start======= import option ; using clang : 6.0 : "C:\\Program Files\\LLVM\\bin\\clang++.exe" : <compileflags>-fmsc-version=1911 <compileflags>-DBOOST_USE_WINAPI_VERSION=0x1000 <compileflags>-DBOOST_USE_WINDOWS_H=1 <compileflags>-D_WIN32_WINNT=0x1000 <compileflags>-DNOMINMAX <ranlib>"C:\\Program Files\\LLVM\\bin\\llvm-ranlib.exe" <archiver>"C:\\Program Files\\LLVM\\bin\\llvm-ar.exe" <linkflags>-fuse-ld=lld <linkflags>-flto=thin ; option.set keep-going : false ; =======end======== 4. issue 'bjam -d0 --clean' The script of that, and the result is below: Microsoft Windows [Version 10.0.15063] (c) 2017 Microsoft Corporation. All rights reserved. C:\Users\User>cd \ C:\>cd boost_1_65_1 C:\boost_1_65_1>bootstrap.bat Building Boost.Build engine Bootstrapping is done. To build, run: .\b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: .\b2 --help - Getting started guide: http://boost.org/more/getting_started/windows.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html C:\boost_1_65_1>bjam -d0 --clean 'C:/Program' is not recognized as an internal or external command, operable program or batch file. etc.. etc... the rest is history? Any ideas? degski

2 3

'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context
by james 15 Oct '17

15 Oct '17

I was considering whether I could/should build an actor system on Rust rather than C++, since it would be an interesting exercise for me. And then I found this article: https://www.reddit.com/r/rust/comments/56wgzq/status_of_coroutines/ In particular: > we noticed that the Rust stdlib is actually using TLS (!) to implement exceptions It seems to me that in practice other compilers might use some sort of thread-local hook for exceptions, whether it is TLS or something lower-level that supports TLS. And that the issue is whether the compiler will assume that the address of the TLS (or thread information block etc) is volatile, or can be cached in a stack frame or register across calls. It seems to me that any such caching of an address might cause difficulty, not just in Rust but also other languages. Microsoft's compiler explicitly has a switch for 'fibre safe optimisations' that disables such caching. The worry I have is code like this: void foo() { try { A() } catch (...) {} B(); // Can switch the context to another underlying OS thread try { C() } catch (...) {} } I am concerned that information about exception handling that was acquired for the first try block, might be retained in the frame and reused in the second try block. and the information might be captured in the frame and/or registers that get saved in the context, but in an arbitrary way. I suspect that access to explicit ABI TLS or C++ thread local is also impacted, although it might be easier to avoid. I guess its not a complete show-stopper if we ensure that fibres never migrate between OS threads, but that is somewhat inconvenient. So - is this actually a Rustc specific issue?

1 0

printf official specs or docs, ISO C99, and C++
by James E. King, III 14 Oct '17

14 Oct '17

I found https://svn.boost.org/trac10/ticket/10541 today and my guess is Boost.Format hasn't been updated to support the ISO C99 extensions, or the Microsoft type formats. Before any work is done on this, I'm looking for any official C++ documentation related to printf support requirements. For example the compatibility section in http://www.cplusplus.com/reference/cstdio/printf/ indicates certain language levels have requirements. Thanks, Jim

3 3

[build] Building library with vc++ 64-bit does not find vcvarsall.bat
by Edward Diener 13 Oct '17

13 Oct '17

If I build any library with any version vc++ 64-bit compiler, by using address-model=64, the vcvarsall.bat is looked for at, for example with msvc-14.0, C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/vcvarsall.bat and is not found. Naturally this leads to basic compilation failures. The path for vcvarsall.bat for msvc-14.0 is C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat instead. All versions of vc++ follow this path structure for vcvarsall.bat Building with any version of vc++ 32-bit, by not specifying the address-model, works correctly.

3 4

1.65.1 as modular packages on Conan.io
by Rene Rivera 13 Oct '17

13 Oct '17

Following on with the announcement before CppCon of the 1.64.0 modular packages here we are with more. I'm pleased to announce that the 1.65.1 Boost C++ Libraries are now available individually using the Conan package manager. There's even some improvements for the 1.64.0 package also :-) Find out more from the Bincrafters post here <http://bit.ly/2g6VEpp>[1]. For help using the packages you can bug the Bincrafters team in the #Conan CppLan Slack channel <http://bit.ly/2ykeqC0>[2]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[3]. [1] <https://bincrafters.github.io/2017/10/13/Conan-Packages-Boost-1-65-1/> [2] <https://cpplang.now.sh/> [3] <http://docs.conan.io/en/latest/integrations.html> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

1 0

Maintainers: Adding Coverity Scan to your library
by James E. King, III 13 Oct '17

13 Oct '17

I have completed the work necessary to add Coverity Scan to Boost.Uuid and wanted to share the steps involved. This work can be carried into other libraries fairly easily. 1. Go to Coverity Scan: https://scan.coverity.com/ 2. Sign up/in with your Github account. 3. Create a project for your boostorg/library. It will take about 24 hours for them to activate your account so that you can use the results browser. To run a coverity scan manually: 1. Check out your project master (or whatever branch you want to scan). 2. cd into BOOST_ROOT (where "libs/" is located) 3. Run the libs/uuid/covscan.sh script with the following environment variables set: A. COVERITY_SCAN_TOKEN: the project token in coverity scan B. COVERITY_SCAN_NOTIFICATION_EMAIL: your email C. SELF: your library name, for example SELF=uuid for Boost.Uuid 4. You will need to clean up some cruft it leaves behind as the script is designed for Travis CI - just a couple directories starting with "cov" and a tar.xz file. To integrate coverity scans for every pull request or push into master with Travis CI: 1. Make sure you have Travis CI set up properly to build your project. 2. Copy the Coverity Scan stanza from libs/uuid/.travis.yml into your .travis.yml file. Note that the Boost.Uuid travis configuration now uses jobs instead of matrix, as jobs allow for conditions. I would encourage you to convert your .travis.yml to use jobs as well. 3. The next pull request into master, or the next push into master, will trigger a build, and any build for master will run covscan.sh and upload the data. You can add component regular expressions to ignore/omit other boost library errors if you wish. Here are the results for Boost.Uuid. I have not excluded other components yet: https://scan.coverity.com/projects/boostorg-uuid Initially I saw a flurry of "unhandled exception" items which I dismissed as intentional (i.e. I want the test to segfault if an unexpected exception is thrown so that I can debug it), and that will likely be a common practice for test files, but should not be for implementations. I also caution folks against marking something as a false positive. Approach it with the mindset of, "it must be a fault of the library" before jumping to, "it must be a fault in Coverity" and really convince yourself it is not a code issue. Even if you do not have travis integration in your library, running a manual scan will help you improve the quality of your library, so I recommend everyone at least do that much. - Jim

5 5

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

Boost.Format Library Maintenance
by James E. King, III 12 Oct '17

12 Oct '17

Currently the Boost.Format library is being maintained by the CMT. I would like to petition for that responsibility and lighten their case load further. I recently assumed maintenance for Boost.Uuid, and I have added Universal Windows Platform support to Boost.WinAPI and Boost.Predef so that folks will have an easier time making Windows Store compatible apps. I have also been working on a change that will add UWP support to Boost.Random and turn it into a header-only library, and expect to submit that in the next few days. I would like to shore up the CI environment for Boost.Format and groom the backlog in trac and on github, and get all the open issues resolved. Thanks for your consideration, Jim King

3 3

[Build] How to build libboost_lzma?
by degski 12 Oct '17

12 Oct '17

Up till now I have built libboost_zlib and libboost_bzip2 by setting ZLIB_SOURCE and BZIP2_SOURCE variables to their respective source directories on the bjam command-line and the libraries get built without fail. I gather (from the bjam output) their is now support for lzma, which I would like to use. I've tried a similar (did not find a doc) approach with LZMA by feeding "-sLZMA_SOURCE=c:\xz-5.2.3" (from https://tukaani.org/xz/xz-5.2.3.tar.gz) to bjam. This does not work. How do I make bjam build libboost_lzma? Thanks in advance. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 1

Boost Serialization: Serializing large objects
by Adlai Shawareb 12 Oct '17

12 Oct '17

We are trying to text serialize a 700 MB object. We are getting an archive_exception: input stream error. This is on a 32-bit QNX system. * Is there a limit to the size of the object that can be serialized? * Is there anything we can do to fix or work around this? Here is the code we are using: std::stringstream ss_; boost::archive::text_oarchive oa(ss_, boost::archive::no_header); oa << &object; Adlai

4 11

interest in a stateful pointer library?
by Hans Dembinski 11 Oct '17

11 Oct '17

Hi everyone, I wrote a variant of std::unique_ptr, called tagged_ptr, which allows safe read/write access to a customisable number of bits in the pointer variable. You can find the library on github: https://github.com/HDembinski/stateful_pointer You can use those bits to store extra state in the pointer variable at no extra space cost. I did some benchmarks to show that the computational overhead required for the bit manipulation is also negligible. One needs little imagination to find good use for those bits. As a proof of principle, I wrote an STL compatible string class which has the size of const char*, but can store up to 7 ASCII characters (on a 64 bit system) without allocating any memory on the heap (aka small string optimisation). The string class is also included in the library. To make this work, I use one of the bits in the pointer variable to recognise whether the variable should be interpreted as a pointer or as a char array. The Stateful Pointer library is C++11, header-only, and AFAIK platform-independent (in theory, this has not been tested so far). To create pointers which allow one to use a certain number of bits for other purposes, I rely on Boost.Align to allocate aligned memory. How does it work? Aligned memory, as the name implies, does not point to any address in memory, only certain addresses are allowed. For example, a two-byte aligned memory block can only have an even address. Therefore the lowest bit in the address is always zero. Since the bit is guaranteed to be zero, we can use it to store something else and mask it to zero whenever we need to dereference the pointer. I think this is a generally useful class to have in Boost, so is there some interest in polishing it up in a review process? Best regards, Hans

7 18