Disable GC entirely

[Regan Heath]

On Wed, 10 Apr 2013 11:39:20 +0100, Manu <turkeyman at gmail.com> wrote:
> All your examples all hinge on the one case where the optimisation may
> possibly be valid, a is _allocated in the same scope_.

Correct, that was the whole point.  I am trying to establish where the  
"problem" arises, starting from the most basic examples :)

> Consider:

The example below is, I presume, supposed to be a function call in user  
code where A is defined in a library, correct?

If so, I agree with the issues stated.

If not, if A, and B, and any other classes derived from A are all compiled  
at the same time(*) and we're producing an exe then the compiler has all  
the information it needs to decide which methods MUST be virtual, and all  
others should be non-virtual.

This is the point I was trying to establish with my simpler examples :)

(*) Yes, perhaps you compile a.d then b.d separately - this may result in  
the same problem case as a library, or it may not - I don't have the  
understanding/data to say one way or the other.

> void func(A* a)
> {
>  a.isVirt(); // is it? I guess...
>  a.notVirt(); // what about this?
> }
>
> We don't even know what a B is, or whether it even exists.

Assuming A and B come from a library and are not present in the source we  
are compiling with this function, yes.

> All we know is that A's methods are virtual by default, and they could be
> overridden somewhere else. It's not possible to assume otherwise.

If we're compiling A, and some number of sub-classes of A, and producing  
an exe, then from the definition of A, B, and all sub-classes we know  
which methods have been overridden, those are virtual, all others are  
non-virtual.

R

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