You don't like GC? Do you?

Stanislav Blinov stanislav.blinov at gmail.com
Fri Oct 12 19:43:02 UTC 2018


On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh wrote:

> Over the lifetime of the script, it processed more memory than 
> my computer had. That means I needed a memory management 
> strategy other than "allocate everything". The GC made that 
> quite easy.

Now *that* is a good point. Then again, until you run out of 
address space you're still fine with just plain old 
allocate-and-forget. Not that it's a good thing for production 
code, but for one-off scripts? Sure.

>>> People demonstrably have trouble doing that. We can do it 
>>> most of the time, but everyone occasionally forgets.
>> 
>> The GC isn't a cure for forgetfulness. One can also forget to 
>> close a file or a socket, or I dunno, cancel a financial 
>> transaction.

> By lines of code, programs allocate memory much more often than 
> they deal with files or sockets or financial transactions. So 
> anything that requires less discipline when dealing with memory 
> will reduce bugs a lot, compared with a similar system dealing 
> with sockets or files.

My point is it's irrelevant whether it's memory allocation or 
something else. If you allow yourself to slack on important 
problems, that habit *will* bite you in the butt in the future.
But the other end of the spectrum is also harmful. That's how we 
get those "good" APIs such as XCB that fragment the hell out of 
your heap, force libc on you and make you collect their garbage.

> It's good enough for a lot of people most of the time without 
> thinking about things much.

That's precisely the line of thinking that gave us Java, C#, 
Python and other bastard languages that didn't want to concern 
themselves with the hardware all that much. 30 years of 
"progress" down the drain.

> It reduces the frequency of problems and it eliminates 
> use-after-free

Not in D it doesn't. Unless you only ever write @safe code, in 
which case you're not in the "without thinking about things much" 
camp.

> and double-free, which are sources of data corruption, which is 
> hard to track down.

Agreed.

> And in the context of a one-off script, I'm probably not going 
> to worry about using the GC efficiently as long as I'm not 
> running out of memory.

Sure, *that's* the appropriate message. Not the "use the GC, it's 
not as bad as you think".

>> If you "forget" who owns the data, you may as well "forget" 
>> who writes it and when. Would GC help then as well? You need 
>> to expend pretty much the same effort to track that.
>
> That's why we have the const system.

Oh please, really? Const in D? And you're still talking about 
people that don't like to think about things much?


More information about the Digitalmars-d mailing list