January 2014 - Boost - lists.boost.org

The Community Maintenance Team proposal accepted
by Beman Dawes 14 Jan '14

14 Jan '14

The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader. See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal. Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone. --Beman

14 23

[git] nit in library release documentation
by Peter A. Bigot 14 Jan '14

14 Jan '14

At https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea… there is: git tag -a mylib-1.2.0 git push --tags mylib-1.2.0 # specific tag pushed to avoid pushing all local tags As discussed in a thread on module tagging, --tags should never be used with git push as it pushes all local tags to the remote repository (adding those that did not exist there). There are cases where you might want to do that, but for the specific situation of releasing a tagged library a sufficient and less risky command is: git push mylib-1.2.0 # specific tag pushed to avoid pushing all local tags Peter

2 1

Re: [boost] Is there interest in a collection of call stack utilities?
by Aurelian Melinte 14 Jan '14

14 Jan '14

Hello, To follow up on the discussion https://groups.google.com/forum/#!topic/boost-developers-archive/PSwTBEEe0Ao I was not clear if there is interest for it or not. I went ahead and the first cut of the code is now at https://github.com/melintea/Boost-Call_stack Please feel free to take a look and comment. Regards, Aurelian

6 7

Getting Started with Modular Boost Library Maintenance
by Gly Marvellou 14 Jan '14

14 Jan '14

1 0

Removing support for old compilers
by Joaquin M Lopez Munoz 14 Jan '14

14 Jan '14

Hi Stephen As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I understand this should be inserted in a prominent place on the Boost 1.56 release notes and can serve as a reference for lib maintainers reviewing your patches (tracking changesets is harder and commit messages are not always completely illuminating). Thank you, Joaquín M López Muñoz Telefónica Digital

16 51

[Thread] Doc bug?
by Alexander Lamaison 14 Jan '14

14 Jan '14

The docs [1] for the `scoped_thread` and `strict_scoped_thread` says > "While thread call std::terminate() on the destructor is the thread is > joinable, strict_scoped_thread<> or scoped_thread<> join the thread if > joinable. Several other places on the page say something similar. I was under in the impression that Boost.Thread had toyed with adopting this behaviour to match `std::thread` but decided against it after complaints on this list. Am I wrong? [1] http://www.boost.org/doc/libs/1_55_0/doc/html/thread/ScopedThreads.html Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

3 3

[range] flat_array_view feature request.
by Mostafa 14 Jan '14

14 Jan '14

I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think? Mostafa

5 7

[block_ptr] & Java
by Phil Bouchard 14 Jan '14

14 Jan '14

Hello everyone, In a quest to speed up my Android applications and knowing Java is written in C++, I decided to discuss with the OS community openjdk.java.net to try to introduce them block_ptr. But the conversation was dead in the water probably due to the lack of developers. So I just have questions: - Does anybody know if Java uses Boost? - block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it? Sincerely, -Phil Experiment proposal to refute Special Relativity for the interested: http://finitetheory.com/files/experiment.pdf

11 39

[predef] [rfc] Mutually exclusive definitions?
by Rene Rivera 13 Jan '14

13 Jan '14

After going back and re-reading various commentaries for the review of Boost.Predef and some after the review I'm questioning a design choice of Boost.Predef. Currently Boost.Predef will define multiple symbols when, for example, a compiler "emulates" another compiler. The current common occurrence of this is the GCC compiler which many other compilers emulate by defining the GCC version macros. This is no longer the case for the OS definitions though. The OS definitions are mutually exclusive. And hence in order to make for a more consistent behavior I am considering changing the library to make not just OS defs mutually exclusive. But also making compiler, library, and architecture mutually exclusive. And I'm asking for some general feedback as to what the most useful approach, from using Boost.Predef, is likely to be. In particular I'm considering the following choices: 1. Simple mutual exclusion of BOOST_ARCH_*, BOOST_COMP_*, BOOST_LIB_C_*, BOOST_LIB_STD_*, and of course BOOST_OS_* definitions. 2. Mutual exclusion of the base/real definitions with the addition of *_EMULATED definitions when multiple defs detected. For example for GCC we would have BOOST_COMP_GCC_EMULATED indicated the version of the GCC being emulated. 3. No mutual exclusion of base definitions but with the addition of a "flag" definition when multiple defs are detected. For example with GCC it would have the usual BOOST_COMP_GCC but also have a "#define BOOST_COMP_GCC_IS_EMULATED". 4. Do nothing and live with multiple definitions and the current discrepancy in behavior for BOOST_OS definitions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[TypeTraits] propose new callable-type call traits
by Hui Li 13 Jan '14

