Harald M. Mueller (mueller@garwein.hai.siemens.co.at) wrote:
: In article 11284@forte.com, mikes@forte.com (Mike Schilling) writes:
: |>In _Theory and Evolution_, Stroustrup dismisses the (to me) obvious
: |>syntax of
: |>
: |> class xxx
: |> {
: |>  public:
: |>  xxx& operator++(xxx& x);  // postincrement
: |>        xxx& ++operator(xxx& x);        // preincrement
: |>    };
: |>
: |>as "too cute".  If the syntax were going to change (I know; it isn't)
: |>this is simplest and clearest IMHO.
:
: Well: try it and write the modified syntax rules. You will see
: that ... oh well, just try it! (if you really find a set of simple
: syntax rules, please mail them to me! I didn't find any when I tried).
:
: HMMueller
:
In _The C++ Programming Guide (Second Ed.)_, Stroustrp has:

 operator_function_name : operator <operator>

 operator : one of [new delete ...]

Switch to:

 operator_function_name : operator <operator>
        <preoperator> operator

 operator : one of [new delete ...]
 preoperator : ++
                  --
I've never tried to build a C++ compiler, so I can't picture how much
complication would be added to parsing, but frankly, I don't much care.

Mike

In article <1995Mar29.184343.15087@wisipc.weizmann.ac.il>,
Ben-Kiki Oren <oren@hadar.weizmann.ac.il> wrote:
>
>... I don't suppose the C++ standard
>will be accompanied by a rationale?

Nope.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

Paul J. Ste. Marie (pstemari@erinet.com) wrote:
> :I suppose they could also have named them `int
> :operator++_postfix()' and `int operator++_prefix()'.
> :
> :> I keep forgetting which is which :-)
> :
> :Exactly.

> It isn't that difficult.  The operator goes after the class
> instance whenever the () have something in them, and before
> whenever they don't.  It's the same for binops and postfix ops.

Neat. It is worth mentioning somewhere... I don't suppose the C++ standard
will be accompanied by a rationale?

     Oren.

--
Life is tough and the hard ships are many.

In article 11284@forte.com, mikes@forte.com (Mike Schilling) writes:
|>In _Theory and Evolution_, Stroustrup dismisses the (to me) obvious
|>syntax of
|>
|> class xxx
|> {
|>  public:
|>  xxx& operator++(xxx& x);  // postincrement
|>        xxx& ++operator(xxx& x);        // preincrement
|>    };
|>
|>as "too cute".  If the syntax were going to change (I know; it isn't)
|>this is simplest and clearest IMHO.

Well: try it and write the modified syntax rules. You will see
that ... oh well, just try it! (if you really find a set of simple
syntax rules, please mail them to me! I didn't find any when I tried).

HMMueller

== --------------------------------------------------------------
== Dr. Harald M. Mueller mueller@garwein.hai.siemens.co.at
== Siemens AG Austria  Siemens AG Austria
== PSE EZE TNA1   Erdberger Laende 26
== fax: +43-1-71711-5425 A-1030 Vienna/Austria
== --------------------------------------------------------------

In article <1995Mar29.184343.15087@wisipc.weizmann.ac.il>,
   oren@hadar.weizmann.ac.il (Ben-Kiki Oren) wrote:
:Paul J. Ste. Marie (pstemari@erinet.com) wrote:
:> It isn't that difficult.  The operator goes after the class
:> instance whenever the () have something in them, and before
:> whenever they don't.  It's the same for binops and postfix ops.
:
:Neat. It is worth mentioning somewhere... I don't suppose the C++
:standard will be accompanied by a rationale?

I forget where I first saw it, but the possible culprits are the
ARM, the Borland docs, or D&EoC++.  My guess is I saw it in the
ARM.

 --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com

The Financial Crimes Enforcement Network claims that they capture every
public posting that has their name ("FinCEN") in it.  I wish them good hunting.

In article <3l2qcg$moi@news.erinet.com>,
Paul J. Ste. Marie <pstemari@erinet.com> wrote:
:In article <CHRISTEN.95Mar25182750@das.harvard.edu>,
:   christen@das.harvard.edu (Jon Christensen) wrote:
:
: [snip]
:
::I suppose they could also have named them `int
::operator++_postfix()' and `int operator++_prefix()'.
::
::> I keep forgetting which is which :-)
::
::Exactly.
:
:It isn't that difficult.  The operator goes after the class
:instance whenever the () have something in them, and before
:whenever they don't.  It's the same for binops and postfix ops.

I always remember it by noting that the superfluous int had to be kludged in
so that the expression 'C++' could do its thing properly  :-)

-- Alan_Waldock@ccm.jf.intel.com
   From, but not on behalf of, Intel Corporation

In _Theory and Evolution_, Stroustrup dismisses the (to me) obvious
syntax of

 class xxx
 {
  public:
  xxx& operator++(xxx& x);  // postincrement
        xxx& ++operator(xxx& x);        // preincrement
    };

as "too cute".  If the syntax were going to change (I know; it isn't)
this is simplest and clearest IMHO.

Mike

Jim Hester (hester@titan.fullerton.edu) wrote:

> I refer to postorder unary operators (++,--).  The only syntax I have
> seen is to declare an "extra" int operand and let the compiler add in an
> "extra" operand to all calls.  This offends the formal definition of the
> language as well as every programmer who has to add "dummy" parameters
> whenever they want to overload postorder unaries.

All right, so they could have used the syntax:

class A {
 int ++operator() { ... }
};

But since that would have made the syntax definition uglier then hell,
they sensibly decided on a lesser evil. It's not _that_ bad, except that
I keep forgetting which is which :-)

     Oren.

--
Life is tough and the hard ships are many.

In article <1995Mar25.200228.27484@wisipc.weizmann.ac.il> oren@hadar.weizmann.ac.il (Ben-Kiki Oren) writes:

> All right, so they could have used the syntax:
>
> class A {
>  int ++operator() { ... }
> };
>
> But since that would have made the syntax definition uglier then
> hell, they sensibly decided on a lesser evil. It's not _that_
> bad, except that

I suppose they could also have named them `int operator++_postfix()'
and `int operator++_prefix()'.

> I keep forgetting which is which :-)

