CODEWITHSUNDEEP
c++parsingoperators
Felix Dombek
Felix Dombek

Reputation: 14356

Why does C++ not allow user-defined operators?

I've been wondering this for quite some time. There are already a whole bunch of them and they can be overloaded, so why not do it to the end and allow custom operators? I think it could be a great addition.

I've been told that this would make the language too hard to compile. This makes me wonder, C++ cannot really be designed for easy compilation anyway, so is it really undoable? Of course, if you use an LR parser with a static table and a grammar such as 

E → T + E | T
T → F * T | F
F → id | '(' E ')'

it wouldn't work. In Prolog, which is usually parsed with a Operator-Precedence parser AFAIK, new operators can easily be defined, but the language is much simpler. Now, the grammar could obviously be rewritten to accept identifiers in every place where an operator is hard-coded into the grammar.

What other solutions and parser schemes are there and what other things have influenced that design decision?

Upvotes: 4

Views: 393

Answers (7)

Felix Dombek
Felix Dombek

Reputation: 14356

I just found out that it's actually possible to achieve something very similar to overloaded operators. Consider 

Vector v, a, b; v = a /vectorProduct/ b;

Turns out you can achieve the behaviour of custom operator by using dummy classes delimited by existing operators. =)

Upvotes: 0

mvladic
mvladic

Reputation: 1189

http://www2.research.att.com/~bs/bs_faq2.html#overload-operator

The possibility has been considered several times, but each time I/we decided that the likely problems outweighed the likely benefits.

It's not a language-technical problem. Even when I first considerd it in 1983, I knew how it could be implemented. However, my experience has been that when we go beyond the most trivial examples people seem to have subtlely different opinions of "the obvious" meaning of uses of an operator. A classical example is a**b**c. Assume that ** has been made to mean exponentiation. Now should a**b**c mean (a**b)**c or a**(b**c)? I thought the answer was obvious and my friends agreed - and then we found that we didn't agree on which resolution was the obvious one. My conjecture is that such problems would lead to subtle bugs.

Upvotes: 10

ruslik
ruslik

Reputation: 14870

This is usually avoided because most code is written by more that one man, so the code should be "reviewable", and it's hardly a "desired" feature of a language.

Joel Spolsky have a good article about this.

Upvotes: 0

Jörgen Sigvardsson
Jörgen Sigvardsson

Reputation: 4887

The problem with allowing custom operators is that you also have to allow the programmer to specify the syntax for how the operators should be used. I suppose the C++ type system could help a little, but it would help resolving issues like associativity, etc.

It would make the already complex language, much more complex...

Upvotes: 0

Simone
Simone

Reputation: 11797

It would become even harder to compile than what already is. Also, there would be problems with operators' precedence: how do you define it? You need a way to tell the compiler that an user-defined operator has precedence over another operator.

Almost surely it's feasible, but I think that C++ doesn't need other ways to shoot yourself in the foot :-)

Upvotes: 2

ewanm89
ewanm89

Reputation: 929

Actually it's designed to be very easy to parse and compile. C has 32 defined keywords, all other tokens are function and variables.

C++ only has a few more. One can easily identify which token is for which, so know what to look for when one uses the + token or whatever.

Upvotes: 0

darioo
darioo

Reputation: 47183

This would make the language even more complex. And that obviously wouldn't be desirable.

Still, check out Boost Spirit. It goes a long way to make stuff like you mentioned possible using lots of template metaprogramming tricks.

Upvotes: 1

Related Questions