In article <3A19683A.825AD06A@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> Christian Bau wrote:

> [...]

> > I am relatively sure that if "an object specified by the same
> > token sequence" is modified twice or modified and used etc. then
> > you will have undefined behavior.

> Counter example:

> int& f()
> {
>   static std::vector<int> numbers;
>   numbers.push_back(0);
>   return numbers.back();
> }

> int main()
> {
>   f() = ++f();
> }

> Since both function calls return different objects, the behaviour is
> well defined, despite the equal token sequence.

The behavior is unspecified, not well defined, since which f is called
first is unspecified.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Bo-Staffan Lankinen wrote:
>
> > If you require that compilers catch some, but not all, violations of
> > 5.4, you also must specify which kinds of violations must be caught
> > and which ones need not be caught. Otherwise, the requirement has no
> > meaning. (You can't test for conformance, and disputes between
> > implementors and users cannot be resolved.)
> >
> > I think it is too difficult, if it is possible at all, to provide a
> > useful specification. Consequently, this area is left as a "quality of
> > implementation" issue.
>
> If it is possible to deduce that an expression results in undefined behavour
> then I want the compiler to issue an error. Disregarding aliasing, it
> wouldn't that difficult for the built-in types.

You still have to specify what you mean by "possible". How smart
must the compiler be?  Example:

 // p is a pointer or array
 ... ++p[int(sin(0.0))] + p[int(cos(PI/2.0))]++ ...

Do we require the compiler to recognize that sin(0) and cos(PI/2)
have the same value? How about other mathematical identities?

If you don't require that the compiler be able to prove mathematical
theorems, exactly what sorts of identities must be recognized?

I still claim it is too difficult to specify to be of any use.
A compiler vendor is free to detect relatively easy cases and
report them. Requiring something like that in the language
standard is a different story.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Bo-Staffan Lankinen wrote:
...
> If it is possible to deduce that an expression results in undefined behavour
> then I want the compiler to issue an error. Disregarding aliasing, it

I'd prefer "easy to deduce", rather than "possible to deduce". There are
many cases where it is possible to deduce undefined behavior, but where
it can take arbitrarily long to carry out the deduction. Compilation
times that run into millenia are seldom acceptable :-)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A0F79A7.31CE9CA1@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:

> Bo-Staffan Lankinen wrote:
> ...
> > If it is possible to deduce that an expression results in undefined behavour
> > then I want the compiler to issue an error. Disregarding aliasing, it
>
> I'd prefer "easy to deduce", rather than "possible to deduce". There are
> many cases where it is possible to deduce undefined behavior, but where
> it can take arbitrarily long to carry out the deduction. Compilation
> times that run into millenia are seldom acceptable :-)

I am relatively sure that if "an object specified by the same token
sequence" is modified twice or modified and used etc. then you will have
undefined behavior.

A simple example:

   int i;
   int *p;
   int **q, *r;

   i + ++i;             // Undefined behavior.
   (*p) + ++(*p);       // Undefined behavior

   (*p) + (++*q == r) + ++(*p);

This one will have undefined behavior: First this looks obvious because *p
is both used and modified. However, the 'p' in (*p) and ++(*p) is not
necessarily the same, because ++*q could have modified p, so we do NOT
know for sure that there is undefined behavior because *p is both modified
and used. On the other hand, the only way to make this defined is if ++*q
modifies p, and then this itself causes undefined behavior.

If there are no counterexamples, then this rule could be used. I would
probably want to make it just slightly stronger by including unneeded
brackets, so both

   *p = ++*p;
and
   *p = ++(*p);

would be illegal. I think this would be a rule that is sufficiently easy
to check and reasonably powerful.

Another problem has to do with comma expressions. If you write (expr1,
expr2) + (expr3, expr4) then the compiler has the freedom to have the two
sequence points between expr1 and expr4 for example or not. Of course
behavior is undefined if it is possible for the compiler to legally insert
the two sequence points in such a way that behavior is undefined. But
whether this is possible or not might be very hard to decide. I am not
sure about this. So if you have a very complicated expression with many
comma operators, ?: operators, ||, && etc, containing the subexpressions i
and i++, it might be very hard to prove that there must be a sequence
point or not.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> You still have to specify what you mean by "possible". How smart
> must the compiler be?  Example:
>
> // p is a pointer or array
> ... ++p[int(sin(0.0))] + p[int(cos(PI/2.0))]++ ...
>
> Do we require the compiler to recognize that sin(0) and cos(PI/2)
> have the same value? How about other mathematical identities?

