[wx-dev] Re: #9149: wxWeakRef - Multiple bases, MSW
wxTrac
#9149: wxWeakRef - Multiple bases, MSW
---------------------+------------------------------------------------------
Reporter: arst | Owner:
Type: defect | Status: reopened
Priority: normal | Milestone:
Component: wxMSW | Version:
Resolution: | Keywords: wxWeakRef
Blockedby: | Patch: 1
Blocking: |
---------------------+------------------------------------------------------
Changes (by arst):
* cc: arst (removed)
* status: closed => reopened
* resolution: wontfix =>
Comment:
First, there was a discussion where the contents of the patch was agreed
on:
http://lists.wxwidgets.org/pipermail/wx-dev/2008-February/098097.html
Then, background: Visual C++ by default uses an optimization of Pointers-
to-members (PMF) that only works generally for single inheritance class
hierarchies. This of course is not according to C++ std and the background
was to optimize MFC size/speed performance some 10..15 years ago.
Unfortunately they made it the compiler default, and it has stayed so ever
since.
When using multiple base classes and PMF, we _must_ tell the compiler to
use the more general PMF form if we want to have PMF:s to unspecified
(general) classes.
>> Hence any projects using wx become incompatible with everything else
and, worse (???)
If one compilation module uses one internal representation of general PMF
and another compilation module uses a different one, they are not affected
at all as long as they don't pass PMF:s between eachother. And to exchange
PMF:s they typically use header files. And then the problem would be
resolved.
Usually PMF:s are used in template header files, for things like generic
callbacks, delegates. Such header files are included into a compilation
unit, not linked to.
I've used wx with this setting for some 9+ months now, in a quite complex
project. PMF:s are used in many places. In some of these, wx headwers are
included, in others not. The potential effects you're describing have not
been observed.
Is this comment about incompatibility based on some example?
> but it's wxWeakRef which should be changed, not the pointers
representation.
If we use multiple base classes, then general PMF:s should be for multiple
base classes. There's really no way around it.
As said before, Visual C++ in this sense is only works generally for the
single base class case. Sticking to that, one should not have multiple
base classes when using PMF:s.
The only workaround would be to have instead:
class wxObject : public wxTrackable { ... }
I.e. a pure single base class hierarchy rooted from wxTrackable.
For general PMF:s, one either must use compiler options: "/vmm /vmg" or
the "#pragma" in the patch. They both work fine, and that's after a lot of
use / testing.
It's true that it's easiest / safest if the whole project shares the
setting for PMF. This is really a very limited issue, since PMF:s are used
so rarely in interfaces, and when they are, they are, it's template code,
which keeps it all inside one compilation unit.
Given the non-std approach of VC++ in this area, a workaround must have
some cost. The only other way is to avoid multiple inheritance when using
PMF:s.
Regards
// ATS.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/9149#comment:5>
wxTrac
#9149: wxWeakRef - Multiple bases, MSW
-----------------------+----------------------------------------------------
Reporter: arst | Owner:
Type: defect | Status: closed
Priority: normal | Milestone:
Component: wxMSW | Version:
Resolution: outdated | Keywords: wxWeakRef
Blockedby: | Patch: 1
Blocking: |
-----------------------+----------------------------------------------------
Changes (by arst):
* status: reopened => closed
* resolution: => outdated
Comment:
Patch ID #9556 replaces this one.
Regards
// ATS.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/9149#comment:6>
wxTrac
#9149: wxWeakRef - Multiple bases, MSW
-----------------------+----------------------------------------------------
Reporter: arst | Owner:
Type: defect | Status: closed
Priority: normal | Milestone:
Component: wxMSW | Version:
Resolution: outdated | Keywords: wxWeakRef
Blockedby: | Patch: 1
Blocking: |
-----------------------+----------------------------------------------------
Comment(by vadz):
Replying to [comment:5 arst]:
>
> First, there was a discussion where the contents of the patch was agreed
on:
>
> http://lists.wxwidgets.org/pipermail/wx-dev/2008-February/098097.html
I didn't realize the consequences of this change back then.
> If one compilation module uses one internal representation of general
PMF and another compilation module uses a different one, they are not
affected at all as long as they don't pass PMF:s between eachother. And to
exchange PMF:s they typically use header files. And then the problem would
be resolved.
Unfortunately it wouldn't. The files (using different PMF representations)
would happily link together and crash when a pointer is passed between
them during run-time.
> I've used wx with this setting for some 9+ months now, in a quite
complex project. PMF:s are used in many places. In some of these, wx
headwers are included, in others not. The potential effects you're
describing have not been observed.
I would guess that all your objects files ended up using the generic
representation. Or you were very, very lucky. Of course, you're not a
typical object of my worry here: you're knowledgeable enough to recognize
and fix the problem when it arises. Many wxWidgets users wouldn't have a
clue (including some experienced C++ programmers coming from other
platforms who have no idea about this MSVC peculiarity).
> Is this comment about incompatibility based on some example?
Yes, I did have the pleasure of debugging these mysterious crashes in a
project I was working on.
> For general PMF:s, one either must use compiler options: "/vmm /vmg" or
the "#pragma" in the patch. They both work fine, and that's after a lot of
use / testing.
There is no doubt that they work if you use them for all your code. There
is equally no doubt that they don't work if you use them when building
only parts of it. Do you really disagree with it?
--
Ticket URL: <http://trac.wxwidgets.org/ticket/9149#comment:7>