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

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-10-11 16:30:44

AMDG

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

> 
> gpd wrote:
> > I do not think we want to consciously introduce these kind of bugs in
> >a boost library.
> 
> Let's not jump to conclusions before we've thought this through.  You
> are saying that the compiler might assume that a pointer to an object of
> type A can't possibly be an alias for a pointer of type B, which
> *inherits* from type A because A and B are different types?  That just
> doesn't make any sense.  Obviously A could be an alias for an object of
> type B, even if the standard says that an object of type A might not be
> encapsulated within an object of type B and therefore cast from A to B
> might produce undefined behavior, it doesn't mean that the compiler
> would ever misconstrue that the mean there is no legitimate circumstance
> in which a developer would cast an object of type A to B, or B to A,
> because that is expressly the purpose of subtyping and static_cast.  It
> wouldn't just break non-standard compliant code; it would break all
> code.  Therefore, it is safe to assume that what I'm doing, which
> currently works, will continue to work in the future.

If type A is non-pod and the object of type A is known statically
not to be an object of type B, then using the pointer to type
B in a way which requires it to really be what it claims to be
like calling a non-static member function gives enough information
to determine that the to pointers cannot be aliases for each other.
If there is sufficient information about the real types of BOTH
pointers, then the compiler can assume that they are different.

This condition can happen as in the example I gave where the definition
of the base class object was visible.

In Christ,
Steven Watanabe