Exactly.  BTW, speaking of ugly syntax, what about the `= 0' for
pure virtual functions.  Now _that_ is ugly, IMHO.

--
Jon Christensen              "Get your facts first, then you can distort
christen@das.harvard.edu      them as you please."   -- Mark Twain

In article <CHRISTEN.95Mar25182750@das.harvard.edu>,
   christen@das.harvard.edu (Jon Christensen) wrote:

 [snip]

:I suppose they could also have named them `int
:operator++_postfix()' and `int operator++_prefix()'.
:
:> I keep forgetting which is which :-)
:
:Exactly.

It isn't that difficult.  The operator goes after the class
instance whenever the () have something in them, and before
whenever they don't.  It's the same for binops and postfix ops.


 --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com

The Financial Crimes Enforcement Network claims that they capture every
public posting that has their name ("FinCEN") in it.  I wish them good hunting.

>>>>> Mike Schilling <mikes@forte.com> writes:

> In _Theory and Evolution_, Stroustrup dismisses the (to me) obvious
> syntax of

>  class xxx
>  {
>   public:
>   xxx& operator++(xxx& x);  // postincrement
>         xxx& ++operator(xxx& x);        // preincrement
>     };

> as "too cute".  If the syntax were going to change (I know; it isn't)
> this is simplest and clearest IMHO.

And so infix operators would be written...?

oper+ator, perhaps?

I agree with Stroustrup.

Jason

I haven't seen any other comments on this, so I'll blow off steam and
see what happens.  This message asks if there is a proposed improvement
of what appears to be bad syntax, and makes a proposal if not.  Feel
free to flame at my ignorance, instruct me as to what the gurus plan to
do, and/or instruct me as to why my proposal sucks.  Also feel free to
praise my brilliance lavishly.  :-)

I refer to postorder unary operators (++,--).  The only syntax I have
seen is to declare an "extra" int operand and let the compiler add in an
"extra" operand to all calls.  This offends the formal definition of the
language as well as every programmer who has to add "dummy" parameters
whenever they want to overload postorder unaries.

