January 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

[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

[defer] - comments?
by simon meiklejohn 14 Mar '07

14 Mar '07

Anyone had a play with the defer library in the vault and want to comment on its usefulness? It clearly shares much in common with the asio Dispatcher concept but with the freedom to define more general Dispatchers. (e.g. 'Create thread per callback' and 'Dispatch Callback via Message Pump', both of which violate the specific guarantees of the asio Dispatcher concept, that the callback occur in a thread that has called asio::demuxer::run().) One potential application for defer would be in conjunction with asio, creating the thread(s) which call demuxer::run() in a succinct form. Cheers Simon

3 2

mcs::units informal review request
by Matthias Schabel 19 Feb '07

19 Feb '07

I've been making incremental improvements (I like to think, anyway) in the mcs::units dimensional analysis and unit library. The most recent version (v0.5.4, in the boost vault, just uploaded) includes wrappers for all <cmath> functions for which operations on quantities make sense, provides Boost.Serialization support for units and quantities, and a significantly expanded and more flexible system for unit conversion. I have also tightened up requirements on construction to improve safety in unit computations by making strict unit construction the default. In the hopes of getting it review- ready and addressing potential issues before the formal review, I'm hoping to get some concrete feedback from anyone who has downloaded and used the library (especially the v0.5.x branch). To get things started, here are a few questions I have : 1) At the moment, the library enforces strict construction; that is, quantities must be fully defined at construction : quantity<double,SI::length> q1(1.5*SI::meters); is acceptable, but quantity<double,SI::length> q2(1.5); is not. Basically, construction of quantities (other than copy construction) is restricted to products/divisors of scalars and units, scalars and quantities, and/or units and quantities. This entails some redundancy, but also avoids errors in generic code where the unit system may change. In addition, I think it makes the intent of the code clearer. Direct construction from a value_type is supported, but through a static member function: quantity<double,SI::length> q3 = quantity<double,SI::length>::from_value(1.5); Obviously, in my opinion, this sort of stuff should be restricted to libraries where it is necessary and shouldn't be ubiquitous in user code. I know that there is a camp in favor of implicit unit conversions (which can be supported in the library through a #define, though I think this causes more problems than it is worth), and I have some further thoughts on this below, but I'd like input from the non-implicit crowd as to whether this is a reasonable approach. 2) I'm not currently satisfied with the I/O aspects, particularly the lack of a mechanism for internationalization. I'd love to hear any design/implementation suggestions, especially from anyone familiar with facets/locales, on how to most gracefully accomplish this... 3) At the moment, it is possible to have completely generic rules for explicit conversion of quantities between systems by specialization of the conversion_helper class. The default implementation also allows simpler conversion implementations by defining the convert_base_unit template classes for each fundamental dimension (length, time, etc...) between the two systems to be interconvertible. I think it may be possible to implement a system that allows for fine granularity in implicit unit conversion; for example, SI::second and CGS::second are degenerate units, so they could be implicitly converted to one another with no computation. Thus, implicit conversion would be allowed in this case : 1.5*SI::seconds/SI::kelvin <-> 1.5*CGS::seconds/CGS::kelvin since these are identical quantities, but not in this one : 1.5*SI::meter*SI::seconds/SI::kelvin <-/-> 1.5*CGS::centimeter*CGS::seconds/CGS::kelvin Is this of sufficient interest to invest the effort? 4) Any comments on implementation from those brave enough to look at the guts of the library would be especially welcome. Regards, Matthias

14 87

boost_unit_test_framework cannot be built as DLL with msvc-6.5
by Roland Schwarz 09 Feb '07

09 Feb '07

I am trying to get the regressions straight for msvc-6.5. I discovered, that some of the test's test are failing with msvc-6.5. I tracked this down to the fact, that the boost_unit_test_framework cannot be built as a DLL. In fact the compilation of compiler_log_formatter faults with error C2504 : test_suite : base class undefined altough the base class is being properly declared. I suspect that the problem is, that the base class contains some template classes which are not exported. Trying to export them unfortunately doesn't resolve the problem. I further suspect, that it isn't possible to export templated classes with msvc-6.5. But I am not sure on that. Is this a known issue? Are there any work-arounds possible? If not: 1) Should the tests be omitted for msvc-6.5? 2) Are other boost regression test affected? Roland

6 18

[interprocess] problem in boost/interprocess/detail/atomic.hpp
by Glenn Schrader 09 Feb '07

09 Feb '07

I ran across this bug while running on a 2.6.9 Linux kernel. Since that kernel version doesn't have native interprocess mutexes and condition variables the interprocess library uses some emulation code. The x86 verion of the emulated semaphore uses atomic_dec32() from atomic.hpp but that function wasn't behaving properly. The following change in oost/interprocess/detail/atomic.hpp made things work properly: BEFORE: inline boost::uint32_t atomic_dec32(volatile boost::uint32_t *mem) { unsigned char prev; asm volatile ("lock; decl %1;\n\t" "setnz %%al" : "=a" (prev) : "m" (*(mem)) : "memory", "cc"); return prev; } AFTER: inline boost::uint32_t atomic_dec32(volatile boost::uint32_t *mem) { boost::uint32_t prev; // acts like an atomic 'return (*mem)--;' asm volatile ("movl $-1, %0;\n\t" "lock; xaddl %0, %1" : "=r" (prev) : "m" (*(mem)) : "memory", "cc" ); return prev; } -glenn

3 4