It's impossible to predict the return value of a function, defined in
another translation-unit, at compile-time. sin and cos, for instance,
doesn't have to correspond to the trigonometric functions sine and cosine. A
decent compiler should be able to determine whether the outcome of a
function call is possible to resolve at compile-time, since that operation
should be part of the optimization process. It would result in a slightly
longer compile-time though, but I think it's a reasonable tradeoff.

Bo-Staffan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8vbjom$4167t$1@ID-47792.news.dfncis.de>,
Bo-Staffan Lankinen <bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com> wrote:
>> You still have to specify what you mean by "possible". How smart
>> must the compiler be?  Example:
>>
>> // p is a pointer or array
>> ... ++p[int(sin(0.0))] + p[int(cos(PI/2.0))]++ ...
>>
>> Do we require the compiler to recognize that sin(0) and cos(PI/2)
>> have the same value? How about other mathematical identities?
>
>It's impossible to predict the return value of a function, defined in
>another translation-unit, at compile-time. sin and cos, for instance,
>doesn't have to correspond to the trigonometric functions sine and cosine. A
>decent compiler should be able to determine whether the outcome of a
>function call is possible to resolve at compile-time, since that operation
>should be part of the optimization process. It would result in a slightly
>longer compile-time though, but I think it's a reasonable tradeoff.

