- Boost - lists.boost.org

Running Tests with Timeouts
by Axel Ismirlian 07 Jun '14

07 Jun '14

Hello everyone, Is there a way to run all of the tests on all of the test suites with timeouts? Occasionally, I need to run all of the tests on all of the test suites, so I leave them overnight only to find out the next morning that one of them hung forever. Sincerely, -Axel

2 1

Review manager for Boost QVM?
by Emil Dotchevski 06 Jun '14

06 Jun '14

Hello, The QVM library has been in the review queue for a some time waiting for a review manager. I've been receiving occasional support requests from random people, and I remember there was at least some initial interest when I proposed the library years ago, but nobody has volunteered to be the review manager yet. This is a library for working with (Q)uaternions and statically-sized (V)ectors and (M)atrices, it's the kind of high level library that is useful to video game programers working with 3D graphics. It's unique (AFAIK) feature is that it uses a type traits system that allows all library functions to operate on 3rd-party types, making it easy to integrate types from different other math libraries into a single type-safe environment. It also has functions that can map vectors as matrices or matrix rows/columns as vectors, or even present mutable transposed view to any matrix, all without creating temporary objects. The documentation and source code can be found here: http://www.revergestudios.com/boost-qvm/ Anyone takers? :) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 8

[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