Tony Cook (tony@online.tmx.com.au) wrote:
> Mike Rubenstein Phoenix Contract (rubenst%occs.nlm.nih.gov) wrote:
> : Am I the only one appalled by the result of the following code according to
> : the standard?

> Why is it appalling?  Is is appalling that sizeof() has a similar
> effect?

I see a big difference.  sizeof never evaluates its argument.  I know that i
will not be incremented in sizeof(*(a + i++)) without looking at the entire
class hierarchy above the type of *a to see if there is a virtual function.

sizeof, for example, does not break the equivalence of a[b] and *(a + b).
The effect of sizeof a[b++] is always the same as the effect of
sizeof *(a + b++).

typeid sometimes evaluates, depending on the type of the argument.  As shown
in my example, typeid(a[b++]) may have a different effect on b
typeid(*(a + b++)) even if a is a pointer, so operator overloading doesn't
come into play.

An operator that sometimes evaluates its argument depending on type is a
disaster waiting to happen.

--
Mike Rubenstein

Steve Clamage (clamage@Eng.Sun.COM) wrote:
> rubenst%occs.nlm.nih.gov (Mike Rubenstein Phoenix Contract) writes:

> >Am I the only one appalled by the result of the following code according to
> >the standard?

> Don't give typeid an expression with side effects. The standard has
> to say what happens if you do, but you are not required to write
> such code. If you want the side effects, compute them first. If
> you don't want the side effects, don't write them.

What tripe!  We're talking about a standard, not how to code.

Saying that the standard has to say what happens is begging the question.
Why does it have to say this?  Why not a simple rule like "the typeid
expresson is always evaluated?"

I don't see any problem with that, but I've not examined this anywhere near
as closely as the committee should have.  Perhaps I'm missing something.
But the current specification threatens to be very prone to errors because
of its complexity.

Also, saying "don't give typeid an expression with side-effects" just doesn't
solve anything.  It may not be practical.  I gave an example that uses ++
because it is simple and easily (I thought) understandable.  How about code
like

 class A {
 };

 A& f(int);

 typeid(f(1));

What if f(int) has side-effects?  Remember, I may not have written the
function if it is part of a library and  I may need to use the same function
in the typeid as is used elsewhere in the program -- if other places need
side-effects, what choice do I have?

What if I'm not writing the C++ program?  Programs aren't always written
by people -- sometimes they are written by other programs.  If I'm working in
another language I may not have control, or even know, if a given expression
is going to be used as a typeid expression.

--
Mike Rubenstein

Mike Rubenstein Phoenix Contract (rubenst%occs.nlm.nih.gov) wrote:
: Am I the only one appalled by the result of the following code according to
: the standard?

Why is it appalling?  Is is appalling that sizeof() has a similar
effect?

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

Am I the only one appalled by the result of the following code according to
the standard?

 include <iostream>

 struct A
 {
   void f();
 };

 struct B
 {
   virtual void f();
 };

 int main()
 {
   A* a = new A[10];
   B* b = new B[10];

   int i = 0, j = 0;

   typeid(a[i++]);
   typeid(*(a + i++));
   cout << i << '\n';

   typeid(b[j++]);
   typeid(*(b + j++));
   cout << j << '\n';

   delete[] a;
   delete[] b;

   return 0;
 }

Unless I miss something, this will print out

 0
 1

--
Mike Rubenstein

rubenst%occs.nlm.nih.gov (Mike Rubenstein Phoenix Contract) writes:

>Am I the only one appalled by the result of the following code according to
>the standard?

Don't give typeid an expression with side effects. The standard has
to say what happens if you do, but you are not required to write
such code. If you want the side effects, compute them first. If
you don't want the side effects, don't write them.
--
Steve Clamage, stephen.clamage@eng.sun.com