- Boost - lists.boost.org

[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

boost::aligned_storage broken on VC12 for alignment values of 8
by Glen Fernandes 24 Apr '14

24 Apr '14

Very surprising, but easily reproducible with VC12 (2013), Release or Debug configuration, Win32 platform: the following program will often* throw: #include <boost/type_traits/aligned_storage.hpp> #include <cstdint> int main() { boost::aligned_storage<8, 8>::type a; if (((std::uintptr_t)&a % 8) != 0) { throw 1; } } * Four of every five times it failed because the storage was only 4-byte aligned, not 8-byte aligned. Does not reproduce for x64 builds, just x86 builds. Does not reproduce with alignment values other than 8. Glen

4 7

Regression test relying on undefined compiler behavior (c++11)
by Chris Cooper 24 Apr '14

24 Apr '14

libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). See discussion here: http://stackoverflow.com/questions/23250651/strange-behavior-with-c-recursi… In addition, it looks like the existing code also relies on the compiler filling the vacated bits with one’s, which I don’t think is what actually happens. The solution I’ve come up with, is to do the shifting using unsigned values, thus avoiding the compiler no-no, and then putting the result back in the specified type. In other words, replacing line 73 BOOST_STATIC_CONSTANT(Number, min = Number(Number(prev::min) << CHAR_BIT)); With BOOST_STATIC_CONSTANT(Number, min = boost::detail::is_signed<Number>::value ? (Number)(((unsigned long)(prev::min) << 8) | 0x00FF) : Number(Number(prev::min) << CHAR_BIT) ); I’m using constants ‘8’ and ‘0x00FF’ rather than CHAR_BIT since the code would get really ugly if CHAR_BIT != 8. Thoughts? Thanks, Chris

3 5

Fwd: [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Antony Polukhin 24 Apr '14

24 Apr '14

2014-04-23 17:33 GMT+04:00 Paul A. Bristow <pbristow(a)hetp.u-net.com>: <...> > > 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? > > Nor am I clear that this namespace bti helps the reader. > > "Through all the examples, we'll assume that the following namespace alias > is in > effect: > > namespace bti = boost::typeind; > > " > > 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 > Agreed: boost::typeindex would be more user friendly. It suggests to the reader which library to look for. Other notes will be also addressed. Thanks for the review! -- Best regards, Antony Polukhin

1 0