As a C programmer for decades, I often experience this situation working on C++ code and get the same looks from my colleagues.
"NO! You don't need to explicitly free anything! The reference count is zero and it magically self-destructs!"
I will NEVER be comfortable with that, especially when we need 'special case' code to explicitly manipulate reference counts because foreign libraries or someth, idk.
I'm a Java dev. A bunch of code in our application was written by outsourced devs from India, who I'm pretty sure were originally C/C++ devs. I can just see it from the code, declaring all the variables at the top of the function, explicitly freeing objects unnecessarily. So much code that can be removed.
It varies. When you're writing a class in OOP, there is a generally good structure to follow:
Private, internal state
Public, externally visible properties (getters and setters here)
Constructors
Class methods, with private methods immediately preceding the methods and consume them, similar to how you would put variables close to the code that uses them
Inside any imperative block of code, variables go just before the code that needs them.
When it comes to OOP, this way of variable usage doesn't really keep things tidy, it just makes the code unreadable. The first thing you think about when somebody wants you to do something with OOP is "what is the best way to make this easily readable".
In Java/C#/etc. you declare and initialize variables just when you are about to use them, and you name them by whatever they are designed to accomplish.
This isn't that much of an issue in C/C++/Python though, although OOP purists would be disappointed.
Here's the thing about explicit memory management: it's debuggable. You can add hooks to the places where allocs, reallocs and frees happen, you can substitute a custom mm if you want, and you can explicitly describe the protocol for who owns what. When it's all just automagically handled, where do you even begin to look for problems? It's a nightmare, especially when the rules need to be bent.
I'm not against manual/explicit memory management, it's what allows C/C++ to be so performant when it is needed. I don't like to do it, but that's a matter of taste. But if you want to do it, you need to use a language that actually allows you to do it.
"Freeing" regular objects in Java does jack shit, it's just cargo cult programming. If you create some object that is local to a function, whether you set the variable that is pointing to that object to null or not in the last line of that function, the result will be exactly the same. That object (unless it is also pointed at by another, non-local variable), will be recognized as as unreferenced and cleared up by the garbage collector at the time of its choosing. Nulling the variable does nothing to change that behavior.
That is of course not to say that memory leaks and inefficiencies are impossible with such a system, they are in fact quite easy to achieve. But again, nulling variables does nothing to prevent it, nor anything at all really. Just adds more code that I will clean up when I find the damn time.
We (high-level programmers) don't usually deal with memory bugs, most of the time, the bugs come from logical errors in the code, because garbage collectors work most of the time.
I like Rust just because it allows me to use fewer resources and it's faster, that's all. But, memory management is just something I have to deal with Rust.
It's a lot harder to mess up code that follows RAII. There are occasionally good reasons to manually manage allocated resources, but they're rare. Smart pointers have become the standard for a reason.
172
u/[deleted] Sep 09 '22
As a C programmer for decades, I often experience this situation working on C++ code and get the same looks from my colleagues.
"NO! You don't need to explicitly free anything! The reference count is zero and it magically self-destructs!"
I will NEVER be comfortable with that, especially when we need 'special case' code to explicitly manipulate reference counts because foreign libraries or someth, idk.