Comment by jstimpfle
5 days ago
You keep "asking" for evidence but the only evidence presented by yourself is that you have merely surface-level understanding of the subject matter, and are looking for arguments, not insight and critical examination.
It's your claim that destructors are harmful so the burden of proof is on you.
People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate, which require no explicit cleanup once the destructor is implemented.
This is the opposite of C where even though the resource cleanup needs to happen on scope end, it is not automatic, and so becomes a source of bugs. This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
This automation also removes boilerplate so there is less management that needs to be done when using data structures.
What was your evidence or explanation?
> It's your claim that destructors are harmful so the burden of proof is on you.
I have given a variety of arguments why I think the C++ RAII specifically has downsides. You can accept them or ignore them, but don't act like I didn't give arguments.
> People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate,
Once again you're explaining beginner C++ do me. Are you still doubting if I understand this argument? My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs. This is scripting and plumbing. It's not interesting to me. Systems programming is not so much about stack scoped lifetimes.
RAII systematicing object lifetimes and cleanup, thus enabling exceptions and implicit or uncontrolled control flow, may sound nice on paper, but turns out we shouldn't want them in the first place. What RAII leaves for me is a system that will automatically call nested object's destructors when I delete something. It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.
> This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
If I were you, my response would be: The burden of proof is on you, show the evidence. But my answer is, yes that is right, but everything is a tradeoff, and the issues caused by manual cleanup are also somewhat exaggerated by C++ people, and the issues caused by blindly buying into the corset of C++ types are not well understood by C++ zealots (I've done my best at explaining them).
Issues caused by C approach are also a matter of design and approach to programming in general. It also depends on the actual problem you're solving. The linux kernel for example doesn't exactly have the easiest or most beautiful code to follow, but surely it's one of the most technical codebases out there, one that solves difficult problems (performant resource multiplexing for programs that it doesn't even know). On the other hand, the debugger code base I've referenced doesn't have any gotos for example, nor even early returns (or almost none, not sure).
Find me a single example of programs that run as fast and are as productively maintained as these two codebases in their respective areas? I believe there aren't any.
This should be plenty evidence to a reasonable mind, but that isn't you.
I have given a variety of arguments why I think the C++ RAII specifically has downsides.
I don't think you did, I think you just said it has downsides over and over.
Once again you're explaining beginner C++ do me.
Don't ask for basic knowledge then get upset when you get it.
My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs.
This is what the vast majority of values have. Some escape one scope and get cleaned up in another one. This also includes values inside data structures.
It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.
Again, this isn't an explanation, it's just you saying "I don't think it's good, I don't like it", but you aren't explaining why. This isn't evidence, it's just you restating "this is bad". Why is it bad? "I told you it's bad!!".
thus enabling exceptions and implicit or uncontrolled control flow
Exceptions aren't uncontrolled flow and you can also not use them. Something else being enabled doesn't mean the unrelated feature is bad. This also implies that every other language that isn't C is terrible because they have some sort of automatic cleanup. Now java and python are unstructured by your own definition?
If I were you, my response would be: The burden of proof is on you, show the evidence.
You don't have an explanation of why the burden of proof is on me. Everyone uses these techniques in system software now. You are the odd person out, that's why the burden of proof is on you.
I also gave you a very good explanation and you said "you're explaining basic C++ to me". I am, you asked for it and you didn't poke any hole in why it's wrong.
the issues caused by manual cleanup are also somewhat exaggerated by C++ people
It means memory leaks and crashes which everyone has been fighting for 50 years.
This should be plenty evidence to a reasonable mind, but that isn't you.
Someone running a marathon without shoes doesn't mean shoes are bad. Just because an old program is written in C, that has no bearing on if other tools are good or not. This is not a logical conclusion. Unix was written in C too, does that mean destructors are bad? No one said it's impossible to write a program in C now that C++ exists.
Why can't you give a single basic explanation instead of making the same claim over and over?
2 replies →