[bind10-dev] Operators

[Shane Kerr]

Jinmei,

On Tuesday, 2012-02-21 09:48:58 -0800, 
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> At Tue, 21 Feb 2012 11:46:11 +0100,
> Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> 
> > > On a related note; should we also by default overload the relevant
> > > operators if we have their corresponding methods? (i am just
> > > writing one that has an equals() for instance)
> 
> In the original context, one question is whether to support
> operator<<(ostream&, OurClass&) for our classes.  And, in general I
> think it's a good practice as long as we can define a reasonable
> textual representation of the class objects (so, for example, I'd say
> if a class has a toText() method we should also define operator<< for
> it).

Yes, I agree with this.

> The other is whether to support operator==.  For this, and for other
> operators, my opinion is that it's case by case basis.  On one hand, I
> like the brevity and possibly much more intuitive representation as a
> result of operator overloading.  On the other hand, its brevity can
> often make the intent unclear and lead to confusion and surprising
> results.  So, it would be a good check point in review when someone
> wants to introduce a new overloaded operator - if it's not super clear
> for the reviewer, it's probably not as good as it might look for the
> original developer.

And I also agree with this. :)

> On a further related note: we have this in our coding guideline:
> http://bind10.isc.org/wiki/CodingGuidelines#OperatorOverloading
> "When a class supports operator overloading, then there should also be
> non-overloaded methods".  I don't know the rationale of this guide,
> and, as a matter of fact, we don't follow this rule so consistently.
> If it really makes sense, we should make sure we do it more
> consistently; if the rationale isn't clear and we actually don't
> follow it anyway, I think we should rather remove it from the guide.

I'm not sure about this though. I do remember us agreeing to this, but
I don't remember the motivation. :( Perhaps we need an annotated
version of these guidelines which explains the "why" as well as the
"what"?

At first glance it appears nonsensical. Perhaps it is to make it a
little easier to read when using function pointers?

So I wouldn't be opposed to deprecating this guideline, if everyone
else thinks that is a good idea.

Cheers,

--
Shane