13 Jan '14

I've implemented a few traits classes (code attached below) that, for a given callable-type T, and a set of Args..., detects whether the function call T::operator()(Args...) would be (1) valid, (2) ambiguous, or (3) none is viable. where T is allowed to have arbitrary overloaded operator()'s. This could be useful for programmers who want to (1) make the function call only when it's valid, (2) generate customized error/warning messages when it's ambiguous, or handle/redirect it without getting an ambiguous compiler error, and (3) redirect non-viable calls to some default behavior, which can be different than how it's handled when the call is ambiguous. If people are interested, I suppose this could be a useful addition to TypeTraits. I would appreciate any feedback! For clarity, the implementation and demonstration attached below is written in c++11. It can be easily ported to c++98/03 compilers by using TypeTratis to replace the std type traits, BOOST_TYPEOF_KEYWORD to replace decltype, and Boost.Preprocessor to generate code for arbitrary arity. - Hui Li #include <utility> #include <type_traits> template < typename T > struct is_callable; template < typename Signature > struct has_valid_call; template < typename Signature > struct has_ambiguous_call; template < typename Signature > struct has_no_viable_call; template < typename T > struct is_callable { struct yes {}; struct no {}; struct ambiguate_seed { void operator()(); }; template < typename U, bool=std::is_class<U>::value > struct ambiguate : U, ambiguate_seed {}; template < typename U > struct ambiguate<U,false> : ambiguate_seed {}; template < typename U, typename = decltype(&U::operator()) > static constexpr no test(int); template < typename > static constexpr yes test(...); static bool constexpr value = std::is_same<decltype(test< ambiguate<T> >(0)),yes>::value ; typedef std::integral_constant<bool,value> type; }; template < typename T, typename... Args > struct has_valid_call< T(Args...) > { struct yes {}; struct no {}; template < typename U, bool = is_callable<U>::value > struct impl { template < typename V, typename = typename std::result_of<V(Args...)>::type > struct test_result { using type = yes; }; template < typename V > static constexpr typename test_result<V>::type test(int); template < typename > static constexpr no test(...); static constexpr bool value = std::is_same<decltype(test<U>(0)),yes>::value; using type = std::integral_constant<bool, value>; }; template < typename U > struct impl<U,false> : std::false_type {}; static constexpr bool value = impl<T>::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_ambiguous_call< T(Args...) > { struct ambiguate_seed { void operator()(...); }; template < class U, bool = is_callable<U>::value > struct ambiguate : U, ambiguate_seed { using ambiguate_seed::operator(); using U::operator(); }; template < class U > struct ambiguate<U,false> : ambiguate_seed {}; static constexpr bool value = not has_valid_call< ambiguate<T>(Args...) >::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_no_viable_call< T(Args...) > : std::integral_constant<bool, not (has_valid_call<T(Args...)>::value or has_ambiguous_call<T(Args...)>::value)> {}; #include <string> #include <vector> struct test { void operator()(int); void operator()(double); void operator()(int,double); template < typename T > typename std::enable_if< not std::is_integral<T>::value >::type operator()(const T&, int=0){} template < typename T > typename std::enable_if< std::is_integral<T>::value >::type operator()(const std::vector<T>&, T*){} template < typename T > int operator()(const std::string&, int){} }; int main(int argc, const char * argv[]) { static_assert( is_callable<test>::value , ""); static_assert( not is_callable<int>::value , ""); static_assert( has_valid_call<test(char const*,long)>::value , ""); static_assert( has_valid_call<test(std::string&,long)>::value , ""); static_assert( has_valid_call<test(std::vector<int>, int*)>::value , ""); static_assert( has_no_viable_call<test(std::vector<double>, double*)>::value , ""); static_assert( has_valid_call<test(int)>::value , ""); static_assert( has_valid_call<test(int,double)>::value , ""); static_assert( not has_valid_call<test(int,double,int)>::value , ""); static_assert( not has_ambiguous_call<test(double)>::value , ""); static_assert( has_ambiguous_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(int)>::value , ""); static_assert( has_no_viable_call<test(void)>::value , ""); return 0; }

5 16