March 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

Boost Logging library - first draft
by JD 16 May '07

16 May '07

Hello, So here is the question: "Is there any interest in a logging library for boost?" John Torjo did not answer my mail, beside I looked at pantheios. it seems a little bit complex... My idea is that a logging library should be _simple_ to use. Here is a small example: // snippet on #include <fstream> #include <boost/logging.hpp> int main(int argc, char **argv) { BOOST_LOG_INIT(("[" >> boost::logging::level >> "]," >> boost::logging::filename >> "(" >> boost::logging::line >> ")," >> boost::logging::time >> "," >> boost::logging::trace >> boost::logging::eol), // log format 2); // log level BOOST_LOG_ADD_OUTPUT_STREAM(new std::ofstream("./output.log")); BOOST_LOG_ADD_OUTPUT_STREAM(&std::cout); BOOST_LOG(1, "something"); BOOST_LOG(2, "something else"); BOOST_LOG(3, "doesn't matter"); char you_want[256] = "you want"; BOOST_LOG(1, "Let's say " << you_want << " to display " << 2); return 0; } // snippet off You can find the first draft of a logging library in the boost Sandbox vault. It consists of a header files, some examples and documentation. Put the file at your boost root folder and unzip it. It compiles with msvc and vc-8_0. I'll try with gcc asap. So let me know if you think it worth something or not. JD

15 34

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

[serialize, 1.34] Warning in detail/oserializer
by larsbj＠gullik.net 13 Apr '07

13 Apr '07

Both in boost/archive/detail/oserializer.hpp(l.117) and boost/archive/detail/iserializer.hpp(l.124). Because of some commented code 'flag' in unused and gives a warning. Would be nice if this was fixed before 1.34 proper. -- Lgb

4 7

try... catch... finally?
by Hans Larsen 12 Apr '07

12 Apr '07

Hi, You've probably seen "modern" languages that incorporate the keyword finally, but nothing such exists in C++. I've come with a simple class that could perform close to that keyword. The main exception is that you have to define what finally does BEFORE the try catch clause, which is kind of counter-intuitive but not hurtful. The obvious advantages of such a class over a smart_ptr<X> (X could be void*) is that you can use Boost.Bind (cf my code sample), and the order of the instructions in the finally "clause" is predictable (which is IIRC not guaranteed on destruction of variables). Obviously, though, one could not throw inside a finally... Is such a concept existent currently in Boost (or any library)? If not, would it be useful? I think so, but eh could be wrong :) Hans Larsen ---------------- #include <boost/lambda/lambda.hpp> #include <boost/bind.hpp> #include <iostream> #include <vector> class finally { protected: struct helper_base_t { virtual ~helper_base_t() {} }; template< class T > struct helper_t : public helper_base_t { const T& _; helper_t( const T& t ) : _(t) { } ~helper_t() { _(); } }; std::vector< helper_base_t* > vec; public: finally() {} ~finally() { for( std::vector<helper_base_t*>::iterator it = vec.begin(); it != vec.end(); it++ ) delete (*it); } template< class T > void operator()( const T& t ) { vec.push_back( new helper_t<T>(t) ); } }; struct func1 { void operator()() const { std::cout << 1 << std::endl; } }; void func2( int& x ) { std::cout << x << std::endl; x++; } void function() { using namespace boost; using boost::lambda::var; finally f; int x = 0; f( func1() ); // Simply print 1 // This way we can pass parameters between calls... f( bind( func2, ref(x) ) ); // using Boost.Bind, modify x - will print 0. f( bind( func2, ref(x) ) ); // using Boost.Bind, modify x - will print 1 f( var(x) = 5 ); // using Boost.Bind && Boost.Lambda f( bind( func2, ref(x) ) ); // using Boost.Bind, modify x - will print 5 try { throw int(5); } catch( short x ) { std::cout << (x+1) << std::endl; } } int main() { try { function(); } catch( int x ) { std::cout << x << std::endl; } return 0; }

8 43

units: performance testing
by Lewis Hyatt 08 Apr '07

08 Apr '07

Hello- I don't think I will have time to write a full review of units (and I probably don't know enough to seriously critique it anyway), but FWIW, I think it should be accepted, and it looks quite useful and well designed to me. I did try some quick performance tests out of curiosity on a few different systems. Here is the output of the unit_example_14 test program for: 1) gcc 3.4.4 on WinXP / MinGW (Intel P4 2.8 GHz) ------------------------------------ f(x,y,z) took 6.593 seconds to run 1e+009 iterations with double = 6.06704e+008 flops f(x,y,z) took 10.782 seconds to run 1e+009 iterations with quantity<double> = 3.70989e+008 flops g(x,y,z) took 6.625 seconds to run 1e+009 iterations with double = 6.03774e+008 flops g(x,y,z) took 9.906 seconds to run 1e+009 iterations with quantity<double> = 4.03796e+008 flops ------------------------------------ 2) gcc 3.4.4 on WinXP / cygwin (Intel P4 2.8 GHz) ------------------------------------ f(x,y,z) took 6.5 seconds to run 1e+09 iterations with double = 6.15385e+08 flops f(x,y,z) took 10.375 seconds to run 1e+09 iterations with quantity<double> = 3.85542e+08 flops g(x,y,z) took 6.719 seconds to run 1e+09 iterations with double = 5.95327e+08 flops g(x,y,z) took 10.531 seconds to run 1e+09 iterations with quantity<double> = 3.79831e+08 flops ------------------------------------ 3) gcc 3.4.6 on Linux (Intel Xeon 3.2 GHz) ------------------------------------ f(x,y,z) took 13.76 seconds to run 1e+09 iterations with double = 2.90698e+08 flops f(x,y,z) took 17.34 seconds to run 1e+09 iterations with quantity<double> = 2.30681e+08 flops g(x,y,z) took 13.82 seconds to run 1e+09 iterations with double = 2.89436e+08 flops g(x,y,z) took 14.76 seconds to run 1e+09 iterations with quantity<double> = 2.71003e+08 flops ------------------------------------ 4) gcc 3.4.6 on Linux (AMD Athlon 1.6GHz) ------------------------------------ f(x,y,z) took 27.83 seconds to run 1e+09 iterations with double = 1.4373e+08 flops f(x,y,z) took 33.22 seconds to run 1e+09 iterations with quantity<double> = 1.20409e+08 flops g(x,y,z) took 27.54 seconds to run 1e+09 iterations with double = 1.45243e+08 flops g(x,y,z) took 30.68 seconds to run 1e+09 iterations with quantity<double> = 1.30378e+08 flops ------------------------------------ So gcc, at least, seems to be able to tell the difference when the units are being used, at the level of a few tens of percent. This was compiled with g++ -s -O3 -DNDEBUG I also tried compiling with gcc 3.3.3 but got a large number of errors... I attached the gzipped output in case that is interesting, but maybe this compiler is not supposed to be supported anyway? -Lewis

9 29