- Boost - lists.preview.boost.org

[testing] gcc 4.9 test failures
by Andrey Semashev 27 Apr '14

27 Apr '14

Hi, I'm seeing lots of test failures on BP x86_64 C++11 gcc-4.9.0~c11. http://www.boost.org/development/tests/develop/developer/log.html The test logs don't show any errors. Is it possible to see the complete build log?

2 1

any macro for silencing unused variable warnings?
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Is there in Boost a macro for disabling warnings about unused variables? (In case I intend my variable never to be used). Regards, &rzej

3 2

noexcept BOOST_EXPLICIT_OPERATOR_BOOL
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Although I am not entirely convinced that any not throwing function (except for moves) should be marked as noexcept, I can see that noexcept starts to get into Boost. explicit operator bool appears to be a good candidate, but macro BOOST_EXPLICIT_OPERATOR_BOOL does not offer it. So I have to choose: use the macro or noexcept. Perhaps the macro could be expanded to give an option to add noexcept, but that would spawn two macros (BOOST_EXPLICIT_OPERATOR_BOOL and BOOST_CONSTEXPR_EXPLICIT_OPERATOR_BOOL) into four. Are four macros for almost the same purpose acceptable? Or do I have to abandon the idea of making the operator noeaxcept. Are there any recommendations? Regards, &rzej

2 6

[config] Documentation oversight?
by Mostafa 26 Apr '14

26 Apr '14

Here: http://tinyurl.com/lm2u35f it says that BOOST_NO_NOEXCEPT is deprecated in favor of BOOST_NO_CXX11_NOEXCEPT, yet here: http://tinyurl.com/lggeqcp the reference is defined in terms of the deprecated macros. For consistency and to prevent accidental misuse shouldn't the documentation be referencing the new macros throughout?

1 0

[ublas] FYI: msvc12 compilation errors and some questions
by Adam Wulkiewicz 25 Apr '14

25 Apr '14

Hi, FYI, ublas is broken for MSVC 12 due to the use of constexpr which is not suported by this compiler. I might fix it however I assume there are people who would like to do it. Btw, would you be so kind and answer for some questions? I'm curious about the design. Why BOOST_UBLAS_CPP_GE_2011 library-wide #define is usedto enable fixed_vector<>? This makes it available only on some compilers which allows the users to write non-portable code. Shouldn't Boost libraries use language featureswhen they're available or emulate them rather than enable/disable some functionalities? Especially when it could be easily done, like in this case. Variadic templates may be emulated with Boost.Preprocessor, e.g. see how emplace_back() is implemented in boost::container::vector<> : https://github.com/boostorg/container/blob/develop/include/boost/container/… lines 1309-1380. constexpr may be conditionally used e.g. like this: #ifndefBOOST_NO_CXX11_CONSTEXPR #define CONSTEXPR_OR_STATIC constexpr #else #define CONSTEXPR_OR_STATIC static #endif So I'm wondering was the decision about the design made to push the library towards "pure" C++11? If yes, does this mean that all new features will require C++11? Regards, Adam

2 2

the Boost policy for protecting against "too perfect forwarding"
by Andrzej Krzemienski 25 Apr '14

25 Apr '14

Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constru… In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy. There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads. (1) appears cleaner, but some compilers might not support SFINAE. My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE. I can see Boost.Any just uses SFINAE for this purpose without any check. Are there any compilers supported by Boost that have rvalue references but no SFINAE? Regards, &rzej

3 2

[Graph] Pull request for multiplicities support in brandes_betweenness_centrality
by Javier Dehesa 25 Apr '14

25 Apr '14

I've put a pull request for ticket #9935 https://svn.boost.org/trac/boost/ticket/9935 https://github.com/boostorg/graph/pull/6 Explanations included in the ticket and the pull request. I can try to make the implementation for graph_parallel if this get accepted. -- Javier Dehesa

1 0

lazy_enable_if is not sfinae friendly?
by Hui Li 24 Apr '14

24 Apr '14

I was surprised to find that the following code doesn't compile with boost 1.55, where boost::result_of is itself sfinae friendly. template < typename T > typename boost::lazy_enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type test(int){} template < typename > void test(...) {} struct A{}; // boost::result_of<A(int)> is a valid type that doesn't have a member called "type" int main(int argc, const char * argv[]) { test<A>(0); // test<A>(int) meant to be a substitution failure return 0; } For example, on clang++-3.4 with -std=c++11, I got: clang++-mp-3.4 -std=c++11 -I /opt/local/include/ main.cpp In file included from main.cpp:1: In file included from /opt/local/include/boost/type_traits.hpp:65: In file included from /opt/local/include/boost/type_traits/is_nothrow_move_assignable.hpp:22: /opt/local/include/boost/utility/enable_if.hpp:40:25: error: no type named 'type' in 'boost::result_of<A (int)>' typedef typename T::type type; ~~~~~~~~~~~~^~~~ main.cpp:12:1: note: in instantiation of template class 'boost::lazy_enable_if_c<true, boost::result_of<A (int)> >' requested here typename boost::lazy_enable_if_c< ^ main.cpp:16:1: note: while substituting explicitly-specified template arguments into function template 'test' test(int){} ^ 1 error generated. But if lazy_enable_if_c had been implemented as template <bool B, class T> struct lazy_enable_if_c : T {}; // inherits from T template <class T> struct lazy_enable_if_c<false, T> {}; The above test code would compile fine. However, the current implementation template <bool B, class T> struct lazy_enable_if_c { typedef typename T::type type; // this is what caused the compile error }; template <class T> struct lazy_enable_if_c<false, T> {}; seems to evaluate T::type too soon, and results in a compile error rather than a substitution failure. I wonder if the current implementation is chosen deliberately to disallow use cases like the test code? But I imagine allowing lazy_enable_if etc to be (more) sfinae friendly could be very useful. I was able to find a workaround for the test code: template < typename T > typename boost::enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type::type // when T = A, this is a substitution failure test(int){} Hui

1 0

[assign] Merge request for type disambiguation with C++11
by Ben Pope 24 Apr '14

24 Apr '14

https://github.com/boostorg/assign/pull/3 The merge base was somehow ignored, not sure what happened there, but the set of changes is in the last commit. Ben

5 8

[Bug Report] macro definition has \ followed by spaces
by Walter Bright 24 Apr '14

24 Apr '14

In order for line splicing to work, \ has to be followed by a newline. boost/1.51.0/gcc-4.8.1-glibc-2.17-fb/42097cf/include/boost/spirit/home/classic/utility/rule_parser.hpp line 422 ::BOOST_SPIRIT_CLASSIC_NS::type_of::depend_on_type<__Dummy>(x) ) \

2 2