Boost C++ Libraries: Ticket #4189: Add better support for non-default constructible function objects

attachment set

Daniel Walker — Tue, 04 May 2010 22:44:27 GMT

attachment → transform_iterator.patch

use boost::optional to store function objects

attachment set

Daniel Walker — Wed, 05 May 2010 21:00:12 GMT

attachment → transform_iterator.2.patch

use boost::optional to store function objects with non-trivial constructors as suggested by Jeffrey Lee Hellrung

sdebionne — Fri, 22 Jul 2011 12:06:39 GMT

This patch solves the problem mentionned here :

http://boost.2283326.n4.nabble.com/Bind-Interoperability-of-bind-mem-fn-with-transform-iterator-td2668312.html

I have been using it for more than a year. Could you considerer merging it to trunk ?

the problem is even more acute with Boost.Range adaptors since something as simple as

using namespace boost::range::adaptors;
boost::for_each(my_range | transformed(boost::mem_fn(foo)), bar);

won't compile.

Dave Abrahams — Fri, 22 Jul 2011 20:00:20 GMT

I'm concerned about the mandatory overhead implied by the use of boost::optional for transform iterators that may not need it. What about making a function object wrapper that adds default-constructibility?

owner changed

Dave Abrahams — Wed, 21 Nov 2012 19:44:05 GMT

owner changed from Dave Abrahams to jeffrey.hellrung

Taras Kozlov — Tue, 13 Aug 2013 10:38:32 GMT

Ive suffered from the same problem, when I tried to use it with lambdas. If lambda has non-empty capture list, it doesnt provide constructor with zero arguments.

typedef boost::any_range<int, boost::random_access_traversal_tag, int, ptrdiff_t> int_range;
int_range f(const vector<double>& v)
{
    vector<double> vec;
    string str = "Hello";
    return vec | boost::adaptors::transformed([str](double v) -> int { return (int)v; });
}

If boost::optional overhead is inacceptable, we may try to use aligned storage + placement new instead.

I also want to notice simple workaround: assigning lambda to std::function will make it work

std::function<int(double)> lambda = [str](double v) -> int { return (int)v; };
return vec | transformed(lambda);

This is not the perfect solution since it involves runtime overhead especially on large data ranges.

olivier-m.pena@… — Wed, 21 Aug 2013 22:54:24 GMT

Same problem than Taras here : transform_iterator assigned to an any_range with gcc 4.8.1. Even without closure.

If not assigned to an any_range, it's ok.

typedef boost::any_range<int, boost::forward_traversal_tag, int, std::ptrdiff_t> int_range;
std::vector<int> v;
// Fail.
int_range range1 = v | boost::adaptors::transformed(
   [](const int& i) {return i * 2; });
// Ok.
int_range range2 = v | boost::adaptors::transformed(
   std::function<int(const int&)>(
   [](const int& i) {return i * 2; }));

I would like to add that clang 3.3 compiles successfully.

Dave Abrahams — Thu, 22 Aug 2013 04:47:17 GMT

As far as transform_iterator is concerned, there's nothing it can do about non-default-constructible function objects in C++03 without also penalizing uses of default-constructible function objects. If there's a C++11 type trait that allows detection of deleted default ctors that would sort of let the iterator library introduce the optional<F> wrapper itself, but it wouldn't help if the default ctor was private. My suggestion here would be to create a generic forwarding function object wrapper around optional<F> and use that as the function object for your transform_iterator.

olivier-m.pena@… — Fri, 23 Aug 2013 07:29:19 GMT

Thank you for the explanations. With C++11, std::function may be that wrapper. But I still can't figure out why clang compiles my example ?