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

[modularization] About sub-sub-module path/names..
by Rene Rivera 06 Jun '14

06 Jun '14

This past week I spent time to update my documentation tools to the latest to get the Predef release done. As part of that I created my own mini-Boost that is both minimal to just getting Quickbook compiled and I can control when updating <https://github.com/grafikrobot/boost-doctools/tree/develop>. One frustrating aspect of building that repo was that I made various accidents in adding submodules because of naming. And a key one was the structure for the numeric submodules <https://github.com/boostorg/boost/tree/develop/libs/numeric>. So I have one basic question: Is there a *good* reason why numeric submodules need to have their own subdirectory? It would seem to me much easier to understand if all submodules where flat and on the libs/* dir. The uniformity would also remove various special cases I saw in build and testing code files. For example some special code in Boost/Jamroot <https://github.com/boostorg/boost/blob/develop/Jamroot#L149>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[core] Detach demangle() from type_info
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi Peter, I can see you already extracted demangle() to boost/core. Great, thanks! However I'd prefer it to be detached from type_info. This tool would be useful with different kinds of symbols, like function and variable names, not just type_info. So it better accept a string as an argument and not type_info. demangled_name() should probably be in core/typeinfo.hpp. And regarding typeinfo.hpp. Aren't we duplicating Boost.TypeIndex here? PS: I was also planning to create pull requests to other libraries to use demangle from Core. These are Exception, Units, TypeIndex and Log, AFAIK. Do you plan to do this? If not, I could.

3 5

