April 2014 - Boost - lists.preview.boost.org

[graph] Undocumented function bron_kerbosch_all_cliques
by Javier Dehesa 28 Apr '14

28 Apr '14

Looking for clique search algorithms in BGL, I've found out that there exists the function bron_kerbosch_all_cliques, but that there is not documentation for it. The implementation fo the algorithm can be found here http://www.boost.org/doc/libs/1_55_0/boost/graph/bron_kerbosch_all_cliques.… and there is even an example program using it http://www.boost.org/doc/libs/1_55_0/libs/graph/example/bron_kerbosch_print… Also, it seems to define a "clique visitor" concept that is not documented either. Is there any reason for it? Maybe there is some problem with the implementation? Or is it just missing documentation? I've run some toy examples and it seems to work, but I can't tell if there would be a problem with large graphs. -- Javier Dehesa

2 1

Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 27 Apr '14

27 Apr '14

On 23 Apr 2014 at 14:33, Paul A. Bristow wrote: > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: but I > don't have any much better ideas. Perhaps someone else has? To clarify the issue to everyone else, TypeIndex is in a rather unusual bind with regard to what namespace to use. Ideally I think we'd all agree that boost::type_index would be best, but then one of the issues raised last peer review was that there shouldn't be a boost::type_index type as could conflict with std::type_index, and if we hold that to be wise, then surely the same rationale applies for a boost::type_index namespace as well. So we end up with boost::typeind, which I don't think makes anyone happy, but it is safe. > IMO, the frequency of use of the namespace bti is probably so low that spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable Noted. > > 8. Do you think the library should be accepted as a Boost library? > > Yes. Thanks Paul for the vote and quick turnaround. I was worried that the review announcement had got lost. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 7

[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