On 05/04/2010 06:20 PM, Daniel Walker wrote:
On Tue, May 4, 2010 at 6:55 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
On 5/4/2010 3:49 PM, Daniel Walker wrote:
On Tue, May 4, 2010 at 1:49 PM, Peter Dimov<pdimov@pdimov.com> wrote:
Samuel Debionne:
Anyway, in my opinion, using bind/mem_fn/lambda with transform_iterator is a common use case. That would be great to have an option to add a default constructor in those libs... or is it to risky ?
The proper fix would be to make transform_iterator not require a default-constructible function object, by using boost::optional or an equivalent.
That's a great idea! I took a look at it, and the required changes seem to be minor. I made a ticket and attached a patch. https://svn.boost.org/trac/boost/ticket/4189 I ran Boost.Iterator regression tests with gcc 4.2 and it passed without error.
Daniel Walker
Maybe you should only conditionally wrap in a boost::optional, e.g., if has_trivial_constructor<F> is false
What would that gain? It's a little hairy to implement on old compilers. I'm not sure that it's worth it.
The gain is you don't have to pay the cost of a boolean in space. The boolean also has to be checked upon assignment and copy construction, so there is some amount of additional runtime overhead. What is "it" in "it's a little hairy to implement on old compilers"? The has_trivial_constructor metafunction, or a has_trivial_constructor-aware transform_iterator? For the former, I'd believe it, but I would expect the Boost.TypeTraits version to be good enough. For the latter, (and I could be very very wrong here, but) seems like the only thing you have to do is put an indirection layer when calling the function held by the transform_iterator, e.g., unwrap_optional(f)( ...args... ). In fact, there may be such a function provided by Boost.Optional... - Jeff