- Boost - lists.preview.boost.org

[modularization] First goal clarification: have a DAG dependency graph?
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

Hi, I would like what is the first goal of the modularization changes we are doing. IMO, the first one is to have modules that don't have dependency cycles, that is they form a DAG. Reducing the dependencies could be done later on, once we don't have cycles. The next conflicting cycle is Level 3 1/2 mpl - config core predef preprocessor static_assert type_traits utility type_traits - config core mpl preprocessor static_assert typeof utility typeof - config core mpl preprocessor type_traits utility - config core mpl preprocessor static_assert throw_exception type_traits If declval moves from utility to type_traits we break the type_traits->utility dependency. Could we extract *temporally* common_type to a specific module? These break the type_traits -> typeof dependency and the type_traits I say temporary because once all the changes are done to avoid the cycles, we can start looking for better ways to organize the modules preserving always the DAG structure. If we admit these changes we have to resolve this cycle type_traits<=>mpl. We need surely to add every thing that allows to define a trait to either to TypeTraits or to Core without using MPL of course. However in order to see clearer on the dependencies that must be broken to avoid this cycle, could these new file-to-module associations be applied? Best, Vicente

1 0

(no subject)
by Leif Reichert 08 Jun '14

08 Jun '14

1 0

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

07 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. [Dave Gomboc]: > 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. [Andrey Semashev]: > I think a tag would be a better alternative to a SHA. It's more readable and > GitHub creates a downloadable archive for it so git is not required to review > the library. Sure, using a tag would be great. (I wasn't aware that GitHub had that additional functionality.) Mainly, I have concern that Boost might adopt a procedure whereby committing to master is not permitted during a review. I want to discourage the mindset that changes can't be committed to their logical place (or even at all) just because a review is currently underway, and so tried to show that it is not difficult to avoid such an encumberance. Dave

1 0

[Trac] Adding modules Core, Detail, Sync
by Vicente J. Botet Escriba 07 Jun '14

07 Jun '14

Hi, could we create Component entries on the Trac system for Core -> ?? Detail -> ?? Sync -> Andrey Semashev Vicente

2 1

[core] Breaking bugfix in scoped enums
by Andrey Semashev 07 Jun '14

07 Jun '14

Hi, While creating tests for scoped enums emulation I've fixed a bug which resulted in the enums being convertible to int. This is a potentially breaking change, the code like this will now not compile: BOOST_SCOPED_ENUM_DECLARE_BEGIN(color) { red, green, blue } BOOST_SCOPED_ENUM_DECLARE_END(color) void foo(boost::native_type<color>::type col); color col = color::blue; foo(col); The call to foo() should be done like this: foo(boost::native_value(col)); Previously, the conversion was implicit.

4 7

[pimpl] Some comments
by Andrzej Krzemienski 07 Jun '14

07 Jun '14

Hi Vladimir, My congratulations on the success of Boost.Convert. But I can see you will not have much time to celebrate it, next library waiting in the queue. I wanted to share some of my thoughts on Boost.Pimpl library. This is by no means a review. I am not sure if I will have time to do a decent one. I only skipped through the documentation so my understanding is superficial, but I noticed some things that raise my immediate objection. Boost.Pimpl has been around for a while now, and I remember I was using it at some point in my work, although it didn't have the nice documentation format at that time. [1] The main point in using pimpl idiom (at least my) is to avoid header inclusion, which may grow compilation time too much (at the expense of certain run-time cost). But in order to use Boost.Pimpl I do need to include a header file, which in turn includes more header files. This is arguably less headers that in normal non-pimpl implementation, but it is more than if I used a raw pointer. And this is what I finally did in my work: switched to raw pointers for implementing piml in order to get the build perform faster. (I didn't measure the improvement though.) [2] Boost.Pimpl is good for everyone: people who like value semantics get the value semantic interface, and people who like shated_ptr's get shared_ptr semantics. Call me selfish or biased, but I believe using shared_ptr's should be banned (at least in 90% of the cases where it is currently being used), and the fact that you advertise it first in the docs makes me uneasy. It looks from the docs that 'pointer_semantics' implements something like a flyweight. This is so against value semantics. One of the expectations of types returned by value is that changing the original does no affect the copy: T a = c; T b = c; zap(a); assert(b==c && a!=b); Although the author of class Book knows that it is implemented with pointer_semantics, the users of the class are likely not to know it, and since Book doesn't look like a pointer, they will be expecting value semantics, and will be severely punished. [3] The docs advertize the definition of operator== as a member function. This is against a typical recommendation that it should be a free function in order to avoid asymmetrical behavior in certain cases. Does your library allow the definition of a non-member operator==? If so, I would encourage you to reflect that in the docs. [4] This page: http://yet-another-user.github.io/boost.pimpl/the_boost_pimpl_library/pimpl… says "The advantage of the 'built-in' *Book::null()* [...] is that it makes possible an implementation of strongly exception-safe constructors, the copy constructor" There seems to be something wrong with this statement. How can a strong (commit-or-rollback) guarantee apply to constructors? If an exception is thrown from constructor the object is never created or accessible, so no-one cares about its state (as long as it doesn't leak). Or did you mean the no-throw guarantee? But the latter looks like an anti pattern. What is the value in concealing the exception (and information it carries) and instead produce null objects, which cannot be used? While I find the value_semantics interface useful, I am strongly against even offering the pointer_semantics interface. I am not sure if I have succeeded in explaining why. Regards, &rzej

