Maybe D is right about GC after all !

[bachmeier]

On Wednesday, 20 December 2017 at 00:38:58 UTC, Jonathan M Davis 
wrote:
> On Tuesday, December 19, 2017 23:53:04 bachmeier via 
> Digitalmars-d wrote:
>> On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:
>> > What do you think of the following comment to that article?
>> >
>> > "In well-written modern C++, memory management errors are a 
>> > solved problem. You can just write code, and know that the 
>> > compiler and library will take care of cleaning up for you, 
>> > just like with a GC-based system, but with the added benefit 
>> > that it’s deterministic, and can handle non-memory resources 
>> > such as file handles and sockets too."
>>
>> I'm no C++ expert, but isn't that because of the use of unique 
>> pointers and shared pointers? And aren't shared pointers 
>> reference counted and stuck with the usual limitations 
>> associated with reference counting?
>
> What limitations are you concerned about? Certainly, shared_ptr 
> comes with whatever pros and cons come from non-intrusive (i.e. 
> not built into the object) reference-counting, but from I've 
> seen, there really isn't much of a downside to them 
> (_especially_ if you're comparing them to manual memory 
> management). Mostly, you just have to worry about using 
> weak_ptr when you'd otherwise have a circular reference. Sure, 
> using the GC is easier but not by much. In my experience, you 
> can generally just use shared_ptr and not worry much about 
> memory management, and you get mostly deterministic 
> destruction, unlike the GC (it's mostly, because there are 
> times when stuff sticks around a lot longer than you might 
> expect, because something has a reference to it, which isn't 
> always obvious; it's still technically determinstic, but the 
> effect can seem pretty non-deterministic sometimes). There are 
> plenty of C++ programmers who have no problem with shared_ptr 
> who would feel quite leery about using the GC, and for some 
> stuff, the determinism of reference counting can be critical. 
> With a GC, you can mostly not worry about such things, but 
> occasionally, you have to be careful, or you'll have problems 
> with resource management because on the non-determinism (e.g. 
> you really don't want sockets to closed based on when the GC 
> collects the socket object). And whether RC or GC is better for 
> performance depends heavily on what you're doing. RC tends to 
> slow everything down slightly but usually doesn't have bursts 
> of memory collection (though it can when you free a large tree 
> of objects at once), whereas the GC doesn't slow stuff down as 
> it goes along, but it has definite bursts where performance 
> tanks, because a collection is being run. I'd say that from D's 
> perspective, the main advantage of the GC over RC is that the 
> compiler can guarantee that it's @safe, which is more more 
> problematic with RC - that and you don't have to worry about 
> circular references with the GC like you do with RC.
>
> Overally, I don't think that it's particularly clearcut whether 
> RC or GC is better overall. The big thing is that the memory is 
> managed automatically rather than manually.

That's what I'm getting at. The comment shared by Mark does not 
contradict the blog post. The C++ community gave up on manual 
memory management, just taking a different route to automatic 
memory management, with the associated costs and benefits.