gennaro_prota@yahoo.com (Gennaro Prota) wrote
> >From the current C++ standard, clause 5p5: "If during the evaluation
> of an expression, the result is not mathematically defined or not in
> the range of representable values for its type, the behavior is
> undefined, unless such an expression is a constant expression (5.19),
> in which case the program is ill-formed."
>
> Hmm... "during" the evaluation? Ok, that's probably just bad wording.
> The main point is: AFAIK, except in some
contexts
> (e.g. controlling
> expression of a #if, array bounds), a compiler is not required to
> evaluate constant-expressions in compile time, right? Now, let us
> consider, for instance:
>
>   if (a && 1/0)
>       ...
>
> with a, to fix our attention, being *not* a constant expression. The
> quote above seems to say that since 1/0 is a constant
> (sub-)expression, the program is ill-formed. Is it the intent that
> such ill-formedness is diagnosable at run-time? Or is it the intent
> that the above gives undefined behavior (if 1/0 is evaluated) and is
> not ill-formed, because they meant to write:
>
>   "if an expression is evaluated but its result[...]
>    the behavior is undefined, unless such an expression is a
>    constant expression (5.19) __that shall be evaluated at
>    compile-time__, in which case the program is ill-formed."

Consider that undefined behavior and ill-formed programs are
similar, in some ways -- they both indicate that the programmer has
no right to expect the program to "work." The main difference is
that ill-formed programs must be dianosed at compile time, while
undefined behavior doesn't need to be.

Okay, it's obvious that you already understand this distinction. But
the reason that it's relevant here is that the standard goes to such
pain in this passage to determine which case applies. It's undefined
behavior UNLESS there's a constant-expression, in which case it's
ill-formed.

I think that it's clear here what the intent is -- diagnose the
condition whenever possible (i.e. whenever the math is being done
at compile time), but the rest can be deferred until runtime if
needed.

However, take a look at 5.19/3 -- arithmetic constant expression.
I think it's already clear that constant expressions shall be
evaluated at compile time, whenever possible.

At any rate, I would accept your alternate wording as synonymous with
what's already in the standard.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota <gennaro_prota@yahoo.com> wrote:
+
+>From the current C++ standard, clause 5p5: "If during the evaluation
+ of an expression, the result is not mathematically defined or not in
+ the range of representable values for its type, the behavior is
+ undefined, unless such an expression is a constant expression (5.19),
+ in which case the program is ill-formed."
+
+ Hmm... "during" the evaluation? Ok, that's probably just bad wording.
+ The main point is: AFAIK, except in some contests (e.g. controlling
+ expression of a #if, array bounds), a compiler is not required to
+ evaluate constant-expressions in compile time, right? Now, let us
+ consider, for instance:
+
+  if (a && 1/0)
+      ...
+
+ with a, to fix our attention, being *not* a constant expression. The
+ quote above seems to say that since 1/0 is a constant
+ (sub-)expression, the program is ill-formed. Is it the intent that
+ such ill-formedness is diagnosable at run-time? Or is it the intent
+ that the above gives undefined behavior (if 1/0 is evaluated) and is
+ not ill-formed, because they meant to write:
+
+  "if an expression is evaluated but its result[...]
+   the behavior is undefined, unless such an expression is a
+   constant expression (5.19) __that shall be evaluated at
+   compile-time__, in which case the program is ill-formed."

Hmmmmm.  Very interesting.  I agree that your wording is the
appropriate specification and that the current wording seems
to say something else.

Tom Payne

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

>From the current C++ standard, clause 5p5: "If during the evaluation
of an expression, the result is not mathematically defined or not in
the range of representable values for its type, the behavior is
undefined, unless such an expression is a constant expression (5.19),
in which case the program is ill-formed."

Hmm... "during" the evaluation? Ok, that's probably just bad wording.
The main point is: AFAIK, except in some contests (e.g. controlling
expression of a #if, array bounds), a compiler is not required to
evaluate constant-expressions in compile time, right? Now, let us
consider, for instance:

  if (a && 1/0)
      ...

with a, to fix our attention, being *not* a constant expression. The
quote above seems to say that since 1/0 is a constant
(sub-)expression, the program is ill-formed. Is it the intent that
such ill-formedness is diagnosable at run-time? Or is it the intent
that the above gives undefined behavior (if 1/0 is evaluated) and is
not ill-formed, because they meant to write:

  "if an expression is evaluated but its result[...]
   the behavior is undefined, unless such an expression is a
   constant expression (5.19) __that shall be evaluated at
   compile-time__, in which case the program is ill-formed."

??

Genny.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]