Art Shelest wrote:
[...]
> Does  "++i = 9;" look to you as ridiculous as it looks to me?[...]
Apparently not.  I think it's extremely helpful to be able to
iterate an iterator before assigning to it; or iterate a (smartish)
pointer before assigning to it.  There's nothing here telling me
that you intend to allow this syntax only for scalar types or that
you intend to disallow it only for scalar types.  Of course, for
most scalar types, this is unhelpful, but C(++) is a language
with many side effects.  In fact it's the side effects that help
make C(++) expressive.
  -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <3206A38A.25D5@okway.okstate.edu> Eric Gindrup
<gindrup@okway.okstate.edu> writes:

|> Art Shelest wrote:
|> [...]
|> > Does  "++i = 9;" look to you as ridiculous as it looks to me?[...]
|> Apparently not.  I think it's extremely helpful to be able to
|> iterate an iterator before assigning to it; or iterate a (smartish)
|> pointer before assigning to it.

You do?  It doesn't do anything useful for any of the iterators or smart
pointers I've seen.  In general, smart pointers should behave like
regular pointers (least surprise principle).  In this regards, STL
iterators are somewhat like smart pointers; at any rate, the STL does
not support such hermatic programming.

|> There's nothing here telling me
|> that you intend to allow this syntax only for scalar types or that
|> you intend to disallow it only for scalar types.

In practice, the standard can only define what it does for scalar types.
It is up to the user to define his types in a reasonable manner.  Thus,
regardless of what the standard says, you can choose to support this
idiom or not in your private types.

|> Of course, for
|> most scalar types, this is unhelpful, but C(++) is a language
|> with many side effects.  In fact it's the side effects that help
|> make C(++) expressive.

