Disable GC entirely

[Regan Heath]

On Wed, 10 Apr 2013 11:59:32 +0100, Dicebot <m.strashun at gmail.com> wrote:

> On Wednesday, 10 April 2013 at 10:53:26 UTC, Regan Heath wrote:
>> Hmm..
>>
>>> A is not final.
>>
>> True.  But, I don't see how this matters.
>>
>>> A has no internal linkage. It can be inherited from in other  
>>> compilation unit.
>>
>> 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).
>>
>>> 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.
>>
>> R
>
> If it is compiled all at once and compiled into executable binary than  
> yes, you examples are valid and compiler _MAY_ omit virtual.

Exactly the point I was trying to make.  I wanted to establish the point  
at which the design problems (what D defines/intends to do) arise, vs when  
the implementation problems arise (DMD not doing what D intends).

> But
> a) DMD doesn't do it as far as I am aware.

Maybe, maybe not.  I have no idea.  My understanding of the design  
decision is that DMD will eventually do it.

> b) It is a quite uncommon and restrictive build setup.

Maybe at present.

Lets assume DMD can remove virtual when presented with all sources  
compiled in one-shot.

Lets assume it cannot if each source is compiled separately.  Is that an  
insurmountable problem?  A design problem?  Or, is it simply an  
implementation issue.  Could an obj file format be designed to allow DMD  
to perform the same optimisation in this case, as in the one-shot case.   
My impression is that this should be solvable.

So, that just leaves the library problem.  Is this also insurmountable?  A  
design problem?  Or, is it again an implementation issue.  Can D not mark  
exported library methods as virtual/non-virtual?  When user code derives  
 from said exported class could D not perform the same optimisation for  
that class?  I don't know enough about compilation to answer that.  But, I  
can see how if the library itself manifests an object of type A - which  
may actually be an internal derived sub-class of A, there are clearly  
issues.  But, could DMD not have two separate definitions for A, and use  
one for objects manifested from the library, and another locally for user  
derived classes?  I don't know, these are all just ideas I have on the  
subject.  :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/