Disable GC entirely

[Manu]

On 10 April 2013 21:09, Regan Heath <regan at netmail.co.nz> wrote:

> 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.


I feel like I'm being ignored. It's NOT POSSIBLE.

 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


That sounds overly complex and error prone. I don't believe the source of
an object is actually trackable in the way required to do that.
I can't conceive any solution of this sort is viable. And even if it were
theoretically possible, when can we expect to see it implemented?
It's not feasible. The _problem_ is that functions are virtual by default.
It's a trivial problem to solve, however it's a major breaking change, so
it will never happen.
Hence my passing comment that spawned this whole thread, I see it as the
single biggest critical mistake in D, and I'm certain it will never be
changed. I've made my peace, however disappointing it is to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/71cc5a97/attachment-0001.html>