It is the overuse of side effects that often make C and C++ so
unreadable.  In general, a statement should do one thing, and only one
thing.  (And I know that there are exceptions, and that the definition
of "one thing" is not obvious.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

clamage@Eng.Sun.COM (Steve Clamage) writes:

> artyom@kansmen.com (Art Shelest) writes:
>
> >I can see no use for prefix ++ returning an l-value for built-in types
> >(and for redefined operators, programer defines how it works).
>
> It lets you pass such expressions to reference parameters, a
> situation which doesn't arise in C:
>  x = foo(++i);
> This example would always be ok (assuming compatible types) in C,
> but never in C++ if foo took a reference parameter. Loosening the
> restrictions on prefix ++ and -- fixes that problem.  There are
> probably also other reasons.

Given that C++ needs looser restrictions than C, I once asked what the
guiding philosophy in C++ was.  According to Andy Koenig, any operator
which requires an l-value, and has as a result the value of that
l-value, has an l-value as a result.  (Of course, he expressed it a lot
clearer than I am able to.)

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4tch1c$5vv@its.hooked.net> artyom@kansmen.com (Art Shelest)
writes:

> I can see no use for prefix ++ returning an l-value for built-in types (and
> for redefined operators, programer defines how it works).

> Does  "++i = 9;" look to you as ridiculous as it looks to me?

Actually, having these operators return lvalues was mostly my idea,
and it still doesn't look ridiculous if you look in the right places.

For example, although the ability to say "++i = 9;" buys you little,
suppose you have a function declared this way

 extern void f(const int&);

and you call f(++i).  Isn't it nice that you can pass a reference
to i directly to f without having to make a copy of it?

Moreover, the real reason that things like ++i return lvalues is as part
of a general rule that built-in operators that return one of their arguments
return lvalues if the arguments are lvalues.  That allows conveniences
like "(x>y? x: y) = 0", which is considerably less pointless than "++i = 9".
It also preserves an important identity.  Consider the following function:

 T& assign(T& x, const T& y)
 {
  x = y;
  return x;
 }

It is tempting to rewrite the two statements in the body as

  return (x = y);

but that works only if = returns an lvalue.  It can be talked into doing so
if T is a user-defined type, but what about if T is a built-in type?
To arrange that, we made the language do it automatically.

> I know that ANSI and B.S. and others spend a great deal of time discussing
> changes to existing draft, and there should be strong very reasons to break
> existing C compatibility. Would someone enlighten me what were these
> reasons in this case?

I would agree with you that it would be a bad idea if there were a
C incompatibility involved, but there isn't.  If this statement sounds
surprising, consider that a C incompatibility exists only in the case
of a legal C program that behaves differently in C++.
--
    --Andrew Koenig
      ark@research.att.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <199607231318.AA06207@zacatecas.optimum.com>, tjb839@zacatecas.optimum.com (Tim Boemker) wrote:
>In article <4ssn3t$ojb@its.hooked.net>
>artyom@kansmen.com (Art Shelest) writes:
>
>> Does C++ Draft suggest that ++ yields an l-value, as it happens in my case?
>
>ARM 5.3.1 says that prefix ++ does return an lvalue.  (As to your
>observation that ++++expr does not compile under C: prefix ++ does not
>return an lvalue under C. [C Reference Manual, 7.2.])
>

With C, one can rely on intuition (except maybe operators precedence), C++ has
gone a long way beyond this.

I can see no use for prefix ++ returning an l-value for built-in types (and
for redefined operators, programer defines how it works).

Does  "++i = 9;" look to you as ridiculous as it looks to me?

I know that ANSI and B.S. and others spend a great deal of time discussing
changes to existing draft, and there should be strong very reasons to break
existing C compatibility. Would someone enlighten me what were these reasons
in this case?

C++ compilers I use increment i by _2_ if I use following expression,
    "++ ++ ++i;"
is this also something described in ANSI draft or a bug?

Finally, if soeone could point me in recent C++ Draft general direction, I'd
appreciate it very much.

     _Art.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

artyom@kansmen.com (Art Shelest) writes:

>In article <199607231318.AA06207@zacatecas.optimum.com>,
>tjb839@zacatecas.optimum.com (Tim Boemker) wrote:
>>In article <4ssn3t$ojb@its.hooked.net>
>>artyom@kansmen.com (Art Shelest) writes:
>>
>>> Does C++ Draft suggest that ++ yields an l-value, as it happens in my
>>> case?
>>
>>ARM 5.3.1 says that prefix ++ does return an lvalue.  (As to your
>>observation that ++++expr does not compile under C: prefix ++ does not
>>return an lvalue under C. [C Reference Manual, 7.2.])
>>

>I can see no use for prefix ++ returning an l-value for built-in types (and
>for redefined operators, programer defines how it works).

It lets you pass such expressions to reference parameters, a
situation which doesn't arise in C:
 x = foo(++i);
This example would always be ok (assuming compatible types) in C,
but never in C++ if foo took a reference parameter. Loosening the
restrictions on prefix ++ and -- fixes that problem.  There are
probably also other reasons.

>Does  "++i = 9;" look to you as ridiculous as it looks to me?

It has undefined behavior because it attempts to modify an object
more than once between sequence points.

>I know that ANSI and B.S. and others spend a great deal of time discussing
>changes to existing draft, and there should be strong very reasons to break
>existing C compatibility. Would someone enlighten me what were these reasons
>in this case?

It does not break C compatibility. It is a pure extension to C, not even
adding any keywords. "Breaking C compatibility" means making
a valid C program invalid in C++. That isn't the cae here.

>C++ compilers I use increment i by _2_ if I use following expression,
>    "++ ++ ++i;"
>is this also something described in ANSI draft or a bug?

It has undefined behavior as in the previous example, and any result
is allowed by the language definition, including an error message
from the compiler.

>Finally, if soeone could point me in recent C++ Draft general direction, I'd
>appreciate it very much.

See the FAQ list referenced below.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I noticed that my compiler (MSC 10.10) will compile following lines in C++
mode, but not in C:

++++i;
++(++i); // equivalent
++i = 4;

Result of these operatoins is, of course, undefined.

Does C++ Draft suggest that ++ yields an l-value, as it happens in my case?


     _Art.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

artyom@kansmen.com (Art Shelest) writes:

>Does C++ Draft suggest that ++ yields an l-value, as it happens in my case?

Yes.  See 5.3.2 [expr.incr.pre], paragraph 1.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ssn3t$ojb@its.hooked.net>
artyom@kansmen.com (Art Shelest) writes:

> Does C++ Draft suggest that ++ yields an l-value, as it happens in my case?

ARM 5.3.1 says that prefix ++ does return an lvalue.  (As to your
observation that ++++expr does not compile under C: prefix ++ does not
return an lvalue under C. [C Reference Manual, 7.2.])

Tim Boemker
Optimum Group
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]