On Wed, 10 Apr 2013 12:00:04 +0100, Manu <turkey...@gmail.com> wrote:
On 10 April 2013 20:53, Regan Heath <re...@netmail.co.nz> wrote:
False. In this first example we are compiling A and B together (into an
exe - I left that off) so the compiler has all sources and all uses of
all
methods of A (and B).
And if the program calls LoadLibrary() somewhere?
notVirt is virtual.
It may actually be (I don't know) but it certainly does not have to be
(compiler has all sources/uses) and my impression was that it /should/
not
be.
It doesn't have all sources. It could load a library. That can never be
guaranteed.
So, your counter example is this..
[shared source]
class A {}
[example DLL]
class B : A {}
compiled along with source for A.
[example application]
class C : A {}
compiled along with source for A.
main() {}
calls LoadLibrary which loads above DLL, DLL manifests an A, which is
actually a B, e.g.
A fromDLL = ...exported DLL function...
or perhaps we constrct a B
A fromDLL = new B();
And if we were to manifest our own C, derived from A
A local = new C();
the methods which would be virtual/non-virtual might very well differ. So
how can the compiler know what to do when it sees:
void foo(A a)
{
a.method();
}
Correct?
I must admit I don't know how a class is exported from a DLL. Presumably
the method address is exported. But, does the vtbl get exported, or do
virtual methods all map to a wrapper method which indexes the vtbl?
In any case, it seems to me that the underlying issue is the desire to
have 2 separate definitions for A. One from the DLL, and one local to the
application. And, for calls to optimised on the local one in the ususal
fashion, while maintaining the DLL mandated virtual/non-virtual methods at
the same time.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
