- Boost - lists.preview.boost.org

[type_traits] Proposal: same_xxx
by Adam Wulkiewicz 09 Jun '14

09 Jun '14

Hi, Recently I found some use for a tool adding const to a type if some other type is const. My use case was something like this: typename const_conformant < Range, typename boost::range_value<Range>::type >::type ... I'm guessing that such use cases are quite common, not only for const but also other qualifiers. Do you think that a family of traits adding or removing qualifiers based on the qualifiers of some other type could be a useful addon to the TypeTraits? E.g.: same_const<BaseT, T> same_cv<BaseT, T> same_pointer<BaseT, T> same_reference<BaseT, T> same_rvalue_reference<BaseT, T> same_volatile<BaseT, T> same_extents<BaseT, T> //etc. Regards, Adam

4 5

Let's not forget the release
by John Maddock 09 Jun '14

09 Jun '14

The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying... John.

10 15

[atomic]
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, there is a regression on Boost.Atomic on a lot of compilers. See regression test on Boost.Thread http://www.boost.org/development/tests/develop/developer/thread.html synchronized_value__default_ctor_p <https://github.com/boostorg/thread/blob/develop/test/sync/mutual_exclusion/…> Please, could Time or Ardrey take care of this issue? Best, Vicente Test output: jasonr-Ubuntu13.10-gcc - thread - synchronized_value__default_ctor_p / gcc-4.8.1 Rev cfaf6902e696a50a8f8c81510e676aaa547c7706 / Sun, 08 Jun 2014 00:02:00 +0000 Compile [2014-06-08 04:29:08 UTC]: fail "g++-4.8" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -pthread -fPIC -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/hd/boosttest_new/results/boost/bin.v2/libs/thread/test/synchronized_value__default_ctor_p.test/gcc-4.8.1/debug/threading-multi/sync/mutual_exclusion/synchronized_value/default_ctor_pass.o" "../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp" In file included from ../boost/atomic/detail/atomic_template.hpp:25:0, from ../boost/atomic/atomic.hpp:22, from ../boost/atomic.hpp:12, from ../boost/thread/testable_mutex.hpp:14, from ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:15: ../boost/atomic/detail/union_cast.hpp: In instantiation of ???union boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]::<anonymous>???: ../boost/atomic/detail/union_cast.hpp:36:5: required from ???To boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]??? ../boost/atomic/detail/atomic_template.hpp:355:92: required from ???boost::atomics::detail::base_atomic<T, void>::value_type boost::atomics::detail::base_atomic<T, void>::load(boost::memory_order) const volatile [with T = boost::thread::id; boost::atomics::detail::base_atomic<T, void>::value_type = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:697:27: required from ???boost::atomics::atomic<T>::operator boost::atomics::atomic<T>::value_type() const volatile [with T = boost::thread::id; boost::atomics::atomic<T>::value_type = boost::thread::id]??? ../boost/thread/testable_mutex.hpp:113:30: required from ???bool boost::testable_mutex<Lockable>::is_locked() const [with Lockable = boost::mutex]??? ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:24:7: required from here ../boost/atomic/detail/union_cast.hpp:34:12: error: member ???boost::thread::id boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]::<anonymous union>::as_to??? with constructor not allowed in union To as_to; ^ ../boost/atomic/detail/union_cast.hpp:34:12: note: unrestricted unions only available with -std=c++11 or -std=gnu++11 ../boost/atomic/detail/union_cast.hpp: In instantiation of ???union boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]::<anonymous>???: ../boost/atomic/detail/union_cast.hpp:36:5: required from ???To boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:337:137: required from ???boost::atomics::detail::base_atomic<T, void>::base_atomic(const value_type&) [with T = boost::thread::id; boost::atomics::detail::base_atomic<T, void>::value_type = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:687:101: required from ???boost::atomics::atomic<T>::atomic(boost::atomics::atomic<T>::value_arg_type) [with T = boost::thread::id; boost::atomics::atomic<T>::value_arg_type = const boost::thread::id&]??? ../boost/thread/testable_mutex.hpp:47:40: required from ???boost::testable_mutex<Lockable>::testable_mutex() [with Lockable = boost::mutex]??? ../boost/thread/synchronized_value.hpp:431:14: required from ???boost::synchronized_value<T, Lockable>::synchronized_value() [with T = int; Lockable = boost::testable_mutex<boost::mutex>]??? ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:23:76: required from here ../boost/atomic/detail/union_cast.hpp:35:14: error: member ???boost::thread::id boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]::<anonymous union>::as_from??? with constructor not allowed in union From as_from; ^

