Disable GC entirely

Rob T alanb at ucora.com
Wed Apr 10 13:50:46 PDT 2013


On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
> 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 can paste almost any class I've ever written, there is 
> usually 2-4
> virtuals, among 20-30 functions.
>

In my case it was a C++ virtual class used to supply a common 
interface to various database libraries. This is not a usual 
thing, so your point is valid, and I'll agree that most often 
your classes will have proportionally far less virtual functions 
overall. It's mostly the base classes that will contain the most 
virtual functions, but derived classes generally outnumber them.

>>
>> Mark your properties as final?
>>
>
> That's 90% of the class! You are familiar with OOP right? :)
> Almost everything is an accessor...

Based on what I've learned from this thread, to get the best 
performance I'll have to wrap up almost all my D classes with 
"final", or take the more painful alternative route and move all 
non virtual functions into UFCS.

I can understand the argument in favor if UFCS as the "final" 
solution, however it's something I'd have to try out first before 
making a conclusion. Off hand it seem like more work (an example 
with static if's was shown already), and for code structuring and 
readability it seems to me it won't be helpful. Again these are 
my first impressions without actually trying it out, so who 
knows, it may work well despite my concerns.

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

The GC issue is a recurring one (how many threads on this topic?) 
because the current implementation directly interferes with the 
stated goals of D being a systems language.

Not only can the GC be fixed in simple ways (eg just give us 
programmers more control over how and when it does its job), but 
we can do one better than just improving the GC, and it's through 
marking sections of code as off limits to anything that may 
allocate, and even better than that in more general terms, 
prevent the use a feature (or features) of the language that is 
not appropriate for a marked section of code. That'll make me 
very happy.

--rt


More information about the Digitalmars-d mailing list