Is there any planned improvement to this abomination?

Here is my suggestion, in case the answer above is "no" (or in case this
is better than whatever IS currently planned):

Postorder operators ARE "postorder operators": they are not the same as
preorder operators and should not be grouped (too closely) together.

Minimally, create a new "classification" (reserved word) called
"postoperator" for declaration purposes.  Leave "operator" to cover
binary and preorder unary operators (for simplicity as well as
backwards compatability).  If such a classification is difficult to
incorporate cleanly into the compiler's design (I doubt it but there
may be a "context sensitive" issue I'm missing) the "postoperator"
could still internally use the dummy variable but the programmer's
conception and use of the language don't need to know about it.  Adding
a "postoperator" word allows backward compatibility in THIS language
(maybe not others) since the only cases where it occurs in C++ are in
operators with NO binary definition, so compilers could also accept the
old dummy variable syntax without ambiguity.  The main argument I see
against this, "it adds annoying syntax by adding another reserved word"
appears to be far outweighed by the CURRENT syntax of the extra dummy
variables.

As an extreme of this idea, one might consider separating all operator
types: binoperator (maybe let this one be "operator"), preoperator and
postoperator.  I don't propose this:  the cumbersomeness outweighs the
conceptual value.  I am perfectly happy with "overloading" the
"operator" word to mean binary and preorder unary and can't see any
future ambiguity with this choice.  Perhaps it wouldn't be unreasonable,
however, to allow BOTH extremes if one places a high enough value on a
clean conceptual situation.

Comments?

     _           _   _
    / )         ' )   )       _/_
   (_/  . __     /---/ _  _   /  _  __
  / /\_/_///_   /   (_</_/_)_<__</_/ (_
 (_/

Why not something like "++operator(void)", possibly with removal of the
old syntax, since we already know for the loop index scope issue that
ANSI is not too afraid of breaking code?

John Williams
johnw@jove.acs.unt.edu
"Life is case sensitive."

hester@titan.fullerton.edu (Jim Hester) writes:

>I refer to postorder unary operators (++,--).  The only syntax I have
>seen is to declare an "extra" int operand and let the compiler add in an
>"extra" operand to all calls.  This offends the formal definition of the
>language as well as every programmer who has to add "dummy" parameters
>whenever they want to overload postorder unaries.

I don't know about "offending the formal definition of the language",
but I agree it's a bit of an ugly hack.

>... create a new "classification" (reserved word) called
>"postoperator" for declaration purposes.

So you're suggesting instead of the current

 T operator ++ (int) const { ... }

we write

 T postoperator ++ () const { ... }

?

This is a little better, but you'd be hard pressed trying to find
committee members who thought it was important enough to spend time on.

Personally I'd rather something like

 T operator "postfix ++" () const { ... }

or

 T operator postfix ++ () const { ... }

(note that `postfix' does not need to be a keyword to make that lase one work).
It would have been a little better if it had been designed that way in
the first place, IMHO.  However, I'm not sure that it's worth the
effort and the transition cost to change it now.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <3koeqf$goe@wintermute.fullerton.edu>,
Jim Hester <hester@titan.fullerton.edu> wrote:
[... snip ...]
>
>I refer to postorder unary operators (++,--).  The only syntax I have
>seen is to declare an "extra" int operand and let the compiler add in an
>"extra" operand to all calls.  This offends the formal definition of the
>language as well as every programmer who has to add "dummy" parameters
>whenever they want to overload postorder unaries.
>
>Is there any planned improvement to this abomination?
[... snip proposal & discussion ...]

Though the dummy int declaration may seem rather ugly, it does not have
to imply an actual physical parameter. It is just a way to make a
disctinction between pre- and post- increment and decrement. The
compiler does not have to add in an operand to all calls (but must
generate different "signatures" for both functions of course).
>
>     _           _   _
>    / )         ' )   )       _/_
>   (_/  . __     /---/ _  _   /  _  __
>  / /\_/_///_   /   (_</_/_)_<__</_/ (_
> (_/

 Daveed