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

From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2007-10-10 10:19:41

From: Simonson, Lucanus J

> Fernando Cacciola wrote:
>> Pendantically speaking, there is no such thing as a "safe
>> reinterpret_cast". While this is somewhat permmited in production
>> code where the typical deadline is yesterday, here in boost you need
>> a definite need for using 
> 
>> that.
>> Anyway, can you explain in some detail how doesn't your adaptation
>> pattern avoid copying?
> 
> The ability to modify the contents of an object in place without
> copying 
> was the original intent of the entire exercise in generic programming.
> 
> If you have two classes
> 
> class A {...};
> class B : public A {...};
> 
> or by composition
> 
> class A {...};
> class B { A a; };
> 
> You know it is safe to reinterpret_cast A to B and B to A (because
> they are the same data, and differ in behavior only.)  

No.  5.2.10 [expr.reinterpret.cast] p7 of the standard says "A pointer
to an object can be explicitly converted to a pointer to an object of
different type ... the result of such a pointer conversion is
unspecified."  

Notes: 
- I have snipped the bit where it says you can sometimes cast to a
different pointer and back.  
- Casts between references are defined in terms of casts between
pointers.

If A is POD, 9.2 [class.mem] p17 guarantees that you can
reinterpret_cast B* to A* (but /not/ visa-versa).  If B were extended in
such a way as to be non-POD, then you lose even that guarantee.

There is /no/ guarantee that you can reinterpret_cast between pointers
to base and derived class.  (static/dynamic cast is different.  But even
then you can't cast an A* to B* if the A* doesn't point at the A base
object of a B)

It may work as you expect on the platforms you have used with the types
you have used - but it is not guaranteed by the standard.

> If this use of reinterpret_cast to change the behavior of an object
> is unacceptable for a boost submission that pretty much closes the 
> whole case, since the design pattern depends upon it in a very
> necessary way.

I don't think it is /absolutely/ unacceptable, but I think you would be
fighting an uphill battle.  

I also think you would need to show that you understood the limitations
(both according to the standard, and in practise).

-- 
Martin Bonner
Senior Software Engineer/Team Leader
PI SHURLOK LTD
Telephone: [phone] / 203894 (direct)
Fax: [phone]
Email: martin.bonner_at_[hidden]
www.pi-shurlok.com
disclaimer