September 2006 - 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

[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

interest in pair projection iterators?
by Lewis Hyatt 22 Dec '06

22 Dec '06

Hi All, I am in the middle of writing a large body of numerical code for data analysis and have found the boost library very useful for a number of things. I do a lot of work with std::map and with containers of std::pair objects, and one thing I've always felt annoyed with is the difficulty of interfacing a value_type of std::pair with the STL algorithms. Frequently, for instance, it is nice to represent data as a std::list< std::pair<double,double> > and then to be able to work with the first and second coordinates independently and pass them to std::accumulate() or whatever. The SGI extensions select1st() and select2nd() are somewhat useful but also non-standard, and they frequently require memory-wasting buffers to store only the first or second elements. I have a relatively simple system for solving this problem and it strikes me as the kind of quick thing that might be worth including in boost. The idea is to define a template class, template<typename Iterator> class first_iterator_t { Iterator pair_iter; public: first_iterator_t(Iterator const&); /*...*/ }; which overloads operator*() and operator->() to access the element named "first" of the object returned by Iterator::operator*(). (With something analagous for second_iterator_t.) A function named first_iterator() provides a convenient creation function a-la std::make_pair(). That's it for the most part, the class only needs to provide the required iterator interface which mostly consists of just calls to Iterator::operator functions. There is also the need to define the appropriate iterator_traits typedefs. There is a small issue of deducing whether the iterator needs to be a const iterator or not, which can be solved with partial specialization of a second template class containing nested typedefs. The end result is that something like this is now conveniently available: map<int, double> m; m[1] = 0.1; m[2]=0.2; m[5]=0.5; //prints: 1 2 5 copy(first_iterator(m.begin()), first_iterator(m.end()), ostream_iterator<int>(cout, "\t")); //prints: 0.1 0.2 0.5 copy(second_iterator(m.begin()), second_iterator(m.end()), ostream_iterator<double>(cout, "\t")); I don't see a way to do this otherwise without resorting to something like select1st(), and that also requires the use of std::transform(), which I find distasteful since the required operation is really just a simple copy. So anyway do you think this is useful enough to possibly include in boost somewhere, or is it too trivial? I have what I believe to be correct code, which could be made boost-ready with little effort. Thanks for your advice! -Lewis

4 5

[type_traits]Member function traits in function_traits?
by Realdodo Du 20 Nov '06

20 Nov '06

It's amazing that function_traits in Boost.type_traits does not support member function traits. As I need this feature recently, I wrote a simple implementation and discuss it with John Maddock, but he gave me following reply: John Maddock <john(a)johnmaddock.co.uk> wrote: > I don't think this is quite the right approach: function_traits was > deliberately written *not* to work with function-pointers - since you can > always strip the pointer off before passing the type to function_traits - > but handling member function pointers raise some interesting wider > questions. I'm not sure the meaning of "wider questions". Could anyone tell me what is the question and the differences between global function pointers and member function pointers, please? Regards, Realdodo Du realdodo.d(a)gmail.com

3 3

[test] missing tests
by Vladimir Prus 15 Nov '06

15 Nov '06

Hi, the libs/test/test/Jamfile has the following code: test-suite "prg_exec_monitor_test" : [ test-btl-lib run-fail : prg_exec_fail1 ] [ test-btl-lib run-fail : prg_exec_fail2 : boost_prg_exec_monitor ] [ test-btl-lib run-fail : prg_exec_fail3 : boost_prg_exec_monitor ] [ test-btl-lib run-fail : prg_exec_fail4 : boost_prg_exec_monitor ] ; When I look at regression test results: http://tinyurl.com/joyut I don't see any mention of those four tests. Anybody knows what's wrong? - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

2 1

Asio, run-time polymorphism
by stas garifulin 15 Nov '06

15 Nov '06

Hello. I have some experience with http protocol and i have question/suggestion about implementing this protocol using asio library. Http/1.1 supports "protocol upgrades": during persistent connection client ot server can ask remote peer to upgrade protocol (push additional protocol(s) in protocol stack just before HTTP). After successful upgrading client can continue to send http-requests to server over new protocol stack. See "Upgrading to TLS Within HTTP/1.1" (http://www.faqs.org/rfcs/rfc2817.html) for examples. Currently asio doesn't allow me to implement this facility (to transform socket using simple transport protocol, like TCP, to SSL-socket in run-time). Another problem. HTTP/1.1 supports transfer-encoded bodies of packets, i.e. bodies transformed for transmission between sender and recipient (compressed, chunked etc.). Such transfer-encoded bodies are always chunked, splitted to chunks, each chunk have header with his size, zero sized chunk signals end of body. In some step of my program i would like to eliminate difference between plain bodies (reading/writing to socket) and transfer-encoded bodies (reading/writing to chain of filters). In other words i'm talking about some infrastructure like boost::iostreams but built on top of asio dispatcher. Async analogue of boost::iostreams which allows me to create async chains of filters in run-time. For example, it can be done with non-templated versions of functions async_read, async_write, handler parameter of this functions will have type like boost::function<void (asio::error, size_T)>. SSL class could be implemented as such async filter and would allow attaching at run-time.

4 4

[variant, MPL] Is there a variant -> mpl sequence metafunction ?
by Jaakko Järvi 13 Nov '06

13 Nov '06

make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. Best, Jaakko -- Jaakko Järvi, jarvi(a)cs.tamu.edu

8 12

[jamboost] Boost.Build V2, Milestone 10 released
by Vladimir Prus 04 Nov '06

04 Nov '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Due to large number of improvements all users are encouraged to upgrade. Changes in this release: Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. Documentation was converted to BoostBook and improved. Performance was improved. - Toolsets initialization syntax is much more uniform. Compiler and linker flags can now be specified. - The algorithm for computing build properties was improved. Conditional requirements can be chained, and a number of bugs were fixed. - Specific order of properties can be specified. - The main target rules can be called from everywhere, not necessary from Jamfile. - Check for "unused sources" removed. - The <library> feature affects only linking now. - The <file> feature now works only for libraries. - Simpler syntax for "searched" libraries was added. - New <dependency> feature. Unix: The right order of static libraries on Unix is automatically computed. The <hardcode-dll-paths> feature is the default. gcc: The -fPIC option is passed when creating shared libraries. Problems with distcc were solved. Sun: It's now possible to use the sun linker (as opposed to gnu), and to compile C files. Darwin: Shared libraries are now supported. MSVC: Before resource files compilation, the setup script is invoked. Options deprecated in 8.0 are not longer used. The following bugs were fixed: - The <unit-test> rule did not handle the <library> property. - Don't add "bin" to the build directory explicitly specified by the user. - Allow <include-type> to select staged targets, even with <traverse-dependencies>off. - Includes for the form '# include <whatever>" did not work. - (Qt) Add paths to all dependent libs to uic command line, which helps if the UI files uses plugins. - Using <toolset-msvc:version>xxx in requirements was broken. - Error message printed when target can be found is much more clear. - Inline targets in sources of 'stage' did not work. - Don't produce 'independent target' warnings on Windows - (gcc) The <link-runtime>static did not work. - (gcc) Suppress warnings from the 'ar' tool on some systems. - (gcc) Don't try to set soname on NT. Developer visible changes: - Generator priorities are gone, explicit overrides are used. - 'Active' features were removed - Support for VMS paths was added. Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, Brock Peabody, Michael Stevens and Zbynek Winkler who contributed code to this release. - Volodya

3 5