- Boost - lists.boost.org

clang failing core/detail_iterator_test?
by Peter Dimov 08 Jun '14

08 Jun '14

Does anyone have any idea why Clang doesn't like detail_iterator_test? As an example, http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64… ../libs/core/test/detail_iterator_test.cpp:79:76: error: no member named 'iterator_category' in 'boost::detail::iterator_traits<iterator<C, T, D, P, R> >' BOOST_TEST_TRAIT_TRUE((is_same<boost::detail::iterator_traits<It>::iterator_category,C>)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ I'm having endless trouble trying to get a version of Clang up and running here (on Windows), as is customary. This: ../libs/core/test/detail_iterator_test.cpp:136:17: error: default initialization of an object of const type 'const T [5]' T const x[ N ]; ^ I know what is about, and I've fixed that already.

4 7

[config][compatibility] limits.hpp documentation
by Daniel James 08 Jun '14

08 Jun '14

I just created a pull request to update the limits.hpp documentation in compatibility. If no one objects I'll merge it soon. But maybe it should be in config since the header is there now.

1 1

Tick: Trait instrospection and concepts library now for C++11
by paul Fultz 08 Jun '14

08 Jun '14

Hi, I've just update the Tick library to support C++11 compilers including support for gcc 4.6: https://github.com/pfultz2/Tick To support gcc 4.6 an additional `TICK_RETURNS` macro was added. So while this can be written for gcc 4.7 or later: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> TICK_VALID( returns<int>(x++) ); }; This can be written in order to support gcc 4.6: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> TICK_VALID( TICK_RETURNS(x++, int) ); }; Of course, the macro is optional and only needed to support older compilers. Any other feedback would be appreciated. Thanks, Paul

3 4

[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