Re: Explicit function vs. overloaded operator?
From: Jeff Schwab (jeffplus_at_comcast.net)
Date: 05/27/04
- Next message: John Harrison: "[OT] Re: compiling socket client and server on cygwin"
- Previous message: Eugene A: "Re: [OT] Re: compiling socket client and server on cygwin"
- In reply to: Siemel Naran: "Re: Explicit function vs. overloaded operator?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 27 May 2004 11:14:47 -0400
Siemel Naran wrote:
> "BCC" <bryan@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. :)
- Next message: John Harrison: "[OT] Re: compiling socket client and server on cygwin"
- Previous message: Eugene A: "Re: [OT] Re: compiling socket client and server on cygwin"
- In reply to: Siemel Naran: "Re: Explicit function vs. overloaded operator?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
