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

[Chris Vine <chris cvine freeserve co uk>]

On Monday 06 October 2003 6:45 am, Murray Cumming Comneon com wrote:

[snip ]

> I think it is sensible not to install gtk+ 2.3 on top of gtk+ 2.2 yet, but
> that does not mean that we should not be using it for development. It is
> very easy to use a separate, additional, install prefix. And it is very
> very easy with jhbuild (from gnome's cvs).

I build different GNOME's and different versions of gcc in different 
subdirectories of /opt, so I will take up your suggestion.

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

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.

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

Chris.