Disable GC entirely

[Regan Heath]

On Wed, 10 Apr 2013 09:56:01 +0100, Manu <turkeyman at gmail.com> wrote:

> On 10 April 2013 17:01, Paulo Pinto <pjmlp at progtools.org> wrote:
>
>> On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
>>
>>> [...]
>>>
>>>
>>> I do use virtual functions, that's the point of classes. But most
>>> functions
>>> are not virtual. More-so, most functions are trivial accessors, which
>>> really shouldn't be virtual.
>>> OOP by design recommends liberal use of accessors, ie, properties, that
>>> usually just set or return a variable. Wen would you ever want  
>>> @property
>>> size_t size() { return size; } to be a virtual call?
>>>
>>
>> Yes, if you want to change its behavior in a derived class.
>>
>
> That really shouldn't be encouraged. Give me an example?

I wrote some crypto code which had a property for the hash size, each  
derived class returned it's own size.  Now, in this case the property  
size() was called rarely, but it's still a valid example.

That said, I agree we don't generally want properties and other  
short-and-should-be-inlined methods to be virtual by default.  But.. is D  
really doing that?  I mean /actually/ really doing it.

I have read most of this thread in passing and I've seen the earlier  
discussion about classes in libraries etc and TBH I am not sure how/what D  
does in those situations.  Presumably if D does not have the source for  
the library then the library class would have to have all methods virtual  
- just in case it was derived from and I guess this is an issue that needs  
solving somehow.  But, I don't know if this is the case, or if this is  
even an actual problem.

That's not the most common case however, the common case is a class you're  
compiling with the rest of your classes and in this case D is not going to  
make your base class methods (which have not explicitly been overridden)  
virtual, they should be non-virtual and optimised/inlined/etc.  They just  
start out "virtually" virtual until the compiler is finished compiling  
them and all derived classes, at that point all non-override base methods  
should be non-virtual.

It would be interesting to see what the compiler actually does if, for  
example, you compile a file with a class then in a separate compile/link  
step compile a derived class and link.  Does D manage to non-virtual all  
non-overridden methods?  If so, can it do the same with a lib/dll combo?

> That's not an exampe. I want to see a class where every function SHOULD  
> be
> overloaded... That sounds like a nightmare, how can anyone other than the
> author ever expect to understand it? The fewer and more deliberately
> controlled the virtuals, the better, by almost every measure I can  
> imagine.

This isn't the reasoning behind making virtual the virtual default for  
methods.  The reason for doing it was simply so the compiler could be  
responsible for figuring it out without you having to label it manually.   
You're already labelling the derived class method "override" and that  
should be enough.  This was a choice of convenience and ultimately  
performance because you won't accidentally make a method virtual that  
doesn't need to be.

R

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