Why do several of the standard operators not have standard functors?

Question

We have:

• std::plus (+)
• std::minus (-)
• std::multiplies (*)

Answer 1

The reason probably is that most of developers doesn't need them. Others use Boost.Lambda, most of them are there.

Answer 2

All of the ones listed are two-argument functors. Not all of the ones below are. In fact, only >>, <<, &, |, and != fulfill that criterion, and are just a little less useful in terms of functors. The casts especially are templates, which makes them a little less useful.

Answer 3

The bitwise operators are added in C++0x. I also find not_equal_to already present.

Others, like sizeof and some casts are compile time operators so would be less useful in a functor.

New and delete are abstracted in allocators. Do we need more of that?

Answer 4

new does not have a functor per say, but the default allocator does simply pass along the request to new. This also covers delete, since the two are linked.

From there, I don't think the functors are really meant to be considered "things you pass to for_each, but rather "things you might need to specialize on a case by case basis."

Removing new [and family] from the list, and you basically have a bunch of operations that have no real meaning except as specified by the language. If you take an object's address, there's really only one thing you want to happen: you get given that object's address. How might change, but what doesn't. So there's never really a need to specialize that behavior via a standard functor; you can just use & and trust operator overloading to do its thing. But the meaning of "add" or "compare" might change over the course of a program, so providing a means to do so has some merit.

This also includes the compound assignment operators; their meaning is linked to their two pieces, so if you need std::add_assign you can just fall back on std::add [and operator =, which is absent from your list].

The bitwise operators kind of fall in between; I could see the argument either way for them.

Answer 5

I think the most likely answer to the question is that the included operators are the ones that were thought to be most useful. If no one thinks to add something to the Standard Library, it won't get added.

I think the assertion that the operator functors are useless in C++0x because lambda expressions are superior is silly: sure, lambda expressions are wonderful and far more flexible, but sometimes using a named functor can lead to terser, cleaner, easier to understand code; in addition, named functors can be polymorphic while lambdas cannot.

The Standard Library operator functors are, of course, not polymorphic (they are class templates, so the operand types are part of the type of the functor). It's not particularly difficult to write your own operator functors, though, and macros make the task quite straightforward:

namespace ops
{
    namespace detail
    {
        template <typename T>
        T&& declval();

        template <typename T>
        struct remove_reference      { typedef T type; }

        template <typename T>
        struct remove_reference<T&>  { typedef T type; }

        template <typename T>
        struct remove_reference<T&&> { typedef T type; }

        template <typename T>
        T&& forward(typename remove_reference<T>::type&& a)
        {
            return static_cast<T&&>(a);
        }

        template <typename T>
        T&& forward(typename remove_reference<T>::type& a)
        {
            return static_cast<T&&>(a);
        }

        template <typename T>
        struct subscript_impl
        {
            subscript_impl(T&& arg) : arg_(arg) {}

            template <typename U>
            auto operator()(U&& u) const ->
                decltype(detail::declval<U>()[detail::declval<T>()])
            {
                return u[arg_];
            }
        private:
            mutable T arg_;
        };
    }

    #define OPS_DEFINE_BINARY_OP(name, op)                              \
        struct name                                                     \
        {                                                               \
            template <typename T, typename U>                           \
            auto operator()(T&& t, U&& u) const ->                      \
                decltype(detail::declval<T>() op detail::declval<U>())  \
            {                                                           \
                return detail::forward<T>(t) op detail::forward<U>(u);  \
            }                                                           \
        }

    OPS_DEFINE_BINARY_OP(plus,               +  );
    OPS_DEFINE_BINARY_OP(minus,              -  );
    OPS_DEFINE_BINARY_OP(multiplies,         *  );
    OPS_DEFINE_BINARY_OP(divides,            /  );
    OPS_DEFINE_BINARY_OP(modulus,            %  );

    OPS_DEFINE_BINARY_OP(logical_or,         || );
    OPS_DEFINE_BINARY_OP(logical_and,        && );

    OPS_DEFINE_BINARY_OP(equal_to,           == );
    OPS_DEFINE_BINARY_OP(not_equal_to,       != );
    OPS_DEFINE_BINARY_OP(less,               <  );
    OPS_DEFINE_BINARY_OP(greater,            >  );
    OPS_DEFINE_BINARY_OP(less_equal,         <= );
    OPS_DEFINE_BINARY_OP(greater_equal,      >= );

    OPS_DEFINE_BINARY_OP(bitwise_and,        &  );
    OPS_DEFINE_BINARY_OP(bitwise_or,         |  );
    OPS_DEFINE_BINARY_OP(bitwise_xor,        ^  );
    OPS_DEFINE_BINARY_OP(left_shift,         << );
    OPS_DEFINE_BINARY_OP(right_shift,        >> );

