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

[Murray Cumming <murrayc usa net>]

Chris Vine <chris cvine freeserve co uk> wrote:
> On Monday 06 October 2003 6:45 am, Murray Cumming Comneon com wrote:
> [snip various bits about dynamic_cast and static_cast]
> 
> > Yes, I was thinking of virtual inheritance, not just multiple
inheritance.
> 
> You will see in a separate post that I have established that, with gcc, 
> v-tables as well as multiple inheritance will change the binary layout of 
> classes in a heirarchy, and that the use of reinterpret_cast in my test case

> would have caused a program failure.
>  The more I think about this the more 
> uneasy I get.  Navigating around a class heirarchy with reinterpret_cast 
> (rather than with static_cast or dynamic_cast, which can make offset 
> calculations) gives rise to undefined behaviour under the standard.  With a

> heirarchy with no virtual functions and no multiple inheritance, it is 
> nonetheless probably 99.9% certain to work, but in any other case (and I
will 
> look at the gtkmm code concerned) whether gtkmm still works is entirely 
> dependent on whether the classes to and from which the cast is made keep the

> same binary layout, which is a gamble with the compiler writer.

I do not think that there any any virtual methods in this particular case, so
I really do not think that this is a problem. Please do look at the code in
question. If you see any problem then please do report a bug. 
 
> Applying your test, with which I agree, of adopting the route which has less

> risk (your post of 3rd October), I am not at all sure that the risk of 
> reinterpret_cast failing on a target compiler is lower than the risk that 
> changing inheritance from private to protected will break the library ABI on

> that compiler (I have demonstrated that it will not break API).  Furthermore

> if the reinterpret_cast fails, the code is unusable with that compiler, 
> whereas with a changed ABI the dependent programs can at least be 
> re-compiled.
> 
> As you say, there is a choice to be made, neither of which are desirable in
a 
> stable release but one of them needs to be made (unless gcc-3.3.2 comes out

> with a handy compiler flag which allows static_cast to ignore access 
> controls).  Perhaps someone from the gcc project could comment on which is 
> more likely to break in a practical compiler implementation.
> 
> Also, releasing a library which the standard says has undefined behaviour
will 
> raise quality of implementation issues with professional users who have 
> policies about things like that.

Same reply as above.

> Anyway, if you are prepared to agree in principle a change from private to 
> protected inheritance and revert the reinterpret_cast, I am willing to do a

> binary check on gcc-2.9.3, gcc-3.2.3, gcc-3.3.1 and gcc-3.3.2-rc to make
sure 
> it does not change library ABI with them and submit a patch.

I would much rather have a patch for gtkmm 2.4, simple as it is.

>  (I cannot 
> promise that other compilers will not change the library ABI, but you cannot

> promise that other compilers will not choke on reinterpret_cast).  However,

> with other commitments it may take a couple of weeks.

Same reply as above.



Murray Cumming
murrayc usa net
www.murrayc.com