8 15

[modularization] Extracting lexical_cast from conversion
by Vicente J. Botet Escriba 07 Jun '14

07 Jun '14

Conversion depends on Math and Range due to lexical_cast. /math/ <http://www.pdimov.com/tmp/report-6d1f271/math.html> |<boost/math/special_functions/fpclassify.hpp>| * from |<boost/lexical_cast.hpp>| |<boost/math/special_functions/sign.hpp>| * from |<boost/lexical_cast.hpp>| /range/ <http://www.pdimov.com/tmp/report-6d1f271/range.html> |<boost/range/iterator_range_core.hpp>| * from |<boost/lexical_cast.hpp>| |Extracting LexicalCast allows to break these cycle|s Conversion -> Math -> Conversion -> Range -> Conversion Best, Vicente P.S. This dependencies have been introduced lately while trying to make the implementation more efficient.

5 4

HTTP SERVER 2 Question!
by zyf01234＠gmail.com 07 Jun '14

07 Jun '14

I'm trying to test the HTTP SERVER 2 of the boost.asio samples. some question comes to my mind,so can anyone give me a hand? Q1. The code acceptor_(io_service_pool_.get_io_service()) means get one io_service from the pool , but to this application only one acceptor is created and one io_service is running? Q2 It takes about 25% of the CPU occupancy rate , this is caused by the Q1? zyf01234(a)gmail.com

2 1

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

[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

[Modularization] Breaking dependecy Range -> Algorithm
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Range depends on Algorithm due to these files /algorithm/ <http://www.pdimov.com/tmp/report-6d1f271/algorithm.html> |<boost/algorithm/string/config.hpp>| * from |<boost/range/detail/collection_traits.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| |<boost/algorithm/string/yes_no_type.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| * | boost/algorithm/string/yes_no_type.hpp could be moved to TypeTraits|| boost/algorithm/string/config.hpp| could be moved to Config Best, Vicente

1 0

GitHub is slow
by Andrey Semashev 05 Jun '14

05 Jun '14

For the couple past days I'm seeing problems working with GitHub. I can't complete the full update of Boost repository multiple times in a row: ... Fetching submodule libs/regex ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/scope_exit Fetching submodule libs/serialization ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/signals Fetching submodule libs/signals2 Fetching submodule libs/smart_ptr Fetching submodule libs/spirit Fetching submodule libs/statechart Fetching submodule libs/static_assert Fetching submodule libs/sync Fetching submodule libs/system Fetching submodule libs/test Fetching submodule libs/thread Fetching submodule libs/throw_exception Fetching submodule libs/timer ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tokenizer Fetching submodule libs/tr1 Fetching submodule libs/tti ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tuple ... Don't mind the particular libraries, they are different every time. I'm also seeing occasional timeouts in web interface. I've seen these problems from two different places, so it's not my local connection. Is anyone seeing this too?

1 0

Boost.Pimpl upcoming formal review (June 15 - June 24)
by Glen Fernandes 05 Jun '14

05 Jun '14

The formal review period of Boost.Pimpl by Vladimir Batov is scheduled to begin later this month, on June 15th, and will conclude on June 24th, and we welcome your participation. Vladimir's library provides a mechanism for implementing this popular, and still very relevant, idiom. To borrow his words from the documentation: [quote] In the domain of commercial large-scale software development the following design principles come to the fore: - component-based, modular and API-centered design, - separation of concerns, - implementation hiding, - minimization of compilation and component dependencies, - consistent and recognizable deployment and implementation patterns, multi-platform support. The Pimpl idiom can help great deal achieving those goals. It is a simple yet robust programming technique to minimize coupling via the separation of public interface and private implementation and then implementation hiding. [/quote] Please feel encouraged to browse the source code, documentation, and tests, before the review commences. Any feedback you have prior to the review period is also very appreciated. Source: https://github.com/yet-another-user/boost.pimpl/ Documentation: http://yet-another-user.github.io/boost.pimpl/ Download: https://github.com/yet-another-user/boost.pimpl/archive/master.zip If you would like to submit a review earlier, please provide your thoughts on the following topics: - 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? As well as information on the following questions: - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Best, Glen

1 0

[quickbook] Thank you Daniel James
by Rene Rivera 05 Jun '14

05 Jun '14

After being very surprised that I could build Predef documentation without errors by onyl updating to the latest develop version of Quickbook I had to thank Daniel James. Thank Daniel for the continued work on Quickbook. It's made my life much, much, easier! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

8 12

Moving utility/declval.hpp to type_traits
by Peter Dimov 05 Jun '14

05 Jun '14

I was going to move utility/declval.hpp to type_traits, but type_traits has many unmerged changes. Since the contents of declval.hpp are currently the same in master and develop, replaying its history on top of type_traits:master and type_traits:develop should not affect any later merges, but still, I always prefer to do this when master and develop are identical, so thought I'd ask first. John?

2 2