Explicit function vs. overloaded operator?

[BCC]

In looking through some code I have inherited, I notice a lot of places
where the programmer used operator() as a function call:
void operator() (int x, int y);

Rather than an explicit function name:
void MyFunction(int x, int y);

Then when he instantiates a class he calls it:
MyClass myclass;
myclass (x, y);

vs.

MyClass myclass;
myclass.MyFunction(x, y);
Is there any advantage to this or is it just a style?

Thanks,
B

[Jeff Schwab]

BCC wrote:

In looking through some code I have inherited, I notice a lot of places
where the programmer used operator() as a function call:
void operator() (int x, int y);

Rather than an explicit function name:
void MyFunction(int x, int y);

Then when he instantiates a class he calls it:
MyClass myclass;
myclass (x, y);

vs.

MyClass myclass;
myclass.MyFunction(x, y);
Is there any advantage to this or is it just a style?

The advantage is that the user of the functor (object with overloaded
operator()) doesn't need to know whether an object of some class is
being used, instead of an ordinary function. Functors are especially
useful for encapsulating policies in generic code.

[Victor Bazarov]

BCC wrote:

In looking through some code I have inherited, I notice a lot of places
where the programmer used operator() as a function call:
void operator() (int x, int y);

Rather than an explicit function name:
void MyFunction(int x, int y);

Then when he instantiates a class he calls it:
MyClass myclass;
myclass (x, y);

vs.

MyClass myclass;
myclass.MyFunction(x, y);
Is there any advantage to this or is it just a style?

If your object/type is used as an argument for a template that
expects a functor (a function or a type with operator() defined)
then you need operator().

Otherwise, no.

In general if you think you might need both, just implement it in
the function and then define the operator() so that it simply calls
the member function.

Victor

[David Harmon]

On Wed, 26 May 2004 18:53:48 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.net> wrote,

The advantage is that the user of the functor (object with overloaded
operator()) doesn't need to know whether an object of some class is
being used, instead of an ordinary function. Functors are especially
useful for encapsulating policies in generic code.

Except that the user actually does depend on the type of function
or functor class being used. Only if the caller is a template
instantiated on that type do you get anywhere close to not needing to
know, and that only when the type is in fact known by the compiler.

[Siemel Naran]

"BCC" <br***@akanta.com> wrote in message news:t59tc.73289

In looking through some code I have inherited, I notice a lot of places
where the programmer used operator() as a function call:
void operator() (int x, int y);

Rather than an explicit function name:
void MyFunction(int x, int y);
Does he pass MyFunction objects to a template? Something like this:

template <class Iter1, class Iter2, class Action>
void for_each(Iter1 begin1, const Iter1 end1, Iter2 begin1, Action action) {
for ( ; begin1!=end1; ++begin1, ++begin2) action(*begin1, *begin2);
}

If yes, then it makes sense to write an operator(), as the template for_each
requires it. But then again we could have written for_each to call
action.MyFunction(*begin1, *begin2).

The technical advantage of operator() is that Action can be either a class
object with an operator() or a simple function. If a function, then the
type of Action is something like void (*)(int, int).

The conceptual advantage is that if class MyClass does just one thing, then
operator() reflects this one thing, and thus the essence of the class. But
I think this is a matter of style. Having an explicit function name might
make the code easier to read. For example, style.Combine(1, 2) is usually
easier to read and understand in code reviews than style(1, 2).
Then when he instantiates a class he calls it:
MyClass myclass;
myclass (x, y);
Please note you can say MyClass()(x, y), though not sure if this notation is
in popular usage.
vs.

MyClass myclass;
myclass.MyFunction(x, y);
Is there any advantage to this or is it just a style?

My guess it's a matter of style.

[Jeff Schwab]

Siemel Naran wrote:

"BCC" <br***@akanta.com> wrote in message news:t59tc.73289

In looking through some code I have inherited, I notice a lot of places
where the programmer used operator() as a function call:
void operator() (int x, int y);

Rather than an explicit function name:
void MyFunction(int x, int y);

Does he pass MyFunction objects to a template? Something like this:

template <class Iter1, class Iter2, class Action>
void for_each(Iter1 begin1, const Iter1 end1, Iter2 begin1, Action action) {
for ( ; begin1!=end1; ++begin1, ++begin2) action(*begin1, *begin2);
}

If yes, then it makes sense to write an operator(), as the template for_each
requires it. But then again we could have written for_each to call
action.MyFunction(*begin1, *begin2).

The technical advantage of operator() is that Action can be either a class
object with an operator() or a simple function. If a function, then the
type of Action is something like void (*)(int, int).

The conceptual advantage is that if class MyClass does just one thing, then
operator() reflects this one thing, and thus the essence of the class. But
I think this is a matter of style. Having an explicit function name might
make the code easier to read. For example, style.Combine(1, 2) is usually
easier to read and understand in code reviews than style(1, 2).

If the whole purpose of the "style" object is to combine things, perhaps
the name of the object should be a verb, though the object's class name
still should be a noun:

Combiner combine;
combine( 1, 2 );

I find myself using the style quite a bit, but only in programs I plan
to enhance quite a bit, particularly those that need to do a lot of
different things for a lot of different people. The advantage is that
it pretty much forces me to create a new type for each new concept,
rather than just adding a method to an existing object that happens to
be in the right places at the right times.

Then when he instantiates a class he calls it:
MyClass myclass;
myclass (x, y);

Please note you can say MyClass()(x, y), though not sure if this notation is
in popular usage.

I've used it, but I usually feel guilty about it and end up elongating
it. :) There are a few classes for which I have actually found this
style preferable, and for those, I document the style explicitly near
the class definition. For example, rather than having a global Log
object, I create them wherever I need them. In many places, e.g. catch
blocks, I only need to write one thing to the Log before the block ends.
In the Log case, I've overloaded operator<< instead of operator(), so
the code looks like this:

Log( ) << "message";

It looks less weird when a different constructor is used:

catch( ... )
{
Log( Log::high_priority ) << "An unknown exception occurred.";
}

vs.

MyClass myclass;
myclass.MyFunction(x, y);
Is there any advantage to this or is it just a style?

My guess it's a matter of style.

Mine too. :)