Re: [Re: [gtkmm] ANNOUNCE: gtkmm 2.2.8]



On Saturday 04 October 2003 8:49 am, Murray Cumming Comneon com wrote:
>Chris Vine wrote:
> > We should at least be able to make the change in gtkmm-2.4
> > since it is an API
> > addition of a very weak kind.
>
> Yes, I have said that I want to make the change in gtkmm 2.4, and there are
> TODO comments in gtkmm 2.4 saying that. Anybody is free to submit a patch
> to do that. You do not need to wait for me to do it for you.

I will not be installing gtk+-2.3.  Once gtk+-2.4 is out against which I can 
test gtkmm-2.3, I will submit a patch unless someone has already done that.

> >  reinterpret_cast is never
> > guaranteed to give
> > the right result, since it normally just involves a
> > straightforward bit for
> > bit transfer to the new type.  It would give positively the
> > wrong result if
> > any multiple inheritance is involved (that is, in any case
> > where a pointer to
> > child does not hold the same value as a pointer to parent
> > with respect to the
> > same object).  And for any case, without or without multiple
> > inheritance, the
> > result is in theory implementation dependent.
>
> I think that, wherever a static_cast<> worked, a C-style cast (or a
> reinterpret_cast<>) is probably OK. If multiple-inheritance was an issue
> there then we would have had to use a dynamic_cast<> anyway.  In this case, 
> the class is not multiply inherited.

This is not quite right.  A static_cast casting down an inheritance path will 
carry out offset calculations where necessary, and one case where it is 
necessary is multiple inheritance.  A static_cast of pointers and references 
can be used with multiple inheritance unless the inheritance is virtual and 
the cast is from a shared base class (that is, the inheritance tree is 
diamond shaped), in which case as you say a dynamic_cast must be used when 
casting from the virtual base to a child which inherits it from two parents.  
The offset calculations made by the compiler with a valid static_cast with 
multiple inheritance will not occur with a reinterpret_cast, so the two will 
not necessarily give the same result.

I agree that in our case, since there is no multiple inheritance, the right 
result is almost certainly given by a reinterpret_cast in practice (at least, 
as long as parent and child either both have v-tables or neither have 
v-tables, as I suppose that could possibly affect offsets, I am not really 
sure, and may be implementation dependent).  The standard only guarantees the 
result of a reinterpret_cast to be usable where the cast it to a type (such 
as an int) large enough to take all its bits and it is then cast back again 
to the same type as the original.

Chris.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]