[bind10-dev] Operators

[Shane Kerr]

Michal,

On Tuesday, 2012-02-21 11:46:11 +0100, 
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> On Tue, Feb 21, 2012 at 11:24:46AM +0100, Jelte Jansen 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)
> 
> I don't know if we should, I feel a lot of pro-java tendencies in our
> styles. However, it is more convenient if the operators are there,
> provided they are sane (like == returning the exact opposite of !=
> every time, a < b being the same as b > a, etc.). So, if it is clear
> from context how they should be compared, I tend to think it is good
> to have them, if it makes no real sense (like Name("example.com") ==
> 2 could return true because it has exactly two labels), then
> definitely not.

You missed the philosophical discussion early on in the project, but
I'll attempt to recreate it as much as I can here.

IIRC, there was a lot of fear about using C++, because some of us had
used it before. C++ had a reputation for being bloated, slow, hard to
write, and harder to read.

What we wanted from C++ was basically only objects and exceptions, and
so the idea was to avoid using as much of C++ as possible. Especially
templates and operator overloading were considered dangerous.

I won't discuss templates, but I will mention operator overloading.

There are a number of problems with operator overloading, especially
the way it is done in C++. 

One problem is that while it is designed to make the code easier to
read, it actually has the opposite effect. In C, if you see this:

   if (x == y)

Then you have a pretty good idea of what is going on. A comparison is
cheap. A potentially more expensive comparison is obvious:

   if (0 == memcmp(x, y, sizeof(x))) 

In C++, you actually have no idea of what is going to happen with a
simple comparison. It depends on the types of both x and y - and even
worse it depends on the implementations of all of their parent classes
as well, AND on any potential implicit type conversions. The types are
not always declared at the time of comparison, and so not always even
visible. Using a modern environment like Eclipse can tease this
information out (usually), but it is non-obvious by reading the code,
and to be sure you have to go through potentially a lot of source files.

Note that when I say "the way it is done in C++", I mean the implicit
rules that C++ has for how operator overloading can work.

So, for example, if you write:

  myobject++;

Then C++ will try to find operator++(), then it will look for
operator+=(), then it will look for operator+(). When you add in
default type conversions the problem is even more tricky. The question
is, if you're just reading some code, how are you supposed to know what
is going to happen here?

It *IS* possible to use operator overloading and produce classes that
are clear and possibly even easier to use than ones requiring normal
calls. However, in BIND 10 we decided that rather that the burden would
be on any proposed use of operator overloading, rather than the other
way around.

At least, that's how I remember it. My brain has been known to edit out
memories that it doesn't like though. ;)

Cheers,

--
Shane

p.s. This choice was before we started using Google test, which may
perhaps be a motivation in favor of such operators.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120222/cc4bef64/attachment.bin>