1 0

How to identify sub-libraries/modules of a library?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, I would like to separate the following sub-libraries/modules chrono/stopwatches and thread/executors. Could someone point me where can I find the things to do to split a library in submodules? How to identify them? How to have separated regression test pages? What the new boostdev tool needs? ... Best, Vicente

4 4

[modularization] Removing iterator->conversion dependency
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, in order to remove the dependency from iterator to conversion I suggest to move |boost/implicit_cast.hpp to MPL. | |Vicente | /conversion/ <http://www.pdimov.com/tmp/report-6d1f271/conversion.html> |<boost/implicit_cast.hpp>| * from |<boost/pending/iterator_tests.hpp>| |//boost/implicit_cast.hpp| |template <typename T> inline T implicit_cast (typename mpl::identity<T>::type x) { return x; } |

6 13

[modularization] removing ConceptCheck ->Parameter dependency
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

I suggest removing the ConceptCheck -> Parameter dependency to move|boost/parameter/aux_/parenthesized_type.hpp| to Boost.Detail. Vicente /parameter/ <http://www.pdimov.com/tmp/report-6d1f271/parameter.html> |<boost/parameter/aux_/parenthesized_type.hpp>| * from |<boost/concept/requires.hpp>|

2 5

Guidelines to implement Boost library evolution policy (was Boost 2.0)
by Beman Dawes 09 Jun '14

09 Jun '14

The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen. Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo The plan is to integrate these guidelines with similar material on the web site in time for the 1.56 release. --The Boost Steering Committee

6 13

[modularization] How to remove the Math -> multuplecission dependency?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, John, ther is a cycle between multuprecision and Math. how can this dependency be removed? /math ->multiprecision/ <http://www.pdimov.com/tmp/report-6d1f271/multiprecision.html> |<boost/multiprecision/cpp_dec_float.hpp>| * from |<boost/math/constants/generate.hpp>| Vicente

4 8

boost::system::error_code and std::error_code
by Vinícius dos Santos Oliveira 09 Jun '14

09 Jun '14

Is there any plans to add a conversion operator from boost::error_code to std::error_code or alike? I was designing a class that I'd like to be usable pleasantly with boost variant of error_code and C++11 variant of error_code, but my design was getting rather complicated (multiple inheritance, templates with no type deduction, ...) and I give up after I came to the make_error_code function, which would be called by the error_code constructor if is_error_code_enum was specialized (which was) and we cannot overload function based on return type (then would be difficult to make it work with boost::system::error_code and std::error_code). TL;DR: What the plans for migration from boost::system::error_code to std::error_code? -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 2

[modularization] Moving <boost/math/common_factor_ct.hpp> to TypeTraits
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, |moving boost/math/common_factor_ct.hpp to TypeTraits would remove the dependency from Interprocess, Pool and Variant to Math. | /interprocess/ <http://www.pdimov.com/tmp/report-6d1f271/interprocess.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/interprocess/allocators/detail/node_pool.hpp>| /pool/ <http://www.pdimov.com/tmp/report-6d1f271/pool.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/pool/pool.hpp>| /variant/ <http://www.pdimov.com/tmp/report-6d1f271/variant.html> |<boost/math/common_factor_ct.hpp>| || * from |<boost/variant/variant.hpp>| Vicente

4 8

core/swap tests appear in core?
by Peter Dimov 08 Jun '14

08 Jun '14

