Re: [boost] [GTL] - geometric template library - determininginterest

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-10-10 17:15:07

AMDG

Simonson, Lucanus J <lucanus.j.simonson <at> intel.com> writes:

> Yes, if the derived class adds virtual function pointer not present in
> the base class, or uses multiple inheritance its pointer value may
> differ from the address of the base class data enclosed within it.  I
> think it is safe to say that we understand this fact and can design
> around it.  Do you know of any other way the pointer values may be
> different? 

The pointers being different is not the only possible problem.

Consider the following:

struct base {
    int x;
};
class derived : public base {
    void modify() {
        x = 1;
    }
};
base b;

void foo(derived* d) {
    d->modify();
    b->x = 2;
}

void bar() {
    foo(static_cast<derived*>(&b));
}

The compiler may see that a member function of derived
is being called with the pointer.  Thus the pointer must
really point to an object of the type derived.  Thus it
cannot point to b.  Knowing that, the compiler is free to
reorder the operations after inlining.

void foo(derived* d) {
    b->x = 2;
    d->x = 1;
}

> 
> I don't for a minute believe that the behavior I am relying upon is
> unspecified or undefined.  It is specified in the compiler, and all the
> compilers somehow managed to agree on the definition and specify it the
> same way.  I would be quite surprised if it wasn't the standard that led
> to this remarkable standardization of C++ compiler front-ends.

I do not think this a good test.  The reason this works or
appears to work consistently is that this is the default
behavior if the compiler does nothing special.

In Christ,
Steven Watanabe