Ok, but when sin and cos are defined by the Standard, they you
could make an argument that the compiler and lib can "conspire"
for such an optimization.  The question is how practical it is
for some things (see Steve's example above).

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Christian Bau wrote:

[...]

> I am relatively sure that if "an object specified by the same token
> sequence" is modified twice or modified and used etc. then you will have
> undefined behavior.

Counter example:

int& f()
{
  static std::vector<int> numbers;
  numbers.push_back(0);
  return numbers.back();
}

int main()
{
  f() = ++f();
}

Since both function calls return different objects, the behaviour is
well
defined, despite the equal token sequence.

[...]

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> > In the same vein,
> >I would argue that shifts of signed values should be
> >well defined and be identical to the result of
> >"arithmetic" shifts.
>
> I see two major problems with this:
> * It silently changes the semantics of existing code.  Doing right
>   shifts of signed values has always been perfectly legal C/C++, it
>   just hasn't been portable.  So programmers who are writing non-portable
>   code (e.g. bit-twiddling for particular hardware) have always been
>   allowed to use these shifts (presumably after reading their compiler
>   documentation as to semantics).  This change would require all such
>   code to be modified.
> * The proposed semantics would mean generating significantly slower
>   code for hardware which provides only "logical" and not "arithmetic"
>   shifts.  (Some) users don't appreciate language changes that hurt
>   performance!

Yes, but C/C++ does not otherwise have arithmetic
shifts which are definitely useful -- and their
absence does leave room for assembly language. As far
as possible basic arithmetic and logic operations
should be directly represented in C/C++. The other
major missing operation is rotates, but that would
require introducing a new operator. Of course, we
could leave << and >> along and then define...

   <|   |>    for logical shifts
   <+   +>    for arithmetic shifts
   <*   *>    for rotates

However, in the absence of adding operators to the
language, I think the benefit of ensuring the
availability of arithmetic shifts far outweighs the
possible cost in execution time for those platforms
which do not have arithmetic shifts (do you know of
any?).

> >What most people want is to be able to use expressions
> >like abc(I,I++) in a clearly defined manner.

I have conceded the point on the definition of the
increment operators after a well chosen example in a
different post, so I won't carry this argument any
further. I will note that my primary desire is to
eliminate as far as possible undefined areas in the
language in the interest of portability. There are
always tradeoffs in such an endeavor.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Tue,  7 Nov 2000 22:39:23 GMT, "Bo-Staffan Lankinen"
<bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com> wrote:

>It is impossible to resolve all side-effects at compile-time, we can agree
>on that. There is also a problem with aliasing, ie. when refering to an
>object through multiple pointers/references. That aside, it wouldn't be that
>hard, for the compiler, to verify that an expression contains max. one
>non-const operator for each object, which is implied by 5.4. That way it
>would, for instance, be possible to catch:
>
>i=v[i++]; (where i, for instance, is int and v, for instance, is an array of
>int)

If you require that compilers catch some, but not all, violations of
5.4, you also must specify which kinds of violations must be caught
and which ones need not be caught. Otherwise, the requirement has no
meaning. (You can't test for conformance, and disputes between
implementors and users cannot be resolved.)

I think it is too difficult, if it is possible at all, to provide a
useful specification. Consequently, this area is left as a "quality of
implementation" issue.

---
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Barry Margolin <barmar@genuity.net> writes:

>Michael Lee Finney  <michael.finney@acm.org> wrote:
>>We all benefit. The fewer undefined areas in the
>>language specification the better.
>
>This is not a good generalization.

Michael Lee Finney's generalization would be right if all other things
were equal, but of course they never are.

>Undefined != bad.

I'd describe this slightly differently.

Undefined behaviour is always bad.  It harms portability and can make
debugging very difficult.

In some cirumstances there are compensating benefits which mean that
overall there is a net benefit, but that doesn't mean that the undefined
behaviour isn't bad, it just means that this factor is outweighed by
other considerations.

>Undefined areas are opportunities for hardware-specific optimizations,

If leaving the behaviour undefined makes it possible for compilers to
do additional optimizations, that is a compensating benefit which may
outweight the drawbacks of leaving things undefined.

>vendor extensions and
>experimental features (which can later be standardized if they're popular),
>etc.

For most of those, there is no need to leave things undefined.
Instead, it's generally much better for extensions to be left to areas
for which the standard requires a diagnostic.  Vendor compilers can
then issue a diagnostic (e.g. "Thanks for making use of this
compiler's special features.").  This alerts the programmer to the
fact that they are using non-standard features.

>Or, as in the case of things like f(i++, i++), they serve as a
>message from the experts who make of the standardization committee that
>this type of code should be discouraged.

Unfortunately, this message is not very clear, because of the use of
undefined behaviour for implementation extensions.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Stephen Clamage <stephen.clamage@sun.com> writes:

|>  On Tue,  7 Nov 2000 22:39:23 GMT, "Bo-Staffan Lankinen"
|>  <bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com> wrote:

|>  >It is impossible to resolve all side-effects at compile-time, we
|>  >can agree on that. There is also a problem with aliasing, ie. when
|>  >refering to an object through multiple pointers/references. That
|>  >aside, it wouldn't be that hard, for the compiler, to verify that
|>  >an expression contains max. one non-const operator for each object,
|>  >which is implied by 5.4. That way it would, for instance, be
|>  >possible to catch:

|>  >i=3Dv[i++]; (where i, for instance, is int and v, for instance, is a=
n
|>  >array of int)

|>  If you require that compilers catch some, but not all, violations of
|>  5.4, you also must specify which kinds of violations must be caught
|>  and which ones need not be caught. Otherwise, the requirement has no
|>  meaning. (You can't test for conformance, and disputes between
|>  implementors and users cannot be resolved.)

I think he's advocating the other extreme -- ban any expression with
there is more than one side effect, e.g. *p ++ =3D ch.

I have a certain sympathy for that point of view, but I don't really
think it even possible to consider.  It's hard to imagine any large C++
program that it wouldn't break (including most of mine, and I have a
very conservative style).

|>  I think it is too difficult, if it is possible at all, to provide a
|>  useful specification. Consequently, this area is left as a "quality
|>  of implementation" issue.

Agree.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Barry Margolin <barmar@genuity.net> writes:

|>  In article <8jce0ts4e7npn2fpbuaan6h71b34i4gj4k@4ax.com>,
|>  Alex Oren <alexo@bigfoot---filter---.com> wrote:

|>  >There is a feature I like in Java - the result of evaluating an
|>  >expression (or an argument list) is always "as if" it was evaluated
|>  >in a left-to-right order.

|>  >That makes things like f(a++, a++) well defined.

|>  >Not that I advocate actually writing such code but it seems to me
|>  >that making it well defined for C++ can be beneficial.  It will
|>  >definitely not break any existing code and I think that
|>  >optimisation opportunity loss will be minimal (if at all).

|>  If you don't advocate writing such code, why do you want to
|>  encourage it by making it well defined?

He didn't say he wanted to encourage it.  What he wants, I think, is
simply determinism.  If his code doesn't work, he wants it never to
work, and not simply to depend on the optimization level of the
compiler.

Maybe you never write code that accidentally does something you didn't
intend, but most of us do, and it definitly adds to robustness if at
least it always does the same thing.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> If you require that compilers catch some, but not all, violations of
> 5.4, you also must specify which kinds of violations must be caught
> and which ones need not be caught. Otherwise, the requirement has no
> meaning. (You can't test for conformance, and disputes between
> implementors and users cannot be resolved.)
>
> I think it is too difficult, if it is possible at all, to provide a
> useful specification. Consequently, this area is left as a "quality of
> implementation" issue.

If it is possible to deduce that an expression results in undefined behavour
then I want the compiler to issue an error. Disregarding aliasing, it
wouldn't that difficult for the built-in types. For udt's I think one at
least should expect the compiler to verify that an expression conforms to
5.4 with respect to constness of the involved objects.

When I started programming C++ I was once bitten quite bad by this
"feature". The real nasty part was that it resulted in a bug that only
manifested itself in the release version.

Bo-Staffan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

>I think he's advocating the other extreme -- ban any expression with
>there is more than one side effect, e.g. *p ++ = ch.

No, *p++=ch, doesn't result in undefined behaviour. If it's possible to
deduce that an expression violates 5.4 at compile-time, for instance
i=v[i++]; i=i++ + 1; f(i++,i++); etc., then I want the compiler to issue an
error.

Bo-Staffan



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <MPG.1473c2a7d3b9fbbf989701@news-server.neo.rr.com>,
michael.finney@acm.org wrote:

> In article <christian.bau-0811001643550001@christian-
> mac.isltd.insignia.com>,
> christian.bau@isltd.insignia.com says...
> > Who benefits?
> >

> > By the way, what would your proposal mean for the statements
> >
> >    int i = 3;
> >    i = i++ + 4;
> >
> > Will this produce i = 4 or i = 8? (Java would produce i = 7, but that is
> > not compatible with your proposal).
>
> We all benefit. The fewer undefined areas in the
> language specification the better.  In the same vein,
> I would argue that shifts of signed values should be
> well defined and be identical to the result of
> "arithmetic" shifts. Which is what I usually assume
> and which almost all compilers generate. Since the
> shifts of unsigned values are essentially the
> "logical" shifts, clearing up this undefined area
> would benefit anyone who needs arithmetic shifts and
> must currently rely on undefined behaviour (or
> assembly language or really bad code).
>
> As far as your example, I would think that there has
> to be at least a conceptual sequence point between
> evaluating the expression "I++ + 4" and assigning it
> to I. So, the result would be 7. Because "I++ + 4"
> increments the value of I after it uses the value so
> the expression is effectively 3+4 with a post
> increment of I. Since that post increment of I should
> then occur before the sequence point, and then I would
> be assigned the new value of the expression, I would
> then get 7 as its value with the intermediate value of
> 4 being discarded (or overwritten) by the optimizer.

So i = (i++) + (i++) + (i++) + (i++) is defined to increase i by one? This
is nonsense.

> However, if the standard mandates the sequence point
> after the assignment, then the result of the
> expression should be 4. I see no problem in using the
> current definition of sequence points for code like
> this. The result is still well defined just as code
> such as "I = 4, I = 7" is well defined (and just as
> useless for the multiple assignments).
>
> What most people want is to be able to use expressions
> like abc(I,I++) in a clearly defined manner.

I think very few people want to use expressions like abc (l, l++) at all.

And before you make any proposals, you should think them through. In Java,
at least things are thought through: Side effects happen immediately after
the operand are evaluated, and expressions are evaluated from left to
right. No sequence points (or you could say: A sequence point between any
two operands).

Your rule that pre-increment/decrement side effects should happen just
after the preceeding sequence point is nonsense: Consider

   ++a [a[2]];

You suggest that some element of the array a is incremented BEFORE a[2] is
evaluated. How do you know which one without evaluating a [2]? And which
one do you increment if a[2] equals 2? There are two wrong answers: a[2]
and a[3].

Your suggestion was a special rule for post/pre increment and decrement.
So it treats (++i) and (i += 1) different, although they are absolutely
identical (I don't know the text in the C++ Standard, but in the C
standard they ARE identical. ++i is defined as i += 1). But you cannot
demand that the side effect of += happens just after the preceeding
sequence point: At that point, you don't know the right hand side.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <christian.bau-0811001643550001@christian-mac.isltd.insignia.com>,
christian.bau@isltd.insignia.com wrote:
> Currently working code does not benefit. Instead, it will become slower
> because compiler optimisations will suffer. The loss may not be much, but
> even a small loss without benefits is pointless.

I think this is a very important point.  One of C's key design goals,
which C++ inherited, is (roughly speaking) "not to leave any room for
a lower-level language", i.e. to allow the writing of even count-every-cycle
bit-twiddling code in C/C++.  Stroustrup states this design goal for
C++ quite explicitly in D&EC++.


In article <MPG.1473c2a7d3b9fbbf989701@news-server.neo.rr.com>,
Michael Lee Finney  <michael.finney@acm.org> wrote:
>We all benefit. The fewer undefined areas in the
>language specification the better.

If all other things were equal, that would likely be true.  But the
reality is a cost-benefit tradeoff: the undefined areas in C/C++ are
generally just those where some reasonable implementations may want
to go one way, and others another way... so defining one way as the
"right" way is going to inconvenience some implementations.  This has
a cost, whether in compiler complexity, compile-time performance,
(and/)or performance of generated code.


> In the same vein,
>I would argue that shifts of signed values should be
>well defined and be identical to the result of
>"arithmetic" shifts.

I see two major problems with this:
* It silently changes the semantics of existing code.  Doing right
  shifts of signed values has always been perfectly legal C/C++, it
  just hasn't been portable.  So programmers who are writing non-portable
  code (e.g. bit-twiddling for particular hardware) have always been
  allowed to use these shifts (presumably after reading their compiler
  documentation as to semantics).  This change would require all such
  code to be modified.
* The proposed semantics would mean generating significantly slower
  code for hardware which provides only "logical" and not "arithmetic"
  shifts.  (Some) users don't appreciate language changes that hurt
  performance!


>What most people want is to be able to use expressions
>like abc(I,I++) in a clearly defined manner.

"most people"??  I've never seen any use for them outside obfuscuated-
-programming contests!  Can you show plausible code sequences which
naturally use such a construct, and where the alternative
     abc(I,I); ++I;
is significantly less clear?

To make a convincing case for this, one would want to take a large
body of existing C/C++ code, and demonstrate that this construct could
have been used (to simplify the code) in such-and-such a number of
places.  Has someone done this?  [This _has_ been done for other
proposed changes to C++, see D&E for discussions of (eg) an infix
exponentiation operator.]

There is also once again the issue of performance.  Some hardware
(instruction set + calling sequence) naturally wants right-to-left
evaluation of function arguments, so left-to-right will mean slower
code.  (For example, if arguments need to be pushed on a stack in
right-to-left order, left-to-right evaluation will need to buffer
arguments in registers... which can be slow if there aren't enough
free registers and so values must be spilled to memory.)

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   [[tongue-in-cheek discussion of new infix operators for C++]]
   "I want operator:-) to tell the compiler not to take a certain expression
    too seriously.", Phil Edwards, comp.std.c++, 5 Nov 2000

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <christian.bau-1011001253450001@christian-
mac.isltd.insignia.com>,
christian.bau@isltd.insignia.com says...
> Your rule that pre-increment/decrement side effects should happen just
> after the preceeding sequence point is nonsense: Consider
>
>    ++a [a[2]];
>
> You suggest that some element of the array a is incremented BEFORE a[2] is
> evaluated. How do you know which one without evaluating a [2]? And which
> one do you increment if a[2] equals 2? There are two wrong answers: a[2]
> and a[3].

Excellent point -- you are right. I had not thought of
expressions whose evaluation depends on the result of
the preincrement in a non-trivial way. There probably
isn't any way to make such an expression well-defined.
Pity.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> There is a feature I like in Java - the result of evaluating an expression
> (or an argument list) is always "as if" it was evaluated in a
left-to-right
> order.
>
> That makes things like f(a++, a++) well defined.
>
> Not that I advocate actually writing such code but it seems to me that
> making it well defined for C++ can be beneficial.  It will definitely not
> break any existing code and I think that optimisation opportunity loss
will
> be minimal (if at all).

A better solution, IMHO, would be to require the compiler to issue an error.
Writing code with unspecified behavour can't be what the author intended.
That way the compiler could still have to possiblity to make optimisations.

Bo-Staffan



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8u96ip$16sno$1@ID-47792.news.dfncis.de>,
Bo-Staffan Lankinen <bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com> wrote:
>> There is a feature I like in Java - the result of evaluating an expression
>> (or an argument list) is always "as if" it was evaluated in a
>left-to-right
>> order.
>>
>> That makes things like f(a++, a++) well defined.
>>
>> Not that I advocate actually writing such code but it seems to me that
>> making it well defined for C++ can be beneficial.  It will definitely not
>> break any existing code and I think that optimisation opportunity loss
>will
>> be minimal (if at all).
>
>A better solution, IMHO, would be to require the compiler to issue an error.
>Writing code with unspecified behavour can't be what the author intended.
>That way the compiler could still have to possiblity to make optimisations.

Many cases can't be detected statically.  E.g.

f(g(), h());

If g() and h() are in a separate compilation unit, there's no way for the
compiler to tell whether they have an order dependency.  Even if they're
both in this compilation unit it can be quite difficult for a compiler to
tell.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Alex Oren" <alexo@bigfoot---filter---.com> wrote...
>
> There is a feature I like in Java - the result of evaluating an
> expression (or an argument list) is always "as if" it was evaluated
> in a left-to-right order.
>
> That makes things like f(a++, a++) well defined.
>
> ... I think that optimisation opportunity loss will be minimal.

This is wrong. Left to its own devices, the compiler can almost
certainly overlap the evaluations and calculate two or three
such "argument expressions" in the time it takes to calculate
the longest one of them.

Your rule could easily make inner loops run at only half speed
or slower.


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> Many cases can't be detected statically.  E.g.
>
> f(g(), h());
>
> If g() and h() are in a separate compilation unit, there's no way for the
> compiler to tell whether they have an order dependency.  Even if they're
> both in this compilation unit it can be quite difficult for a compiler to
> tell.

Sorry my bad, I should have been a little bit more explicit! I was refering
to the construct f(a++, a++) and all other constructs that breaks 5.4 of the
ISO C++ standard.

Excerpt: "Between the previous and next sequence point a scalar object shall
have its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be accessed only to determine
the value to be stored."

I'd like to have the standard changed so breaking 5.4 would result in an ill
formed program instead of unspecified behavour.

Bo-Staffan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8u9j4g$18tac$1@ID-47792.news.dfncis.de>,
Bo-Staffan Lankinen <bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com> wrote:
>Sorry my bad, I should have been a little bit more explicit! I was refering
>to the construct f(a++, a++) and all other constructs that breaks 5.4 of the
>ISO C++ standard.
>
>Excerpt: "Between the previous and next sequence point a scalar object shall
>have its stored value modified at most once by the evaluation of an
>expression. Furthermore, the prior value shall be accessed only to determine
>the value to be stored."
>
>I'd like to have the standard changed so breaking 5.4 would result in an ill
>formed program instead of unspecified behavour.

I haven't worked out a specific example, but I suspect that there are
constructs that violate 5.4 but cannot be detected by the compiler's static
analysis.  And since there's often disagreement in this newsgroup over
whether a particular expression meets the requirement "the prior value
shall be accessed only to determine the value to be stored", I think it
would be extremely difficult to program that distinction into compilers.

This seems like it's better left to QOI of compiler warnings, rather than
required constraint checking.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> I haven't worked out a specific example, but I suspect that there are
> constructs that violate 5.4 but cannot be detected by the compiler's
static
> analysis. And since there's often disagreement in this newsgroup over
> whether a particular expression meets the requirement "the prior value
> shall be accessed only to determine the value to be stored", I think it
> would be extremely difficult to program that distinction into compilers.

It is impossible to resolve all side-effects at compile-time, we can agree
on that. There is also a problem with aliasing, ie. when refering to an
object through multiple pointers/references. That aside, it wouldn't be that
hard, for the compiler, to verify that an expression contains max. one
non-const operator for each object, which is implied by 5.4. That way it
would, for instance, be possible to catch:

i=v[i++]; (where i, for instance, is int and v, for instance, is an array of
int)

Bo-Staffan


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8u96ip$16sno$1@ID-47792.news.dfncis.de>,
bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com says...
> > There is a feature I like in Java - the result of evaluating an expression
> > (or an argument list) is always "as if" it was evaluated in a
> left-to-right
> > order.
> >
> > That makes things like f(a++, a++) well defined.
> >
> > Not that I advocate actually writing such code but it seems to me that
> > making it well defined for C++ can be beneficial.  It will definitely not
> > break any existing code and I think that optimisation opportunity loss
> will
> > be minimal (if at all).
>
> A better solution, IMHO, would be to require the compiler to issue an error.
> Writing code with unspecified behavour can't be what the author intended.
> That way the compiler could still have to possiblity to make optimisations.
>
> Bo-Staffan

I advocate something a bit different. All prefix
increment/decrement operators should behave "as if"
the increment/decrement occurred immediately following
the previous sequence point and postfix operators
should behave as if they occurred immediately
preceding the following sequence point. Use of
multiple and combined prefix and postfix operators
would then be well defined, as would expressions such
as abc(++I, I, I--) which are currently undefined.

This ties the semantics of prefix and postfix
operators to the well understood concept of sequence
points. It also allows the compiler the maximum
flexibility in moving things around via the "as if"
rule. The flexibility is reduced from what is
currently allowed, because there are so few
restrictions that the result of primitive operators on
primitive data elements is undefined for simple, but
desirable cases. This approach does not break any
existing code since currently the result is undefined.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <MPG.14728e12e1c0d798989700@news-server.neo.rr.com>,
michael.finney@acm.org wrote:

> In article <8u96ip$16sno$1@ID-47792.news.dfncis.de>,
> bSoP_AsMteSfUfCaKnS_lankinen@hotmail.com says...
> > > There is a feature I like in Java - the result of evaluating an expression
> > > (or an argument list) is always "as if" it was evaluated in a
> > left-to-right
> > > order.
> > >
> > > That makes things like f(a++, a++) well defined.
> > >
> > > Not that I advocate actually writing such code but it seems to me that
> > > making it well defined for C++ can be beneficial.  It will definitely not
> > > break any existing code and I think that optimisation opportunity loss
> > will
> > > be minimal (if at all).
> >
> > A better solution, IMHO, would be to require the compiler to issue an error.
> > Writing code with unspecified behavour can't be what the author intended.
> > That way the compiler could still have to possiblity to make optimisations.
> >
> > Bo-Staffan
>
> I advocate something a bit different. All prefix
> increment/decrement operators should behave "as if"
> the increment/decrement occurred immediately following
> the previous sequence point and postfix operators
> should behave as if they occurred immediately
> preceding the following sequence point. Use of
> multiple and combined prefix and postfix operators
> would then be well defined, as would expressions such
> as abc(++I, I, I--) which are currently undefined.

Who benefits?

Currently working code does not benefit. Instead, it will become slower
because compiler optimisations will suffer. The loss may not be much, but
even a small loss without benefits is pointless.

Currently broken code that does not work might benefit. But then broken
code is probably broken in more than one way and will still be broken.

Code that is broken in principle because of undefined behavior but works
by coincidence is likely to break. (Note: Just because code invokes
undefined behavior doesn't mean it doesn't work. A programmer might write
i = i++; by mistake and there is the possibility that the compiler
actually produces the results that the programmer intended by coincidence
- whatever the intended result is).

Future code: Can anybody come up with an example where you would want the
defined behavior of multiple changes to the same object between sequence
points?

By the way, what would your proposal mean for the statements

   int i = 3;
   i = i++ + 4;

Will this produce i = 4 or i = 8? (Java would produce i = 7, but that is
not compatible with your proposal).

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <christian.bau-0811001643550001@christian-
mac.isltd.insignia.com>,
christian.bau@isltd.insignia.com says...
> Who benefits?
>
> Currently working code does not benefit. Instead, it will become slower
> because compiler optimisations will suffer. The loss may not be much, but
> even a small loss without benefits is pointless.
>
> Currently broken code that does not work might benefit. But then broken
> code is probably broken in more than one way and will still be broken.
>
> Code that is broken in principle because of undefined behavior but works
> by coincidence is likely to break. (Note: Just because code invokes
> undefined behavior doesn't mean it doesn't work. A programmer might write
> i = i++; by mistake and there is the possibility that the compiler
> actually produces the results that the programmer intended by coincidence
> - whatever the intended result is).
>
> Future code: Can anybody come up with an example where you would want the
> defined behavior of multiple changes to the same object between sequence
> points?
>
> By the way, what would your proposal mean for the statements
>
>    int i = 3;
>    i = i++ + 4;
>
> Will this produce i = 4 or i = 8? (Java would produce i = 7, but that is
> not compatible with your proposal).

We all benefit. The fewer undefined areas in the
language specification the better.  In the same vein,
I would argue that shifts of signed values should be
well defined and be identical to the result of
"arithmetic" shifts. Which is what I usually assume
and which almost all compilers generate. Since the
shifts of unsigned values are essentially the
"logical" shifts, clearing up this undefined area
would benefit anyone who needs arithmetic shifts and
must currently rely on undefined behaviour (or
assembly language or really bad code).

As far as your example, I would think that there has
to be at least a conceptual sequence point between
evaluating the expression "I++ + 4" and assigning it
to I. So, the result would be 7. Because "I++ + 4"
increments the value of I after it uses the value so
the expression is effectively 3+4 with a post
increment of I. Since that post increment of I should
then occur before the sequence point, and then I would
be assigned the new value of the expression, I would
then get 7 as its value with the intermediate value of
4 being discarded (or overwritten) by the optimizer.

However, if the standard mandates the sequence point
after the assignment, then the result of the
expression should be 4. I see no problem in using the
current definition of sequence points for code like
this. The result is still well defined just as code
such as "I = 4, I = 7" is well defined (and just as
useless for the multiple assignments).

What most people want is to be able to use expressions
like abc(I,I++) in a clearly defined manner.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Michael Lee Finney wrote:

[...]

> I advocate something a bit different. All prefix
> increment/decrement operators should behave "as if"
> the increment/decrement occurred immediately following
> the previous sequence point and postfix operators
> should behave as if they occurred immediately
> preceding the following sequence point.

This behaviour cannot be emulated with user-defined operators.

[...]

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <MPG.1473c2a7d3b9fbbf989701@news-server.neo.rr.com>,
Michael Lee Finney  <michael.finney@acm.org> wrote:
>We all benefit. The fewer undefined areas in the
>language specification the better.

This is not a good generalization.  Undefined != bad.  Undefined areas are
opportunities for hardware-specific optimizations, vendor extensions and
experimental features (which can later be standardized if they're popular),
etc.  Or, as in the case of things like f(i++, i++), they serve as a
message from the experts who make of the standardization committee that
this type of code should be discouraged.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Fri,  3 Nov 2000 20:52:16 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

} In article <8tv1vj$p25$1@nnrp1.deja.com>, wmm@fastdial.net writes
} >One caveat: 1.4p8 gives the criteria for extensions that are
} >permitted by a conforming implementation, and one is that such
} >extensions "do not alter the behavior of any well-formed
} >program."
}
} Thanks for that reminder. I forget that changes are also considered
} extensions.

