[lmi] virtual inheritance from noncopyable/obstruct_slicing

[Vadim Zeitlin]

 Hello,

 This is another email with questions which originally arose from the MSVC
build problems but seem to merit attention even if MSVC is not a concern.

 The first question is: why so many LMI classes inherit from both
boost::noncopyable and obstruct_slicing? If I understand the purpose of the
latter class correctly, it is used to prevent code like this from
compiling:

        class B : obstruct_slicing<B> { };
        class D : public B { };

        D d;
        B b;
        b = d;

But if B already derives from boost::noncopyable this seems to be
impossible anyhow because B (and hence D, unless someone specifically took
care to implement D assignment operator and/or copy ctor bypassing those of
the base class) doesn't have an accessible assignment operator. So what is
the reason for deriving from both classes, wouldn't just boost::noncopyable
be enough?

 The second question is why some classes (albeit not all) derive from
boost::noncopyable virtually. This seems to be totally unnecessary and
other than some dubious consideration of symmetry with obstruct_slicing I
just don't see any reason for this. And even if I'm missing something again
there is still the issue of deriving from it virtually in some classes but
not the others while I think the same kind of inheritance should be used
everywhere, i.e. in any case something needs to be done. And I believe that
the virtual keyword should be removed from the classes that use it, what do
you think?

 To summarize both of these questions, I'd like to replace all occurrences
of

        class T : [virtual] private boost::noncopyable,
                  virtual private obstruct_slicing<T>

with just

        class T : private boost::noncopyable

My interest in doing this, to return to the MSVC angle, is that due to a
compiler limitation (which is not quite a bug as it's probably meant to be
an optimization and it's arguably indeed a rather successful one) the
classes using virtual inheritance can't be used as wx event handlers with
MSVC by default: the representation of the pointer to members of these
classes is incompatible with the one used by wxEvtHandler and so any
attempt to use a method of such class as an event handler (either using an
event table entry or with wxEvtHandler::Connect()) results in a very
unclear (and this is definitely a bug) compiler error message

        error C2102: '&' requires l-value

This limitation can be fixed by using a special compiler option (/vmg)
which instructs it to use the most generic representation of pointer to
members. But as this option is non-default and has a cost (it doubles the
size of all pointer to members, whether they use virtual inheritance or
not), it is not used by wxWidgets MSVC build by default and hence I still
have to maintain a separate wx build (or rather (N+1)-st separate wx build)
just for LMI which was something I hoped to avoid. And the situation is
especially pernicious because the code compiled with and without /vmg can
be linked together without any errors but dies horrible during run-time (as
you would expect because different object modules use differently sized
pointers).

 So it would be really great if virtual inheritance could be avoided in the
classes used as wx event handlers. Of course, I wasn't about to ask you to
consider not using virtual inheritance just because of this MSVC-only
problem, but if it turns out that virtual inheritance is not needed anyhow,
I'd be very glad to get rid of it. Would this be possible?

 Thanks in advance,
VZ