passing operators?

i'm guessing this is impossible, but is it possible to point to an operator's function, i would ideally like to pass it as an argument.

i would like to avoid having to pass a string literal to represent the operator and writing an if statement for each operator.

is there any way one could achieve something akin to:

Code:

---

template<typename returnType,typename Arg>returnType func(Arg arg1,Arg arg2,operator op)
{
}
matrix a;
matrix b;
func(a,b,a.*);

---

there are probably errors in the above, it is meant only to illustrate the concept.

it seems like there should be some way to create a function pointer to the operator, but i cannot get it...

it would be nice if it were possible to do this for POD also.

Look in the <functional> header.
It has lots of templates for things like:
plus<>
minus<>
multiplies<>
divides<>
...

templatizing the operation wasn't the issue; i need to store it!

is there a way i can pass one of those as an arg?

currently i have a series of if statements and corresponding member functions in the template class, but it would be nice if i could make it more eloquent.

How about just...

Code:

---

template<typename T> void foo(T arg) { }
int main()
{
    obj myobj;
    foo(&myobj::operator+);
    // Or foo(&myobj.operator+);
}

---

Tried it?

Quote:

---

Originally Posted by m37h0d

templatizing the operation wasn't the issue; i need to store it!

is there a way i can pass one of those as an arg?

currently i have a series of if statements and corresponding member functions in the template class, but it would be nice if i could make it more eloquent.

---

Most of those derive from binary_function<Type, Type, Type>, so you could probably store the function object as a binary_function<Type, Type, Type>& in your code...

@ Elysia; indeed, i had considered that, but what if T is an int or other POD type?

Quote:

---

Originally Posted by cpjust

Most of those derive from binary_function<Type, Type, Type>, so you could probably store the function object as a binary_function<Type, Type, Type>& in your code...

---

i will look into that. thank you.

Of course, silly me, it must be:

Code:

---

template<typename T> void foo(T arg)
{ }

class obj
{
public:
        void operator + (int) {}
};
int main()
{
        obj myobj;
        foo(&obj::operator+);
}

---

Works for me.
Now you can call your operator from the template function.

But that limits you to member +. It already doesn't work for a free operator +.

You could just store a std::plus in a boost::function or a std::tr1::function.

Quote:

---

Originally Posted by m37h0d

@ Elysia; indeed, i had considered that, but what if T is an int or other POD type?

---

I don't see why you can't simply pass the address of an appropriate operator function. Even if it's free, you should be able to call it and pass the arguments.

Code:

---

template<typename T, typename T2> void foo(T arg, T2& arg2)
{
        arg(arg2, 0);
}

class obj
{
public:
        friend void operator + (const obj&, int);
};

void operator + (const obj&, int) {}

int main()
{
        obj myobj;
        foo(&operator+, myobj);
}

---

Quote:

---

I don't see why you can't simply pass the address of an appropriate operator function.

---

Built-in operators aren't functions.

Ah, you mean built-in ones. I suppose this would only work on overloaded operators.

Quote:

---

Originally Posted by Elysia

I don't see why you can't simply pass the address of an appropriate operator function. Even if it's free, you should be able to call it and pass the arguments.

Code:

---

template<typename T, typename T2> void foo(T arg, T2& arg2)
{
        arg(arg2, 0);
}

class obj
{
public:
        friend void operator + (const obj&, int);
};

void operator + (const obj&, int) {}

int main()
{
        obj myobj;
        foo(&operator+, myobj);
}

---

---

that can't possibly work. how could the template know that the type arg is a function?

The compiler deduces the type depending on what you pass.
So what you pass IS the type, so you can use it AS that type.
That's the power of templates.
It does work.

perhaps i am being dense in not spotting a trivial error there, but that does not compile.

How about this?

Code:

---

template<typename T, typename T2> void foo(T arg, T2& arg2)
{
        arg(arg2, 0);
}

void operator + (const obj&, int);

class obj
{
public:
        friend void operator + (const obj&, int);
};

void operator + (const obj&, int) {}

int main()
{
        obj myobj;
        foo(&operator+, myobj);
}

---

I know GCC is a little more strict about things, but I don't want to copy and compile it right now.

Quote:

---

Originally Posted by Elysia

The compiler deduces the type depending on what you pass.
So what you pass IS the type, so you can use it AS that type.
That's the power of templates.
It does work.

---

that's tantamount to a kind of implied specialization, though, isn't it?

Quote:

---

The compiler deduces the type depending on what you pass.
So what you pass IS the type, so you can use it AS that type.
That's the power of templates.
It does work.

---

Not in this case.

See, the compiler has two conflicting requirements here. It has to deduce the template argument based on what is passed, so it needs a definite type as the argument. However, the address of a function is the one situation where the compiler can have a vague type on the right hand side and use the definite type of the left hand side for deduction - overload resolution, that is. Since neither the left nor the right side is definite, you get an error.

You need an explicit cast in this case:

Code:

---

foo(static_cast<void (*)(const obj&, int)>(&operator +), myobj);

---

Meh. Easier to just pass a std::plus as a boost::function.

Code:

---

template<typename T, typename T2> void foo(T arg, T2& arg2)
{
        arg(arg2, 0);
}

class obj;
void operator + (const obj&, int);

class obj
{
public:
        friend void operator + (const obj&, int);
};

void operator + (const obj&, int) {}

int main()
{
        obj myobj;
        foo(&operator+, myobj);
}

---

This works on GCC.

Add an include for <string>, import the entire std namespace, and it stops working. That's a little too brittle for my taste.

This is what sometimes is dangerous about free operators. Best put them inside a namespace to avoid conflicts.

wtf...

Code:

---

//---------------------------------------------------------------------------
#include <functional>
#pragma hdrstop

int main()
{
        greater<int>();
        return 0;
}

---

results in "undefined symbol " for any of the function objects defined in functional.h...

am i being dense here?

Yes. But do you really want to put every overload of an operator in its own namespace? That means putting all the classes in these separate namespaces too, or the ADL won't find the operator.

m37h0d: How about explicitly qualifying std?

Quote:

---

Originally Posted by m37h0d

wtf...

Code:

---

//---------------------------------------------------------------------------
#include <functional>
#pragma hdrstop

int main()
{
        std::greater<int>();
        return 0;
}

---

results in "undefined symbol " for any of the function objects defined in functional.h...

am i being dense here?

---

Add std::

Quote:

---

Originally Posted by CornedBee

Yes. But do you really want to put every overload of an operator in its own namespace? That means putting all the classes in these separate namespaces too, or the ADL won't find the operator.

---

Sticks and stones, I guess. Use whichever suits your purpose best.

Quote:

---

Originally Posted by CornedBee

Yes. But do you really want to put every overload of an operator in its own namespace? That means putting all the classes in these separate namespaces too, or the ADL won't find the operator.

m37h0d: How about explicitly qualifying std?

---

doh.

Code:

---

boost::bind(&SomeClass::operator+, _1, _2)

---

This produces a binary functor which when invoked executes SomeClass's operator+ on its operands.

It doesn't work if more than one overload of operator+() is available -- if that's the case you'll need to write your own functor to bounce through.