Let's say you're given code written by a coder who is at least
semi-competent. When you see the line, "int a = b @ c;", you really have no
idea what "@" does, and you pretty much HAVE to stop whatever you're doing,
memorize where you are in the code, push in a new stack frame in your mind,
and navigate to the definition for @ between B and C. While reading that,
you might see further operators your don't recognize, have to push yet more
stack frames into your mind and read those, until your brain throws a stack
overflow error and you forget what you were trying to do in the first place.
Yes, but my point is that this - even this - is still at least an
order of magnitude better than the case when you don't even _realize_
that you should go operator-hunting among B and C.
And I suppose I should add that I see C++ not as a language so much as
I consider it a DIY language construction kit. It's a bit like Lego,
it can be both fun and useful, but if you're not careful it'll get
stuck in your throat and you'll suffocate. The first and foremost task
of any team that is to use C++ on a new project is to critically
review the feature-set of C++, the expected requirements of the
project, and the design and paradigms most likely to be useful for
that project. Then a document (together with any basic libraries
needed) should be produced that makes it very clear which language
features, exactly, should be used, how they should be used, and which
will not (indeed, MUST not) be used.
When it comes to operator overloading, I would suggest never using
it. As I said previously, however, I accept that in a few niche
domains (mostly mathematics), overloading them for new types of
numbers can be both useful and clean. If it's ok for + to be
overloaded for ints and floats, I will accept that there are probably
other types that also fit the bill. (And, no, it's not ok for + to be
overloaded for strings
I would be more liberal with operator definition for the reason I gave
above: it's more obvious that it is happening when it is happening.
_However_, when you are done defining this project-specific language,
you need to _train your developers_ in it. It's not enough to "know
C++" on such a team - you must know _our_ C++. And as is always the
case when teaching a new langauge, you need to provide them with
complete operator precedence charts that include all the old
operators, all of your new operators and all of the new types
supported by the old operators, AND you need to make it very clear to
them that all these operators get used throughout.
Obviously, the more operator magic you do, the more expensive it will
be to train programmers in your dialect of C++, so less is usually
better.
Now, with this in mind, I might not object too strongly to keyword
overloading or keyword definition either. (No, don't get me started on
the preprocessor <g>)
Or syntax overloading. Heh. I must be getting tired . . .
Cheers
Bent D
