September 2012 - Boost - lists.boost.org

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[config] Proposed BOOST_NOEXCEPT_NOTHROW macro
by Beman Dawes 03 Jan '13

03 Jan '13

The three current BOOST_NOEXCEPT* macro variants miss the case where C++03 code has a "throw()" throw-specifier. Classes that derive from standard library exceptions need this to avoid breaking code on C++03 compilers. I'm not enamored with the BOOST_NOEXCEPT_NOTHROW name, so feel free to offer suggestions for alternate names. Here is the full set of macros: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_NOTHROW throw() <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) # define BOOST_NOEXCEPT_EXPR(Expression) false #else # define BOOST_NOEXCEPT noexcept # define BOOST_NOEXCEPT_NOTHROW noexcept <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) noexcept((Predicate)) # define BOOST_NOEXCEPT_EXPR(Expression) noexcept((Expression)) #endif Unless there are objections, I'll commit the changes Wednesday afternoon Eastern US time. --Beman

7 11

Using c++11 features in clang
by Marshall Clow 10 Dec '12

10 Dec '12

In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html I don't know if this should be a FAQ entry for Boost, or for clang. Suggestions/comments/edits welcome. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 3

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[iterator] [property_map] Enhancement proposals
by Louis Dionne 12 Nov '12

12 Nov '12

Dear boost, First of all, let me quickly introduce myself as this is my first post here: I am a 20 years old programming enthusiast with interest for metaprogramming, functional programming and library design. I also have a strong will to contribute to open source projects since I love the philosophy behind it and it is a great way to develop new skills and to work with talented people. The object of this message is to collect feedback on several enhancement proposals I have prepared for two existing libraries: [boost.iterator] [boost.iterator.accessor_iterator] The accessor_iterator is an iterator adaptor that returns a reference to a member of its pointee when dereferenced. I see it as another step in the direction of easier iterator composition, which has helped me writting less code in the past. [boost.iterator.chained_output_iterator] The chained_output_iterator is an iterator adaptor allowing to apply a functional transformation to a value before outputing it into another output iterator. It is much like a function_output_iterator that would forward its result to another output iterator. It allows for cool stuff like creating a pipeline of operations without having to create temporary storage. [boost.property_map] [boost.property_map.accessor_property_map] The accessor_property_map is a property map returning a reference to a member of the key it is given. It is much like the accessor_iterator for property maps. [boost.property_map.chained_property_map] The chained_property_map is a tool for property map composition. It takes two property maps and uses a value in the first one as a key in the second one to perform its put, get, and operator[] operations. [boost.property_map.property_traits] I feel like the boost/property_map/property_map.hpp header is a little bit bloated and not quite as modular as it could be. For now, I propose that we move the code dealing with property_traits into the boost/property_map/property_traits.hpp header and that we provide metafunctions to check for adherence to property map types. By providing an include in the boost/property_map/property_map.hpp header, backward compatibility is maintained and we simply increase modularity. All the code is available on github: https://github.com/ldionne/boost-submissions To see how each class can be used, you may look at the unit tests for the corresponding class. If anything is accepted, I will be pleased to write documentation and examples for the concerned feature and to integrate it into the existing documentation. Looking forward to your feedback, Louis Dionne

2 11

[release][1.52.0] Release Notes
by Daniel James 06 Nov '12

06 Nov '12

Hello everyone, We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ The actual site won't get updated until I run the update script. You can see the release notes so far at: http://www.boost.org/users/history/version_1_52_0.html As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released. thanks, Daniel

9 22

[contract] toward N3351 concepts
by Lorenzo Caminiti 13 Oct '12

13 Oct '12

