Re: public inheritance of interfaces and virtual (multiple) inheri
Alibek Jorajev wrote:
Hi Carl !
thanks for fast reply.
Of course, I will not cling to the death to use virtual inheritance.
But having virtual inheritance gives a nice possibility to use
i_MainDlg also to call functions specified in i_BaseA. Then,
such function call gets nicely delegated to Dlg (I think this is
almost same as using delegation to a sister class via virtual
inheritance, but here we restrict ourselves having only interfaces in
second line and one
of implementation inheritance). By this way, the user of MainDlg
does not need to swap pointers to i_Base_A and i_MainDlg, but can use
provided by MainDlg via single pointer (which can be obtained from
Singleton/factory) for example.
And yes, I made sure that /vmg /vmv are set every place, not
just for one individual file (I used Visual C++ 2005 in Studio 2005
8.0.50727.42). At each project of my solution.
However, I thought that /vmg is more general case and thus safer.
I will try now to use /vmb.
The most general case is /vmv with /vmg. The default is /vmv with /vmb.
However, in MFC, you need to declare a pointer to a member of a class
before defining the class. in message mapping. and then, in the same
class is defined. Alghough there is not mutually referencing classes,
can it be still a problem?
Possibly, yes - if the pmf declaration precedes the class definition, then
it's possible that in some parts of the code the compiler will choose a more
general representation, while in other parts it will choose an optimized
class. This need can arise if you define members in two different
classes that reference each other. For such mutually referencing
classes, one class must be referenced before it is defined.
Do you ever declare a pointer-to-member to an incomplete class? If
you don't, then using /vmb will never fix a problem (but neither
should it create one).
- No, I never declared such pointer, but codebase is large. so I need
to check it.
Are you sure that the crashes are related to pointer-to-member size?
-- No, of course, I am not sure. But what I sure is that system
crashes because of /vmg /vmv. and crashes at random places. exactly
same code with and without these compiler switches. This was all what
Without them it works fine. But warnings - they suggest that without
these compiler switches, we can end up corrupting pointers.
I will try with /vmg /vmv now.
but still, it not clear for me -- why it works without them ?
It may indicate a problem with improper use of pointer to member function,
or some assumption on pmf size. I have seen code where someone hacked out a
way to cast a pmf to an ordinary pointer. Of course, such a conversion is
completely undefined by the c++ standard, and techniques to extract an
ordinary function pointer from a pmf are generally sensitive to pmf
and the main question is that - is it safe to use bigger pointer to
member representations with MFC?
I don't know of any MFC-specific guidance with regard to pmf options, but
then I'm not an MFC user. Maybe someone else knows.