Pass function object to std algorithm by reference

Wouldn't it be better to pass functional objects into STL algorithms by forwarding references rather than by value?

Yes, it would be better this way. It would be better if it was necessary to require that the functor does not have to be , or . But the standard clearly states in 25.1:CopyConstructibleCopyAssignableMoveConstructibleMoveAssignable

Note: Unless otherwise specified, algorithms that take function objects as arguments are allowed to copy those function objects freely. Programmers where object identity is important should consider using a wrapper class that points to an uncopied implementation object, such as reference_wrapper<T>(20.9.4) or some equivalent solution. — endnote ]

This issue was called LWG 92 back in 1998 . and added the "note me" referenced above at that time (this note was modified as it didn't exist at the time ).reference_wrapper<T>

This is a great solution for vendors of std::lib, and a great solution for committee members responsible for revising the spec, but for someone like you who wants to use stateful For functor people, this is not a good choice.

Of course, at the time there was no forwarding reference as a possible solution. Also at that time, it was common for std::implementation to pass functors by value in algorithms , which would further corrupt their state (as indicated by LWG 92 's specification) .

You have correctly touched all the points related to this question:

• Clients could use std::refinstead , but this would not respect reference-qualified functors.

• Clients can explicitly specify functor reference parameters, but this does not prohibit implementations from duplicating functors within an algorithm .

• Explicitly specifying functor reference parameters is very inconvenient for the client because they always come last in the template parameter list.

First, libc++ is the only std::implementation written that forbids copying functors internally. That is, if you write an LWG 92 example:

#include <algorithm>
#include <iostream>
#include <list>
#include <numeric>

template <class C>
void
display(const C& c)
{
    std::cout << '{';
    if (!c.empty())
    {
        auto i = c.begin();
        std::cout << *i;
        for (++i; i != c.end(); ++i)
            std::cout << ", " << *i;
    }
    std::cout << '}' << '\n';
}

class Nth {    // function object that returns true for the nth element 
  private: 
    int nth;     // element to return true for 
    int count;   // element counter 
  public: 
    Nth (int n) : nth(n), count(0) { 
    } 
    bool operator() (int) { 
        return ++count == nth; 
    } 
};

int
main()
{
    std::list<int> coll(10);
    std::iota(coll.begin(), coll.end(), 0);
    display(coll);
    auto pos = std::remove_if(coll.begin(), coll.end(), Nth{3});
    coll.erase(pos, coll.end());
    display(coll);
}

The result today is:

libc ++

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
{0, 1, 3, 4, 5, 6, 7, 8, 9}

g ++

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
{0, 1, 3, 4, 6, 7, 8, 9}

VS-2015

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
{0, 1, 3, 4, 6, 7, 8, 9}

g++'s libstdc++ and VS-2015 are stillNthInternal reproduction , remove_ifas described by Nico Josuttis 18 years ago.

Change the code to:

    Nth pred{3};
    auto pos = std::remove_if(coll.begin(), coll.end(), std::ref(pred));

does change the result to:

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
{0, 1, 3, 4, 5, 6, 7, 8, 9}

IMHO it's just a runtime error waiting for programmers unfamiliar with std::lib's long history to do it.