I surely prefer RAII to any garbage collection. It doesn't mean it's completely wrong though and has no uses at all. It's just of limited usefulness that's why languages which overuse it claiming it's always needed (like Java) are too limiting. If anything, GC should be optional, not mandatory.
Garbage Collection is Wrong
41–50 of 111 posts
Re: Garbage Collection is Wrong
#42As someone who's not interested in following every acronym and resource allocation strategy there is... is this even remotely useful? Lately I've gotten back into Java for Android, and after a very long time with Python, it's the first exposure in over a decade I've had to this argument...
...which, for some of us, isn't an argument, as we have basically no choice in the matter. But I'm still interested to know whether this is actually useful input or whether it's more holier-than-thou posturing.
To me, this is missing the forest for the trees. It's easy to argue about language implementation semantics when, in practice, it means almost nothing to anyone as we're stuck with the idiosyncrasies of the platforms we work on, even when we choose the platform.
I guess it's good that someone is looking at these things, but I can't see the utility in it. Best case scenario, this becomes a paradigm shift in new languages (which doesn't help us or anyone else for years) or gets implemented in the next major revision of language X (which doesn't go mainstream for years).
Re: Garbage Collection is Wrong
#43GC was developed because too many programmers were morons, not the other way.
That's a pretty moronic way of looking at it.
Re: Garbage Collection is Wrong
#44Earlier quoted context omitted.
To speak to point 2, of course this is possible but the time it takes to do a GC is not determinable. As for point 3, just because it's in use, doesn't mean it's correct. With the introduction of unique_ptr, most uses of new and delete can and should be factored out.
Can you give an example of any codebase not using any new or delete at all that compares in size? "Right or Wrong" are irrelevant in the face of "Practical or Not". The fact that all large pieces of serious code use new and delete would either imply that the author is smarter than all the people writing that code combined, or (more likely) he did not consider something w.r.t. the practicality of not using them. Let m…
No but it is the trajectory of the future and it's very practical. I'm not saying there aren't oddball cases that will require new and delete, but for the most part, it simply isn't necessary.
As for the citation, if you are immersed in the C++ community in general (going native, c++ now, subreddits, irc, accu meetings, etc), it's the general feeling.
Re: Garbage Collection is Wrong
#45not even sure where to start... 1. plenty of garbage collectors do not pause all threads or wait for memory to be full. 2. you CAN ask for gc anytime you want in java and in C# (you need not wait for it to happen) 3. new and delete are still integral to C++ (check out any large codebase, like llvm)
1. Can you give an example of some of these systems?
2. Designing your code in such a way that requires it to invoke the GC seems counter-productive. If your algorithm is producing a bunch garbage that is statically known, why not just release that memory explicitly? Invoking the GC is way more expensive than necessary here.
3. New/delete will always be used in performance critical code but I think the point is that in general it's not a good practice.
Re: Garbage Collection is Wrong
#46This is totally on point. Ref-counting / RAII is the only sane way to do resource management. It's super lightweight and easy to understand. The vast majority of resources are short-lived and don't create cycles. Our garbage collections "systems" should be designed for this case. Cycles are a special case required for few data structures. They are not the norm and we shouldn't ship a huge heaping mess of a garbage co…
I think in multi-threaded code ref-counting usually uses atomic_fetch_add instructions. This results in a memory barrier and is much more expensive that you might think.
Re: Garbage Collection is Wrong
#47Earlier quoted context omitted.
RAII is great, and should be used where appropriate. I'm not sure what it has to do with reference counting, though. Reference counting is just a particularly slow and unreliable form of garbage collection; I don't see why you would ever prefer it to a proper garbage collector.
Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic). Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles. I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.
Say you are implementing a self-tracking objects model for data management. How do you fix the reversal of control required to manage that? Specifically you need to go from the representative object to the controller to store the fact that you changed.
Re: Garbage Collection is Wrong
#48> Don't believe me? Then don't skim-read.
My hero.
Re: Garbage Collection is Wrong
#49Earlier quoted context omitted.
For example, two lists both contain a reference to the same object. Neither one is a sole owner, and you can't safely destroy the object until both lists are destroyed.
Then the lists should only have a weak_ptr to the object. Something is handling both list [1], that something could own the object, or maybe something external to that. Giving ownership of the object to both list is a design error [2]. [1] e.g. if the two list are an implementation detail of a data structure, the data-structure itself could own the objects in the lists. [2] Do non-deterministic garbage collectors tha…
I am mostly developing business applications. The user decided to view a couple of orders, orders reference products and some of the orders reference the same product. Who owns the product? Definitely non of the orders and neither the form showing the order. Well, I could attach them to the main form, but now they stay in scope until you close the application. This is not what we wanted. I could implement referencing counting - use shared_ptr - but well, the designers of garbage collectors tried it and found reference counting garbage collectors perform worse than collecting garbage collectors. Am I missing a obvious solution?
Re: Garbage Collection is Wrong
#50What's the catch?
You can run out of space on the stack, which has a smaller size than the heap, where new'd objects are placed. This can easily happen with large objects that own other large objects and it is difficult to debug without knowledge of the implementation of all of the child objects.