There is a feature I like in Java - the result of evaluating an expression
(or an argument list) is always "as if" it was evaluated in a left-to-right
order.

That makes things like f(a++, a++) well defined.

Not that I advocate actually writing such code but it seems to me that
making it well defined for C++ can be beneficial.  It will definitely not
break any existing code and I think that optimisation opportunity loss will
be minimal (if at all).


Have fun,
Alex.

--
My email address is intentionally mangled to foil spambots.
Please remove the "---filter---" from the address for replying.
Sorry for the inconvenience.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8jce0ts4e7npn2fpbuaan6h71b34i4gj4k@4ax.com>,
Alex Oren <alexo@bigfoot---filter---.com> wrote:
>There is a feature I like in Java - the result of evaluating an expression
>(or an argument list) is always "as if" it was evaluated in a left-to-right
>order.
>
>That makes things like f(a++, a++) well defined.
>
>Not that I advocate actually writing such code but it seems to me that
>making it well defined for C++ can be beneficial.  It will definitely not
>break any existing code and I think that optimisation opportunity loss will
>be minimal (if at all).

If you don't advocate writing such code, why do you want to encourage it by
making it well defined?

Although I agree that the lost optimizations will generally be negligible,
what about the fact that compilers that happen to generate right-to-left
code will have to be modified?  Why force implementors to do work to
support a style of code that you don't advocate writing in the first place?
Don't they have enough work trying to support the good features of the
language, should you really be creating new work for them for *bad* ideas?

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]