A use case emerged when wanting to do a contitional copy (1. doable with copy_if
) but from a container of values to a container of pointers to those values (2. doable with transform
).
With the available tools I can't do it in less than two steps :
#include <vector>
#include <algorithm>
using namespace std;
struct ha {
int i;
explicit ha(int a) : i(a) {}
};
int main()
{
vector<ha> v{ ha{1}, ha{7}, ha{1} }; // initial vector
// GOAL : make a vector of pointers to elements with i < 2
vector<ha*> ph; // target vector
vector<ha*> pv; // temporary vector
// 1.
transform(v.begin(), v.end(), back_inserter(pv),
[](ha &arg) { return &arg; });
// 2.
copy_if(pv.begin(), pv.end(), back_inserter(ph),
[](ha *parg) { return parg->i < 2; }); // 2.
return 0;
}
Ofcourse we could call remove_if
on pv
and eliminate the need for a temporary, better yet though, it's not difficult to implement (for unary operations) something like this :
template <
class InputIterator, class OutputIterator,
class UnaryOperator, class Pred
>
OutputIterator transform_if(InputIterator first1, InputIterator last1,
OutputIterator result, UnaryOperator op, Pred pred)
{
while (first1 != last1)
{
if (pred(*first1)) {
*result = op(*first1);
++result;
}
++first1;
}
return result;
}
// example call
transform_if(v.begin(), v.end(), back_inserter(ph),
[](ha &arg) { return &arg; }, // 1.
[](ha &arg) { return arg.i < 2; });// 2.
transform_if
does not exist in the library? Is the combination of the existing tools a sufficient workaround and/or considered performance wise well behaved ?The standard library favours elementary algorithms.
Containers and algorithms should be independent of each other if possible.
Likewise, algorithms that can be composed of existing algorithms are only rarely included, as shorthand.
If you require a transform if, you can trivially write it. If you want it /today/, composing of ready-mades and not incur overhead, you can use a range library that has lazy ranges, such as Boost.Range, e.g.:
v | filtered(arg1 % 2) | transformed(arg1 * arg1 / 7.0)
As @hvd points out in a comment, transform_if
double result in a different type (double
, in this case). Composition order matters, and with Boost Range you could also write:
v | transformed(arg1 * arg1 / 7.0) | filtered(arg1 < 2.0)
resulting in different semantics. This drives home the point:
it makes very little sense to include
std::filter_and_transform
,std::transform_and_filter
,std::filter_transform_and_filter
etc. etc. into the standard library.
See a sample Live On Coliru
#include <boost/range/algorithm.hpp>
#include <boost/range/adaptors.hpp>
using namespace boost::adaptors;
// only for succinct predicates without lambdas
#include <boost/phoenix.hpp>
using namespace boost::phoenix::arg_names;
// for demo
#include <iostream>
int main()
{
std::vector<int> const v { 1,2,3,4,5 };
boost::copy(
v | filtered(arg1 % 2) | transformed(arg1 * arg1 / 7.0),
std::ostream_iterator<double>(std::cout, "\n"));
}