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

[Chris Vine <chris cvine freeserve co uk>]

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.

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

Chris.