June 2014 - Boost - lists.boost.org

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