January 2009 - Boost - lists.boost.org

[time series] What happened to this library?
by Christian Henning 05 Mar '09

05 Mar '09

Hi there, as far as I can tell this lib has been approved but it doesn't show up in boost. Why is it not in there? Thanks, Christian

11 21

Design conventions; passing functors
by Joachim Faulhaber 04 Mar '09

04 Mar '09

Hi, I am pondering about functor passing. Functors occur in my library (ITL) e.g. for the aggregation of associated values on insertion in interval_maps (aggregation on overlap): template<class Domain, class Codomain, ...> class interval_map{ ... //(1) My current implementation is this: // Combinator is the aggregating functor template, // instantiated at compiletime template<template<class>class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator template passed or instantiated somewhere*/ } ... } //I like this definition, because it's abstract: // The functor has to be a matching template e.g. inplace_max interval_map<int,int> m; m.add<inplace_max>(some); //(1) template<class Domain, class Codomain, ...> class interval_map{ //(2) The more traditional definition template<class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator type passed or called somewhere*/ } ... m.add<inplace_max<int> >(some); //(2) I prefer (1) but both definitions (1) and (2) are purely static denotations. To have adaptable functors or functors that can have states, like in ... m.add(some, max_under(42)); ... I am afraid I have to say sayonara to definition (1) and use this instead: template<class Domain, class Codomain, ...> class interval_map{ //(3) Adaptable functor template<template<class>class Combinator> interval_map& add(const value_type& value_pair, const Combinator<Codomain>& combine) { /*combine functor passed or called somewhere*/ } Now, there seems to be a convention from the STL that functors shall be passed BY VALUE. template<template<class>class Combinator> interval_map& add(const value_type& value_pair, Combinator<Codomain> combine); This is stated in [Sutter & Alexandrecu 2005, C++ Coding Standards] item 89: "Function objects are modeled on function pointers. Like function pointers, the convention is to pass them by value. All of the standard algorithms pass objects by value, and your algorithms should too." I do not really understand this convention and feel some resistance to follow it. In addition the call by value implementation can (and will) lead to heavy inefficiency by unaware usage of fat functors. So I browsed through some boost libraries and found that functors are passed by reference there (e.g. accumulators, fusion). Final question: What is the boost standard on passing functors, that I can adapt to? Cheers Joachim

6 20

N2346 - Defaulted and Deleted Functions emulation
by vicente.botet 02 Mar '09

02 Mar '09

Hi, is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks. Attached a draft for the default and deleted functions. Only one remark the macors must be used on the public part and without trailing ';', e.g. class X { BOOST_NEW_DELETE(X) Any coments are welcome, Vicente

3 6

boost::ptr_container: seems bug in erase_if
by Anton Ivanov 15 Feb '09

15 Feb '09

Hi! In ptr_sequence_adapter.hpp we have function: template< class Pred > void erase_if( iterator first, iterator last, Pred pred ) { range_check(first,last); this->base().erase( std::remove_if( first.base(), last.base(), void_ptr_delete_if<Pred,value_type>(pred) ), this->base().end() ); } If we call this function with second parameter not equal to this->base().end() then function remove not only elemets for wich pred return true, but also all alement from last.base() to the end of container (this->base().end()). This is seems bug due to function documentation: template< class Pred > void erase_if( Pred pred ); template< class Pred > void erase_if( iterator begin, iterator end, Pred pred ); * Requirements: Pred must take an const T& argument * Effects: removes all elements t for which pred(t) returns true from the entire container or the specified range -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

3 4

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[parameter] function types as named template parameters?
by Frank Mori Hess 11 Feb '09

11 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does Boost.Parameter support function types as named template type parameters? I'm trying to write a metafunction which lets you use Boost.Parameter to specify the template types for a boost::signals2::signal using named type parameters, as was suggested during the review. But it doesn't seem to work for the "Signature" function type. I get errors like: /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:264: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:270: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:352: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:359: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:365: error: function returning a function I can get it to work if I don't use Boost.Parameter for the "Signature" type, but only use it for the other 6 types. Also, I noticed BOOST_PARAMETER_MAX_ARITY defaults to 5, but signals2::signal has 7 parameters. I can't reliably redefine BOOST_PARAMETER_MAX_ARITY in my library header, since it must be defined before boost/parameter/config.hpp gets included. You can't redefine the arity and then re-include the parameter library headers like you can with Boost.Function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJeO/v5vihyNWuA4URAtVIAJ9iHlncV/+QON81+qYYWzmzex3yDACg48Kc 2il7aidDE0Xj7tVUMmZaxLw= =eqjh -----END PGP SIGNATURE-----

2 6

Gauging interest in a thread-safe containers library
by Eric Greveson 11 Feb '09

11 Feb '09

Hi all, I've recently been doing some work that required thread-safe containers (queue, channel) and I found that in addition to these, a locking_ptr with similar semantics to boost::shared_ptr (except being thread-safe too) allowed me to perform all my threaded operations without needing to worry about synchronisation outside the container/locking_ptr code, and without a major impact on performance compared to coding locks in a slightly less generic (== paranoid) way. These have been re-used with some success by others, and a couple of containers (specifically the queue and channel) seem to be used commonly enough to be worthy of an inclusion in Boost.Thread or similar. This discussion has been had in the past, on this thread: http://lists.boost.org/Archives/boost/2004/09/71454.php Someone else mentioned it later, but there doesn't seem to be much else said here: http://lists.boost.org/Archives/boost/2005/11/96991.php I was wondering if there is more interest now, a few years on. Some of the pros I can think of are: * Writing correct thread-safe code can be tricky (I messed up the first time I wrote my queue). * Use of multithreading is perhaps more prevalent now, with many-core CPUs, than it was 4 years ago * Queues / channels in particular are very useful for building threaded pipelines etc, and more people might be tempted to use such programming techniques if a safe option was available "out-of-the-box" * A thread-safe shared pointer provides a lazy but effective way of synchronising data in many scenarios (my implementation supports the usual boost::shared_ptr stuff except for get(), -> and *: dereferencing is provided by calling an acquire() function which returns a scoped_lock object on which you can call * and ->.The destructor of the scoped_lock releases the lock.) * The thread-safe shared pointer means you could use a pop-copy queue without significant overhead (depending on use) * The code length for these class templates on a single platform is actually quite short (a hundred lines of code or so) Some cons: * Need to support all the platforms Boost works on * Not much interest for these containers last time * More code to maintain * Questions about how re-usable a synchronised queue is due to performance worries (I believe this not to be a major problem for a major class of problems - e.g. pipelining fairly long operations, such as in image and video processing) I'm sure I've missed some things, but I'd be interesting in hearing whether there's a positive or negative reaction to this. I'd be happy to contribute code for this - it wouldn't be the fastest possible code, but I believe that robust, lightweight, maintainable code is better than nothing in this case, even if it's not the very best lock-free implementation. Thanks for reading! Eric

6 10

Futures Review Starts Today - January 5, 2009
by Tom Brinkman 11 Feb '09

11 Feb '09

Futures Review Starts Today - January 5, 2009 Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Please review one or both libraries for submission to boost. Apparently, Anthony Williams' submission has also been sumbitted the C++ standards committee. Status unknown. As always, here are some questions you might want to answer in your review(s): What is your evaluation of the design(s)? What is your evaluation of the implementation(s)? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library(s)? Did you try to use the library? With what compiler(s)? Did you have any problems? How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? Do you think the libraries should be accepted into Boost as-is or should they be merged? Apparently, there has been various discussions about these two libraries last six months. The authors will need to bring us up to date as to why they want their libraries to be reviewed seperately. Also, each author should evaluate each others library and point out the differences in their implentations. These will serve as useful discussion points. The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result. As always, your reviews will certainly assist the authors in improving their libraries even further. Thank you in advance. Please feel free to participate in any discussion even if your not going to provide a full review. Review Manager Tom Brinkman

13 61

[lexical_cast] A suggestion
by Vladimir Batov 09 Feb '09

09 Feb '09

I use boost::lexical_cast quite a bit. Possibly due to specifics of my task I constantly stumble upon two things: 1. It throws if/when conversion fails; 2. It requires the 'Target' class to be default-constructible. I'd like to suggest extending the existing template<class Target, class Source> Target lexical_cast(Source const& arg) interface with template<class Target, class Source> Target lexical_cast(Source const& arg, Target const& failure_value) The behavior of the latter would be to return the 'failure_value' if/when the conversion fails. That communicates the fact of the conversion failure differently (without an exception thrown), i.e. its usage would be as following: int value = boost::lexical_cast(some-string, -1); if (value == -1) conversion failed. In fact, my usage pattern is such that I often do not even need to check the success of the conversion -- if the conversion fails, the supplied failure/default value is returned/used and proceeded with. Secondly, the proposed lexical_cast requirements would be looser -- no need for the default-constructibility of the Target, only the copy-constructibility (as already required anyway). For that the current lexical_cast implementation if(interpreter << arg) { Target result; if (interpreter >> result) return result; } throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return Target(); // normally never reached (throw_exception) would change (for the proposed interface) to something like if(interpreter << arg) { Target result(failure_value); if (interpreter >> result) return result; } return failure_value; I am not sure how much value such an interface extension might have for others but for my usage pattern the benefit would be quite visible as the majority of our classes are with no default constructors and handling conversion-failure exceptions is quite a hassle... not to mention that for whatever guided/misguided reasons exceptions are virtually banned for our mission-critical development. Best, V.

14 40