When you decide to overload operators?

[v4vijayakumar]

When (at which phase of the software development) the decision would
usually be taken to overload operators? Will you first design with
functions and then move these functionalities to overloaded operators?
When we can surely say, we need a functor here, or, predicate here,
for example?

Hope, this is not off-topic.

 

[Gianni Mariani]

When (at which phase of the software development) the decision would
usually be taken to overload operators? Will you first design with
functions and then move these functionalities to overloaded operators?
When we can surely say, we need a functor here, or, predicate here,
for example?

It all depends on the design goals.

For example. A smart *pointer* is supposed to look like a pointer and
so a design goal would be to make it easy to substitute a smart pointer
where you would use a regular pointer and even to the extreme as making
it generic enough that a template that used a smart pointer would behave
much like a regular pointer.

Another case where it is interesting but not necessarily needed but may
be very desirable is when you want to provide an easier way to write
code. For example, I wrote a lexical scanner generator that has one
mode of input of scanning expressions.

at::LexExpr<char> eABC = at::LexExpr<char>( "ABC" );
at::LexExpr<char> eXYZ = at::LexExpr<char>( "XYZ" );
at::LexExpr<char> DEF_or_ABC = ( "DEF" | ABC )
+ at::LexRange<char>('a','z')('A','Z')('_');

Equivalent regex is:
((ABC)|(XYZ))([a-zA-Z_])

OK, don't laugh, I'm still working on it, but it illustrates the point
in that I can overload operators so that it makes it less convoluted to
the programmer and so less error prone. Another interesting real life
example of this was a "processor" that ran at product installation time.
There were lots of parameters about which things needed to happen when
etc so that the installation went smoothly and also an interesting case
of reliably reversing the changes. The processor was implemented with
overloaded operators and originally many of the engineers thought it was
overkill. When the product was finished, the processor was huge and if
we had to have maintained the rules manually, it would have been nigh
impossible to get right and I'm pretty sure that the developer who used
the code was very happy he didn't have to do it without the aid of
operator overloading. In this example, the engineer had written some
code prior to having the overloaded version and code complexity reduced
dramatically.

So, I think the moral of the story is, if it makes your code easier to
develop and maintain, then it's a very good thing, however, be sure you
have your design goals in mind before you even start by answering the
question "what are you wanting to achieve" and actually expressing it as
a real as possible example.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

When (at which phase of the software development) the decision would
usually be taken to overload operators? Will you first design with
functions and then move these functionalities to overloaded operators?

The decision to use operator overloading can usually be taken when
designing the classes. Classes represents concepts, so when you have a
clear picture of what concepts you'll be modelling ask yourself: "Would
A = B @ C, make sense to someone not part of the development team?",
where A, B, and C are concepts and @ an operator?

If the answer is "yes" then you can overload that operator,if it is "no"
you should think twice before overloading that operator for those classes.

When we can surely say, we need a functor here, or, predicate here,
for example?

This is, in my opinion, a lower level decision since the need for a
predicate or functor is connected to the algorithms used. So this is
more an implementation question than a design question.