Disable GC entirely

Paulo Pinto pjmlp at progtools.org
Wed Apr 10 00:01:19 PDT 2013


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.

One nice feature of properties is that you can trigger actions 
when assigning/reading from properties.

This is very used in OO GUI and DB code in other languages.

>
> Can you demonstrate a high level class, ie, not a primitive 
> tool, but the
> sort of thing a programmer would write in their daily work 
> where all/most
> functions would be virtual?

I have lots of code from JVM and .NET languages with such 
examples.

OO code in the enterprise world is a beauty in itself, regardless 
of the language.

>>> Likewise, I like the GC, I just want to be able to control it.
>>> Disable auto-collect, explicitly issue collect calls myself 
>>> at controlled
>>> moments, and give the collect function a maximum timeout 
>>> where it will
>>> yield, and then resume where it left off next time I call it.
>>>
>>
>> I agree 100% and have that need too. I'd go further and also 
>> prefer the
>> ability to optionally ban certain language features from use 
>> from within
>> selective parts of my code base. As you say, I do not actually 
>> want to
>> outright ban the GC or any other language feature (I really do 
>> use
>> them!!!), it's only the desire to be able to have much better 
>> control over
>> it for the situations that demand precision and certainty.
>>
>
> Precisely.
>
> Having control over D and the GC like what we're taking about 
> in here can
>> turn D into a seriously awesome systems language unlike any 
>> other.
>
>
> Correct, it's not quite a systems language while the GC does 
> whatever it
> wants. But D needs the GC to be considered a 'modern', and 
> generally
> productive language.

Maybe something like VisualVM would help as well.

--
Paulo


More information about the Digitalmars-d mailing list