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

[Murray Cumming Comneon com]

Murray Cumming
murrayc usa net
www.murrayc.com 

> -----Original Message-----
> From: Chris Vine [mailto:chris cvine freeserve co uk] 
> Sent: Freitag, 3. Oktober 2003 21:15
> To: Murray Cumming Comneon com; bradleyb u washington edu
> Cc: gtkmm-list gnome org
> Subject: Re: [Re: [gtkmm] ANNOUNCE: gtkmm 2.2.8]
> 
> 
> On Friday 03 October 2003 8:12 am, Murray Cumming Comneon com wrote:
> >
> > Yes, that should have no pratical effect on anybody, but it 
> is a _change_
> > in API, and I don't want to make any API changes in a 
> stable branch unless
> > it is absolutely necesssary (as well as imperceptible). It is not
> > necessary. I'd rather not take the risk, and I'd rather 
> everyone knows that
> > we don't take risks.
> 
> OK, I understand.  However, it shouldn't cause a problem - 
> the fact that a 
> function/member name in one scope hides the same name if it 
> also occurs in 
> another scope up the inheritance chain insures that changing 
> inheritance will 
> result in a (theoretical) API _addition_ through inheritance, 
> but not a 
> modification of the API as previously existing and 
> implemented (in other 
> words, because of hiding it doesn't change overload 
> resolution).  It is 
> particularly safe in this case, which is why I say 
> "theoretically", because 
> protected inheritance only adds to the API for child classes 
> (which would not 
> be changed), and not for users of the classes.

But it is not necessary.

> 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.

>  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.

Murray Cumming
murrayc usa net
www.murrayc.com