[jstimpfle]

> This is the statement that no one seems to be able to back up.

Actually there are many explanations of systemic issues arising from reliance on RAII. Both Jon and Casey are very good explaining the matters.

> Instead you start talking about a third person making a debugger for some reason as if the solution to appealing to authority is more appealing to authority.

A third person (already mentioned in a parent comment), who is creating an extremely snappy and powerful debugger using those exact approaches under discussion.

[CyberDildonics]

Actually there are many explanations

So lets hear them.

A third person (already mentioned in a parent comment), who is creating an extremely snappy and powerful debugger

Who cares? They have nothing to do with anything, why are you avoiding a technical discussion of facts to talk about your favorite influencers?

[jstimpfle]

> So lets hear them.

There are few people delivering more in-depth explanations of their claims, like literally thousands of hours of content. You can just look it up. If you disagree, please disagree. Personally I find what they say articulates almost 100% of my independent experience. And I do systems programming in C++ full-time (file systems / desktop app infrastructure). Personally I've made at least 9 serious attempts of building robust and maintainable systems on top of C++ features like RAII and templates and have always returned to simple straightforward C-style code. And I've had to work many times with existing C++ codebases that had bought into these features, and it always seemed like a giant waste of time, a way to add more spaghettis to a hot mess. And also, any technically convincing C++ codebase I've seen always seemed to make only very light use of C++ features. Not going to argue more here.

> Who cares? They have nothing to do with anything

Quite the opposite, it's a third person from the same circle making the same kind of claims (there are more persons), who have, contrary to what you say, actual evidence to back up their claims. You could just go ahead and check these works out yourself and see if it convinces you that the methods they claim to be better are actually better.

[CyberDildonics]

These are classic zero evidence replies. Go and "do your own research", "look it up yourself", and then nothing but repeating your claims and not even realizing that isn't evidence.

Here it's actually worse, I don't even know what the specific claims you're talking about are.

If this was so simple and you know it so well just spell it out.

You can just look it up.

Or you can just look up what literally everyone else does and relies on in systems programming.

I've seen always seemed to make only very light use of C++ features.

So what? You not using something has nothing to do with an actual explanation of its shortcomings, you realize that right?

there are more persons

Then where is the actual evidence and explanation? Why is it so difficult even after multiple replies to have a shred of evidence or technical explanation?

It's you and the three guys you are fans of against the entire world of systems programming, because scope based resource management and ownership is what people need the vast majority of the time because most resource lifetimes are determined by scope.

If you're going to reply again, try to have some explanation of what your claim is and why it makes sense on a technical level instead of just trying to tell someone to go and prove your ambiguous claim for you.

Also saying that you ignoring something is somehow an explanation for why it doesn't work, is like someone claiming helicopters don't work because they don't use them to get around.

[jstimpfle]

I told you what to check out. I'm not regurgitating this, I've done it often enough.

Have you spent 1 minute cloning the raddebugger, 3 seconds to build it, and 0.5 seconds to launch it, to be convinced that it is a solid product?

> It's you and the three guys you are fans of against the entire world of systems programming

What is this "entire world of systems programming"? From what I've seen, there are very few accomplished experts who would disagree a lot with what e.g. Jon/Casey/Ryan have to say.

What are you working on?

[CyberDildonics]

I told you what to check out.

No you didn't, you have no information and don't even have links. What kind of twilight zone fever dream is this where you say nothing at all and pretend you already gave some sort of evidence. This is the no evidence playbook in a nutshell. Come up with unrelated nonsense, try to divert away from the question, tell the other person to go make your argument for you, say you already gave the evidence...

You had five comments and didn't even get started with confronting the actual question.

Have you spent 1 minute cloning the raddebugger, 3 seconds to build it, and 0.5 seconds to launch it, to be convinced that it is a solid product?

In what world does this have anything to do with anything being talked about? You need to focus.

From what I've seen, there are very few accomplished experts who would disagree a lot with what e.g. Jon/Casey/Ryan have to say.

From what I've seen it's every accomplished expert except for them, but that again is an appeal to authority logical fallacy which you seem to be in love with.

Why don't you say what it is they actually have to say about destructors? If this is so simple and your heroes already laid it all out for you, why can't you do it? Why can't you give even the simplest explanation when people have supposedly already explained it for you?

[jstimpfle]

> If this is so simple

I _never_ said it was simple. It is actually very subtle, which is also why I made many attempts at integrating RAII style programming for many projects. RAII works for applications with simple lexical and local lifetimes and ownership. But it's not a good fit for more complex systems with more global and coordinated allocation and ownership patterns in my experience. The concept of ownership and lifetimes encoded by it are too simplistic (when in reality, these terms are not even well defined), as is evidenced also by the various extensions to the machinery over the years (such as exceptions, move/copy asignment/constructors, rvalue references, unique_ptr, shared_ptr, trivially_copyable, trivially_destructible...) that contributed to form the probably most complex and hard to read language out there.

A big part of the problem is that there is no easy migration path from a smaller program with simpler lifetime and ownership patterns (relying on RAII) to a larger program with much more complex patterns (gradually discarding RAII/reworking allocation and ownership strategies). It is hard to refactor stuff that happens "between the lines" as part of the language rules, besides being hard to read also (unless the patterns are trivial).

>> raddebugger

> In what world does this have anything to do with anything being talked about? You need to focus.

Like, in the world where I've referenced this in 3 of my 4 previous comments, as an example of a serious application built without RAII, which leans heavily into arenas, resulting in extremely compact and fast code?

> Why don't you say what it is they actually have to say about destructors?

Is this an exam? I referenced these guys instead of regurgitating because they can do it better, the content is out there, and I hardly could do justice to the matter in a few lines. If you need a couple more catchy but badly written phrases, it's that RAII comes at a large cost in terms of typing, and even though it automates some painful code, it will "infect" your codebase, requiring an all or nothing approach or you're actually back to manually managing memory, in fact you can not insert manual frees between arbitrary RAII destructor calls.

It will break modularization of your codebase, leading to subtle creeping degradation. It breaks separation/abstraction of memory management from data representation across module boundaries. This is part of what leads to long compile times that are very common with C++ code bases, as typically type definitions (including any internal matters and their dependencies) will be fully exposed in the headers instead of hidden in implementation files.

RAII adds temporal coupling between memory allocation and data lifetimes, which is a disadvantage as you scale your codebase up. And under the hood, RAII is still fundamentally built on a model of individual object thinking, allowing for the typical classes of memory bugs, like use-after-free if you do tree type or even spider web type object graphs (which sometimes is just what you have to do).

Separate allocation approaches on the other hand allow for better modularization and abstraction, and allow to handle allocation more centrally instead of cluttering allocation conerns across all types of a codebase.

That's it finally for me, this is a rushed summary and as said other people have explained this much better. I've also had enough of your condescending replies. Have a good day.

EDIT: if you are looking for text content instead of video rants, checkout https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a... as an example of a well written treatment in this area. But really, these 3 guys (besides others) are all very good at explaining that stuff in videos too, just use google please and make up your own mind.