February 2007 - Boost - lists.preview.boost.org

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

[Ann] Variadic Templates
by Doug Gregor 20 Aug '07

20 Aug '07

Hello Fellow Boosters, I have just completed implementing support for "Variadic Templates" in GCC. Variadic templates are C++ templates that can accept any number of "extra" template arguments, just like a function that uses C-style varargs (with "...") can accept any number of extra arguments. Unlike C varags, however, variadic templates work both for class templates and function templates, and are completely type-safe. Why do variadic templates matter for Boost? For one thing, they will allow us to eliminate the use of preprocessor metaprogramming in many, many places throughout the library. This can simplify our library implementations drastically, and eliminate those annoying "caps" on the number of arguments one can use (ever tried to use bind () with 11 arguments?). Beyond that, variadic templates are just plain fun, and there are undoubtedly a great number of metaprogramming applications. Here are a few teasers to illustrate what variadic templates can do: We can implement an MPL-like type vector with one line of code: template<typename... Types> struct vector { }; The "ellipsis" means that we can pack any number of arguments into the "template parameter pack" called Types. Of course, we can do the same for MPL's vector_c: template<typename T, T... Values> struct vector_c { }; Unimpressed? Here's an implementation of tuple that accepts any number of element types: template<typename... Values> class tuple; template<> class tuple<> { }; template<typename Head, typename... Tail> class tuple<Head, Tail...> : private tuple<Tail...> { protected: Head m_head; }; We're using recursion to build up the tuple. The ellipsis operator works with partial specializations, too, packing together "extra" arguments at the end. Of course, all of this would be useless if we couldn't write some of the other tuple operations, like operator==: inline bool operator==(const tuple<>&, const tuple<>&) { return true; } template<typename T, typename... TTail, typename U, typename... UTail> bool operator==(const tuple<T, TTail...>& t, const tuple<U, UTail...>& u) { return t.head() == u.head() && t.tail() == u.tail(); } Variadic function templates can accept any number of function arguments, so we can now (finally!) implement a type-safe printf() without mangling the tried-and-true printf() syntax or restricting ourselves to POD types: void printf(const char* s) { while (*s) { if (*s == '%' && *++s != '%') throw std::runtime_error("invalid format string: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printf(const char* s, const T& value, const Args&... args) { while (*s) { if (*s == '%' && *++s != '%') { std::cout << value; return printf(++s, args...); } std::cout << *s++; throw std::runtime_error("extra arguments provided to printf"); } I've also built prototypes of of Function and Bind, among other things. The Bind example is especially interesting, and worth a read (see below) Interested? There is more information and a complete implementation in GCC available at: http://www.generic-programming.org/~dgregor/cpp/variadic- templates.html I've written two documents describing variadic templates in more detail: http://www.generic-programming.org/~dgregor/cpp/brief-intro.pdf : A brief introduction to variadic templates, that walks through the printf() implementation. http://www.generic-programming.org/~dgregor/cpp/variadic- templates.pdf : A complete proposal to introduce variadic templates into C++0x. This contains annotated versions of the tuple, function, and bind prototypes along with a detailed description of the capabilities of variadic templates. The GCC implementation is complete, supporting all of the features described in the proposal. I've used it for proof-of-concept implementations of several libraries. In the (near) future, I hope to introduce variadic templates support into the "official" GCC, but I need your help! Are variadic templates worthwhile? Will they help us build better, cleaner Boost libraries in the future? Should we bring variadic templates to the C++ committee, to enable better implementations of TR1 components and eliminate the need for much of the preprocessor metaprogramming we do today? Feedback is greatly appreciated. Cheers Doug Gregor Open Systems Lab @ Indiana University

20 39

Review Request: Boost Exception
by Emil Dotchevski 07 Jul '07

07 Jul '07

I believe the proposed Boost Exception library is now mature enough for formal review. Please read the documentation at: http://www.revergestudios.com/boost-exception/boost-exception.htm Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8: http://www.revergestudios.com/boost-exception/boost-exception.zip Regards, Emil Dotchevski

7 21

[BGL] Adapter from bidirectional to undirected graph
by Benoit 05 Jul '07

05 Jul '07

Hello everyone, I have been using the BGL for quite some time with both directed and bidirectional graphs (with adjacency_list). Sometimes i need to use these graphs in algorithms as if they were undirected... AFAICT, this is currently not possible because out_edges() exists in all cases, but don't do the same... The obvious solution consists in writing a dedicated adapter used for translating a bidirectional graph into a directed one at least for out_edges(), and optionally for other stuff (internal properties, vertex and edge descriptors?) to make this subtle change as transparent as possible. Can you think of another way ? Is there already such an adapter somewhere (i have unsuccessfully tried to find one...) ? In case it didn't exist, would anyone else be interested to have one ? Benoît PS : I'd like to thank the authors of the BGL, it's a pleasure to work with it everyday !

3 2

bug in 1.35's sp_counted_base_gcc_sparc.hpp
by Jerry Lawson 28 Apr '07

28 Apr '07

The cas _asm_ instruction for the gcc/sparc environment has a slight flaw: it does not prevent the gcc compiler from generating assembly that contains a invalid register/offset. In other words, the existing _asm_ can cause gcc to generate something like: cas [%i0+80], %i1, %i2 the relative offset is an illegal address mode for cas instruction. I'm not a sparc assembly guy, by any stretch of the imagination, but doing some reading at http://blogs.sun.com/wesolows/entry/gcc_inline_assembly_part_2 would seem to indicate that this code: inline int32_t compare_and_swap( int32_t * dest_, int32_t compare_, int32_t swap_ ) { __asm__ __volatile__( "cas %0, %2, %1" : "+m" (*dest_), "+r" (swap_) : "r" (compare_) : "memory" ); return swap_; } is not exactly correct. When using -O3 optimization option to gcc, the aforementioned "bad" cas instruction is generated. Base upon how much code there is surrounding the call to compare_and_swap(), different combinations of register allocation occurs and may or may not hide this problem. I'm done some experimenting and with the following code, gcc seems to generate the proper code: inline int32_t compare_and_swap( int32_t * dest_, int32_t compare_, int32_t swap_ ) { __asm__ __volatile__( "cas [%2], %3, %0" : "=&r" (swap_) : "0" (swap_), "r" (dest_), "r" (compare_) : "memory" ); return swap_; } Somebody with more experience in sparc should look this over. If it's good (or a better way), it would be nice to get it into the next version of boost that contains support for boost/detail/sp_counted_base_gcc_sparc.hpp. Jerry Lawson

2 4

[XML] Searching for an XML parsing library in boost
by Shibu Bera 29 Mar '07

29 Mar '07

> I would like to know, > if any library for parsing XML file is available in boost or not. > I srearched in the boost.org site for the same but, >I cound't get any library as such. >If library is present, please let me know the details. >If not, please allow me to know, if any work is going in the concern topic. Thank you, -- Regards, Shibu

12 46

[multiarray] storage_order_convert.cpp
by David Abrahams 25 Mar '07

25 Mar '07

This test file isn't listed in the Jamfile, and thus is never run. Intentional? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[futures] composite or
by Sohail Somani 20 Mar '07

20 Mar '07

Hi, I was looking at the futures implementation in the boost vault. It looks very promising, I must say. One of the open issues however is thread cancellation which I imagine will be important in the case of the "or" futures group. Has there been any progress on this front? One of the coolest things about boost libraries has been the gradual improvement of legacy C/C++ code by non-invasive means. I can't imagine solving this problem without invasive means (or traditionally undesirable means, i.e. something like thread->die()). I'm not saying that its non-invasive or nothing, but there are people smarter than me working on this problem! Thanks in advance, Sohail

15 91

[floating point utilities] Review request
by Johan Råde 19 Mar '07

19 Mar '07

This is a request for a formal review of the Floating Point Utilities library. The library contains the following: 1. Floating point number classfication functions: fpclassify, isfinite, isinf, isnan, isnormal (Follows TR1) 2. Sign bit functions: signbit, copysign, changesign (Follows TR1) 3. Facets that format and parse infinity and NaN according to the C99 standard. (These can be used for portable handling of infinity and NaN in text streams.) The library is available in the vault in the folder Math-Numerics. --Johan Råde

3 9