Re: [Re: [Re: [gtkmm] ANNOUNCE: gtkmm 2.2.8]]
- From: Murray Cumming <murrayc usa net>
- To: Chris Vine <chris cvine freeserve co uk>, <Murray Cumming Comneon com>, <bradleyb u washington edu>
- Cc: <gtkmm-list gnome org>
- Subject: Re: [Re: [Re: [gtkmm] ANNOUNCE: gtkmm 2.2.8]]
- Date: Tue, 07 Oct 2003 09:13:01 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]