    OPS_DEFINE_BINARY_OP(assign,             =  );
    OPS_DEFINE_BINARY_OP(plus_assign,        += );
    OPS_DEFINE_BINARY_OP(minus_assign,       -= );
    OPS_DEFINE_BINARY_OP(multiplies_assign,  *= );
    OPS_DEFINE_BINARY_OP(divides_assign,     /= );
    OPS_DEFINE_BINARY_OP(modulus_assign,     %= );
    OPS_DEFINE_BINARY_OP(bitwise_and_assign, &= );
    OPS_DEFINE_BINARY_OP(bitwise_or_assign,  |= );
    OPS_DEFINE_BINARY_OP(bitwise_xor_assign, ^= );
    OPS_DEFINE_BINARY_OP(left_shift_assign,  <<=);
    OPS_DEFINE_BINARY_OP(right_shift_assign, >>=);

    #define OPS_DEFINE_COMMA() ,
    OPS_DEFINE_BINARY_OP(comma, OPS_DEFINE_COMMA());
    #undef OPS_DEFINE_COMMA

    #undef OPS_DEFINE_BINARY_OP

    #define OPS_DEFINE_UNARY_OP(name, pre_op, post_op)                  \
    struct name                                                         \
    {                                                                   \
        template <typename T>                                           \
        auto operator()(T&& t) const ->                                 \
            decltype(pre_op detail::declval<T>() post_op)               \
        {                                                               \
            return pre_op detail::forward<T>(t) post_op;                \
        }                                                               \
    }

    OPS_DEFINE_UNARY_OP(dereference,      * ,   );
    OPS_DEFINE_UNARY_OP(address_of,       & ,   );
    OPS_DEFINE_UNARY_OP(unary_plus,       + ,   );
    OPS_DEFINE_UNARY_OP(logical_not,      ! ,   );
    OPS_DEFINE_UNARY_OP(negate,           - ,   );
    OPS_DEFINE_UNARY_OP(bitwise_not,      ~ ,   );
    OPS_DEFINE_UNARY_OP(prefix_increment, ++,   );
    OPS_DEFINE_UNARY_OP(postfix_increment,  , ++);
    OPS_DEFINE_UNARY_OP(prefix_decrement, --,   );
    OPS_DEFINE_UNARY_OP(postfix_decrement,  , --);
    OPS_DEFINE_UNARY_OP(call,               , ());
    OPS_DEFINE_UNARY_OP(throw_expr,   throw ,   );
    OPS_DEFINE_UNARY_OP(sizeof_expr, sizeof ,   );

    #undef OPS_DEFINE_UNARY_OP

    template <typename T>
    detail::subscript_impl<T> subscript(T&& arg)
    {
        return detail::subscript_impl<T>(detail::forward<T>(arg));
    }

    #define OPS_DEFINE_CAST_OP(name, op)                                \
        template <typename Target>                                      \
        struct name                                                     \
        {                                                               \
            template <typename Source>                                  \
            Target operator()(Source&& source) const                    \
            {                                                           \
                return op<Target>(source);                              \
            }                                                           \
        }

    OPS_DEFINE_CAST_OP(const_cast_to,       const_cast      );
    OPS_DEFINE_CAST_OP(dynamic_cast_to,     dynamic_cast    );
    OPS_DEFINE_CAST_OP(reinterpret_cast_to, reinterpret_cast);
    OPS_DEFINE_CAST_OP(static_cast_to,      static_cast     );

    #undef OPS_DEFINE_CAST_OP

    template <typename C, typename M, M C::*PointerToMember>
    struct get_data_member
    {
        template <typename T>
        auto operator()(T&& arg) const ->
            decltype(detail::declval<T>().*PointerToMember)
        {
            return arg.*PointerToMember;
        }
    };

    template <typename C, typename M, M C::*PointerToMember>
    struct get_data_member_via_pointer
    {
        template <typename T>
        auto operator()(T&& arg) const ->
            decltype(detail::declval<T>()->*PointerToMember)
        {
            return arg->*PointerToMember;
        }
    };
}

I have omitted new and delete (and their various forms) because it is too difficult to write exception-safe code with them :-).

The call implementation is limited to nullary operator() overloads; with variadic templates you might be able to extend this to support a wider range of overloads, but really you'd be better off using lambda expressions or a library (like std::bind) to handle more advanced call scenarios. The same goes for the .* and ->* implementations.

The remaining overloadable operators are provided, even the silly ones like sizeof and throw.

[The above code is standalone; no Standard Library headers are required. I admit I am a bit of a noob still with respect to rvalue references, so if I've done something wrong with them I hope someone will let me know.]

Answer 6

Most likely, nobody on the Standard committee thought that they would be useful. And with C++0x's lambda support, then none of them are useful.

Edit:

I'm not saying that they have no use- more that nobody on the Committee actually thought of that use.