- Boost - lists.boost.org

[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