Disable GC entirely

[Regan Heath]

On Wed, 10 Apr 2013 12:00:04 +0100, Manu <turkeyman at gmail.com> wrote:

> On 10 April 2013 20:53, Regan Heath <regan at 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/