operator++(int);
Matthias Berndt
I'll start with a quote from D&E, page 246. It's about how to
distinguish ++i from i++ when overloading operator++ for decltype(i).
"Several alternatives that did not involve new keywords were suggested.
For example:
class Ptr_to_X {
// ...
X ++operator(); //prefix ++
X& operator++(); //postfix ++
};
or
class Ptr_to_X {
// ...
X& operator++(); //postfix because it
//returns a reference
X operator++(); //prefix because it
//doesn't return a reference
};
I considered the former too cute and the latter too subtle. Finally, I
settled on:
class Ptr_to_X {
// ...
X operator++(); //prefix: no argument
X& operator++(int); //postfix: because of
//the argument
};"
My problem is that I really don't understand what he means by "too
cute". I always thought cuteness were a good thing. And besides, I think
that introducing a bogus argument is a horrible, horrible wart :( (one
reason being that I can never remember which is which). IMO, the
++operator syntax would have been a lot more elegant. Does anybody have
an idea about what might be wrong with it?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Daryle Walker
Well, cute can be considered bad, since the programmer may have been
showing off his/her knowledge of the minutia of C++. Sometimes the
conventional way is really ugly, not concise, or has drawbacks; then
the cute method may be the best way. In other times, the compactness
of the cute form may include unwanted subtleties.
The first case has a problem with the parser. Right now, an operator
overload is declared like a function (member or non-member) with the
name of the function as "operator" followed by the desired operator's
token set. The only exception right now is that a conversion operator
must omit its return time (because it's in the name). Supporting the
first case would require making the parser more irregular for the
operator syntax. Right now, it would be:
X ++operator();
1. illegal return type "X ++"
2a. no operator token between the "operator" and "()" or
2b. no function parentheses given, since the provided "()" are
used as the operator's token name
The second case has the problem that a function's return type usually
isn't used to distinguish overloads, but that's what's required here.
Daryle Walker
Seungbeom Kim
> Hi,
>
> I'll start with a quote from D&E, page 246. It's about how to
> distinguish ++i from i++ when overloading operator++ for decltype(i).
>
>
> IMO, the
> ++operator syntax would have been a lot more elegant. Does anybody have
> an idea about what might be wrong with it?
If the ++operator() syntax were to be adopted, other prefix operators
probably should follow the same style, for consistency. However:
X *operator(); // return type X* ?
X &operator(); // return type X& ?
As shown above, starting a function name with an operator leads to
trouble. It turns out to be a better approach to start the name with
a designated keyword and have individual operators follow it. That
makes parsing easier for compilers, too.
--
Seungbeom Kim
itaj sherman
{ clc++m banner removed; please don't quote it! -mod }
My way to remember is: The one you want to define is the one with the
reasonable syntax.
The one you probabely/usualy don't want is the one with the bogus hard
to remember syntax.
Whether intended to be so or not, I think it's good.
annamalai
> reason being that I can never remember which is which). IMO, the
> ++operator syntax would have been a lot more elegant. Does anybody have
> an idea about what might be wrong with it?
I gather, from the other responses, that there are no compelling
technical reasons for the choice. Consistency might be one reason for
the choice.
Rgds,
anna
--
Sicko (The Documentary)
http://missingrainbow.blogspot.com/2008/01/sicko.html