Hello all, I'm reading N3351: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf It's a bottom-up approach to define concepts starting from what's needed by STL algorithms. So far so good--I like it probably more than C++0x concept proposals--N331 is simpler :) However, N3351 STL design is not fully compatible with the current STL specifications--maybe N3351 is better, more mathematically sound? In N3351, concepts are boolean constants: ``We can define concepts as simple (constant) Boolean expressions. This is useful when building constraints predicated on non-syntactic and non-semantics properties of types.`` So I can implement concepts in C++11 as boolean meta-functions using expression SFINAE to check the requirements and enable_if to disable generic algorithms when the instantiated types don't model the concepts (i.e., the concept's boolean meta-function is false). For example, that's the case for the bool{a== b} and bool{a!=b} expressions of the EqualityComparable concept below. However, N3351 says that axioms should not be checked by the compiler... ``Axioms express the semantics of a concept’s required syntax; they are assumed to be true and must not be checked by the compiler beyond conformance to the C++ syntax. Any additional checking is beyond the scope of the compiler’s translation requirements. The compiler must not generate code that evaluates axioms as preconditions, either. This could lead to program errors if the evaluated assertions have side effects. For example, asserting that distance(first, last) > 1 when the type of those iterators is istream_iterator will consume the first element of the range, causing the assertion to pass, but the algorithm to have undefined behavior.'' So what am I supposed to do with axioms? Do nothing? Axioms are just "comments" that document the semantic? For example: `` concept EqualityComparable<typename T> = requires (T a, T b, T c) { bool { a == b }; bool { a != b }; axiom { a == b <=> eq(a, b); } // true equality axiom { a == a; // reflexive a == b => b == a; // symmetric a == b && b == c => a == c; // transitive } axiom { a != b <=> !(a == b); } // complement }; So, EqualityComparable<T> is true if T 1. has == and != with result types that can be converted to bool 2. == compares for true equality 3. == is reflexive, symmetric, and transitive 4. != is the complement of == However, the compiler can only check the first of these conditions. The rest must be verified through other means (i.e. manually). '' Thanks, --Lorenzo

16 82

[preprocessor] Variadics suggestion
by Kitten, Nicholas 11 Oct '12

11 Oct '12

Hi Folks, First of all, I'd like to say "thank you" to Edward Diener and Paul Mensonides for incorporating variadics support into Boost.Preprocessor, which has been on my wishlist for a long time. In fact, I wanted it badly enough that I've been using my own slightly modified version of the library assuming variadics for a while now, and I was interested to see what a cross-platform version would look like (mine was only tested on MSVC). I think the chosen approach of converting variadics to non-variadics is probably superior to the breaking algorithm changes I made in my own version, and I would humbly suggest a few more additions in the same spirit. The reason I chose to use variadics in the first place was to simplify the user interface for the common case of manipulating what I'll call a "variadic sequence," (a series of concatenated tuples), which I wanted to look similar to the following: #define FILTER_PARAMETERS (A, int, 3)\ (B, float, 2.0f)\ (C, const char*, "Howdy!") Of course, without variadics you need either a set of macros for each tuple size, or else double parenthesis around each tuple, which becomes even more burdensome when users are also required to parenthesize inner arguments, leading to gems like this one: #define FILTER_PARAMETERS ((A, (TypeConverter<double, float>), (TypeConverter<double,float>())) My solution admitting the preferred format was to replace most private SEQ_*(X) macros with SEQ_*(...), which also required modifying SEQ_ELEM() and SEQ_HEAD() to return (X) instead of X. However, it occurs to me now that a conversion function to go from variadic to regular sequences would've been easier to implement and backwards compatible; see the attached file, which I've tested in basic cases on MSVC 10 and gcc-4.3.4. The usage would be: #define SEQ (a,b,c)(1,2,3,4) BOOST_PP_VARIADIC_SEQ_TO_SEQ( SEQ ) // expands to ((a,b,c))((1,2,3,4)) I'm submitting this because I couldn't find a way to use some combination of TUPLE/VARIADICS and SEQ transformations to do the same thing succinctly, but if I'm just missing something, please let me know. Next, I would suggest having a documented IS_EMPTY(...) function for detecting an empty variadic list. Since is_empty.hpp already exists for single arguments (though undocumented), I would guess the variadic version would look quite similar. My own (MSVC) version is attached. Finally, I would suggest using the preceding IS_EMPTY(...) function to allow VARIADIC_SIZE(...) to return 0, i.e. something along the lines of: # define BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_IIF( BOOST_PP_IS_EMPTY(__VA_ARGS__), 0, BOOST_PP_VARIADIC_SIZE_I( __VA_ARGS__ ) ) where BOOST_PP_VARIADIC_SIZE_I is the current definition of BOOST_PP_VARIADIC_SIZE. Thanks, -Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

9 29

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10