[Modularization] unique_ptr (interprocess/smart_ptr) and SmartPtr
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, what about moving|boost/interprocess/smart_ptr/* to module SmartPtr?| || |||| |||Vicente| ||

3 3

Re: [boost] [pimpl] No documentation for pointer semant
by Dave Gomboc 06 Jun '14

06 Jun '14

[Paul A Bristow]: > I unhappy with a review rigid policy that nothing can be changed during a > review. It isn't always helpful. > > We never accept anything without requiring some changes? > > Can we instead now use git's easy branches to specify a fixed 'master' branch, > but allow the author to update a 'develop' branch as the review develops? [Edward Diener]: > I believe that changes can be made to a reviewed library during a review > as long as the 'master' branch does not change. After all we want all > reviewers to be looking at the same 'master' branch as the code to be > reviewed. But if the developer wants to make changes to other branches > during the review I think this should be allowed. May I suggest that either the library author or the review manager ought to, near the commencement of the review, identify a specific version to be reviewed? This is quite distinct from identifying a branch name for a conventional branch such as master that is expected to change frequently even over a two-week period. A specific checkout is typically identified by a SHA: a branch name such as 'master' is primarily just an alias to the SHA to which it currently resolves. Then again, Boost is relatively new to using git, so perhaps a new branch name can be introduced to refer specifically to the review version. The review manager could, at the commencement of the review, specify the checkout instructions using a specific SHA. For example, for Boost.Pimpl, the manager would provide Source: https://github.com/yet-another-user/boost.pimpl, SHA 59a5c0d or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git reset --hard 59a5c0d As I mentioned, not everybody may be comfortable working directly with SHAs immediately, so the library author and/or the review manager may wish to introduce a specific label for the purpose of easing identifying the review version. If one of them (or somebody else with write access to the repository) continues from the above two commands with the further git checkout -b boost_review git push origin boost_review then it still becomes possible for the contents of the master branch to change (which, generally speaking, is highly desirable) without disrupting the review process. In this case, the instructions provided by the manager could be: Source: https://github.com/yet-another-user/boost.pimpl, branch boost_review or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git checkout boost_review which should be more palatable to the large group of people migrating from Subversion. Naturally, in this case it is imperative that boost_review not itself be pushed to further during the review. However, there is no reason the library author from continuing with these commands: git checkout -b boost_review_fixes git push -u origin boost_review_fixes at which point, fixes to items that come up in the review can be pushed onto that branch, and those people who specifically want to take a look at the fixes can easily do so. The above said, the long-term simplicity of specifying a SHA directly instead of a branch at all is not only that one doesn't have to go and make a bunch of new branch names in order to continue development, but even more importantly, one can't push to a SHA to change its contents --because modifying a commit after the fact modifies its SHA also -- so everyone is sure to get the same version of the content being reviewed. Dave

3 2

[optional] Is detail/none_t.hpp needed?
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi, I've noticed there's boost/detail/none_t.hpp header, which basically reflects boost/none_t.hpp. Worse even, it would cause a conflict if both these headers are included. A search didn't reveal any users of this header. Since it's a detail, could this header be removed?

2 5

cstdint.hpp dependency not working?
by John Maddock 06 Jun '14

06 Jun '14

With the recent changes, when building any file that depends on cstdint.hpp I see: link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\include\boost\cstdint.hpp link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\..\integer\include\boost\cstdint.hpp And this happens for every build - even though everything is up to date. Any ideas? Thanks, John.

4 5

A few more critical dependencies
by Peter Dimov 06 Jun '14

06 Jun '14

At present, we have three dependencies that we can easily cut and doing so will be very beneficial: 1. type_traits now depends on utility only because utility: <boost/utility/declval.hpp> from <boost/type_traits/common_type.hpp> from <boost/type_traits/detail/common_type_imp.hpp> from <boost/type_traits/is_copy_constructible.hpp> from <boost/type_traits/is_nothrow_move_assignable.hpp> from <boost/type_traits/is_nothrow_move_constructible.hpp> Since declval.hpp itself depends on type_traits (add_rvalue_reference), it can't go to core and the most logical place for it is type_traits itself. 2. utility depends on iterator because iterator: <boost/iterator.hpp> from <boost/operators.hpp> <boost/iterator/iterator_facade.hpp> from <boost/generator_iterator.hpp> boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.) generator_iterator.hpp perhaps needs to be moved to iterator. 3. mpl depends on detail because detail: <boost/detail/endian.hpp> from <boost/mpl/string.hpp> <boost/detail/lightweight_test.hpp> from <boost/mpl/aux_/test.hpp> That last one is just because lightweight_test.hpp hasn't been removed from Detail yet; let me know if I should do that. boost/detail/endian.hpp is just a forwarding header that includes <boost/predef/detail/endian_compat.h>. We should move it to Predef. Comments? Objections?

6 20

[core] scoped enum authoring
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi Andrey. In the Boost.Core documentation I see: "Thanks to Andrey Semashev for pointing out that emulation through a namespace could not be used within classes. Helpful comments and suggestions were also made by Kjell Elster, Phil Endecott, Joel Falcou, Mathias Gaunard, Felipe Magno de Almeida, Matt Calabrese, Vicente Botet, and Daniel James." The authors of this file are Beman (for the class based version) and me (for the namespace based). As the documentation has been mainly extracted from the file I would appreciate if both Beman and I are added as authors. BTW, there is no deprecation for the Beman version, there are just different advantages and liabilities. I suspect that the same is applied to the other component of the Boost.Core module Thanks for working on this. Vicente

5 6

[admin][thread] Request for write access fro Niall
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, I would like to give write access to Niall Douglas for Boost.Thread. He has some new features to add and also he could help me to fix some obscure bugs and to maintain the windows port. Can some of the administrators add him as member of the Boost.Thread maintainers team? Thanks, Vicente

2 1

[Config] Announce: New Build time configuration feature
by John Maddock 06 Jun '14

06 Jun '14

In develop only is a new feature to make configuring targets at build time easier, from the docs: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are times when you want to control whether a build target gets built or not, based on what features the compiler supports. For example, suppose you have a test file "test_constexpr_128.cpp" which requires three key features in order to build: * The constexpr keyword as detected by BOOST_NO_CXX11_CONSTEXPR. * User defined literals, as detected by BOOST_NO_CXX11_USER_DEFINED_LITERALS. * The __int128 data type, as detected by BOOST_HAS_INT128. Clearly we know that if these features are not supported by the compiler, then there's simply no point in even trying to build the test program. The main advantages being: * Faster compile times - build configuration uses lightweight tests the results of which are also cached. * Less noise in build output - there's no reason to be faced with pages of template instantiation backtrace if we know the file can never compile anyway. * Less noise in the online test results - the test will show up as blank, rather than as a fail in the online test matrix. * A better experience for end users building all of Boost, if those libraries which can not be built for the current target compiler are simply skipped, rather than generating pages of error output. Returning to our example, the test case is probably executed in it's Jamfile via the "run" rule: run test_constexpr_128.cpp ; We now need to make this target conditional on the necessary features. We can do that by first importing the necessary rule at the start of the Jamfile: import path-to-config-lib/checks/config : requires ; Assuming that the test case is in the usual directory: libs/yourlib/test then the import rule will actually be: import ../../config/checks/config : requires ; Then add a "requires" rule invocation to the requirements section of the target: run test_constexpr_128.cpp : : : #requirements: [ requires cxx11_constexpr cxx11_user_defined_literals int128 ] ; Notice that multiple arguments can be added to the requires rule, and that these are always the same as the Boost.Config macro name, but in lower case and with the boost_no_ or boost_has_ prefix removed. When building the above example, you will see at the start of the build process the results of the configuration, for example GCC in C++11 mode gives: - Boost.Config Feature Check: int128 : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_user_defined_literals : yes That's all there is to this handy feature, should at any time you be unsure of the feature-test names you can pass to the "requires" rule, then search for the Boost.Config macro of interest in libs/config/checks/Jamfiles.v2, and the name of the feature check will follow it. And finally, this feature is built around the Boost.Build built in rule check-target-builds which can be used to perform more generalized build-time feature testing. The checks in this library are provided as a convenient shorthand without the need for you to write the test cases yourself. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let me know what you think, and enjoy :-) John.

4 6