Does anyone know why the core/swap tests, which are in a separate Jamfile, core/test/swap/Jamfile.v2, and have their own line in status/Jamfile.v2, core/test/swap # test-suite core/swap still appear in http://www.boost.org/development/tests/develop/developer/core.html instead of on their own page, core/swap? When they were in utility they did appear on utility/swap: http://www.boost.org/development/tests/develop/developer/utility-swap.html Or, to be more precise, does anyone know how we can make them appear on their own page. :-)

4 5

QVM library
by Emil Dotchevski 08 Jun '14

08 Jun '14

I've updated the QVM library (which hasn't been reviewed yet), including minor changes plus a workaround for what appears to be a parsing bug in msvc-12: http://www.revergestudios.com/boost-qvm/ -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode P.S. Perhaps STL can confirm, I'm guessing that the MSVC bug was introduced by the added rvalue reference support, which interfered with the heuristics MSVC uses to attempt to successfully parse non-conformant code that doesn't use mandatory "typename". This can be seen for example in q.hpp, which used to contain functions like: template <class A,class B> typename enable_if_c< is_q<A>::value && is_q<B>::value, A &>::type operator-=( A & a, B const & b ) which I had to change to: template <class A,class B> typename enable_if< msvc_parse_bug_workaround::quats<A,B>, A &>::type operator-=( A & a, B const & b ) where namespace msvc_parse_bug_workaround { template <class A,class B> struct quats { static bool const value=is_q<A>::value && is_q<B>::value; }; }

2 1

[modularization] chrono/stopwatches
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

Hi, please, could you create a submodule for chrono/stopwatches, or just remove the directory of the files included on the chrono module, as it has not been really released. If this is not possible, I can remove the directory temporarily. Best, Vicente

1 0

[modularization] mpl -> utility dependency
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

The dependency mpl -> utility |<boost/utility/value_init.hpp>| from |<boost/mpl/for_each.hpp>||| |is there just for this line | // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. value_initialized<arg> x; Do we really need to use this value_initialized class to ensure initialization with current compilers? Vicente

2 1

[graph_parallel] Unpushed changes in develop
by Daniel James 08 Jun '14

08 Jun '14

Hi, The develop branch of the super project was manually updated to use a more recent commit that hadn't been pushed to develop. Unfortunately my script for updating the super project doesn't check for this situation and could reset the library to the older version from develop at an arbitrary point (it doesn't normally because it's incremental, but occasionally a non-incremental run will set everything to the current develop branch). So I pushed the current revision to develop. It's just a merge commit that doesn't actually change any code, so I assume it was an oversight that it wasn't pushed. I hope that's okay. Daniel

1 0

[parameter] Literate test, and other changes.
by Daniel James 08 Jun '14

08 Jun '14

Hi, Looking at parameter's history there are three groups of unmerged changes: - "literate" tests extracted from the documentation (plus some small documentation changes) - Stephen Kelly's changes removing workarounds for old compilers - a warning fix - https://github.com/boostorg/parameter/commit/b5e57e0024ae51f5e706eff50e8602… I think they're all okay to merge, although I'm not sure about the literate tests, does anyone know why they weren't merged earlier? They don't show up in the test results, although maybe they're not meant to. Daniel

1 1

Newer dependency report
by Peter Dimov 08 Jun '14

08 Jun '14

http://www.pdimov.com/tmp/report-b932921/module-overview.html http://www.pdimov.com/tmp/report-b932921/module-levels.html

1 0

[Fusion] Heterogeneous comparison rationale?
by Louis Dionne 08 Jun '14

08 Jun '14

Dear list, Is there a reason why Fusion does not support comparing objects of different types? For example, the following will trigger a compilation error inside the library because there is no operator==(int, X): struct X { }; assert(make_vector(1, 2) != make_vector(1, X{})); In the context of programming with heterogeneous types, one could reasonably argue that the above should compile and pass the assertion. Of course, then the library can't use operator== to compare objects internally, but that's an implementation detail. So I'm really looking for a rationale for that design decision and/or comments from people about which way they think it should be and why. Regards, Louis Dionne

1 0

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