Disable GC entirely

[Manu]

On 11 April 2013 06:50, Rob T <alanb at ucora.com> wrote:

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


I won't complain about this, but it'll prevent you from being able to call
into a very significant portion of the standard library. Browse through it,
especially the most basic of tools, like std.string, basically everything
allocates somewhere!
I'm not that enthusiastic about fracturing my code into sections that can
make use of the library, and sections that just can't.
A lot of work could be done to make the library not allocate I'm sure,
increasing the amount of library available in these isolated sections
maybe... but I'd rather see work done to add finer control of the GC, so I
can operate it in an acceptable manner.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130411/fb7827d1/attachment.html>