[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.

[CyberDildonics]

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?

You bringing up something unrelated doesn't mean anything just because you keep bringing it up.

Do you think anyone thought that nothing can be built without RAII? Did you think that was an argument anyone was making? Do you think someone walking barefoot means shoes don't do anything?

Is this an exam?

There is one singular question and you seem to think it's absurd to answer it and not veer off into a hundred different directions about unrelated projects and your favorite influencers instead of being able to focus on it.

it's that RAII comes at a large cost in terms of typing

If it automates things why would it have a typing cost? That makes zero sense.

it will "infect" your codebase,

How? It can be used or not.

requiring an all or nothing approach or you're actually back to manually managing memory

It's completely the opposite, you can use data structures that have destructors or not use them at all, this is not only not true it doesn't even confront the utility.

It will break modularization of your codebase, leading to subtle but substantive degradation.

These are strange claims, they don't have any evidence because you didn't explain why this would be true. It nonsensical, have you ever actually used these features? What does "substantive degredation" even mean or refer to? It's just running deallocation automatically, which you already have to do.

This is part of what leads to long compile times

No it isn't, it's running the same function at the end of a scope. Where are you getting this idea? Templates you could say this about, but a simple concept has nothing to do with it.

RAII adds temporal coupling between memory allocation and data lifetimes,

"Temporal coupling" doesn't make any sense, you have to deallocate memory anyway, why would it be any different to not have to write the line explicitly?

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.

Why would this make any sense? If you want to create a global you create a global. If you aren't freeing something when you don't use it, you're creating a global whether you want to or not.

This whole thing reads like being at the end of a game of telephone, there are no actual explanations in here and pretty much nothing that makes sense, but at least you actually focused on the question.

If you want to have a real explanation, especially to yourself, you should probably show a scenario on godbolt or something like that. It really seems like people have led you down a path that doesn't make sense and you haven't gone back and tested it yourself.

[jstimpfle]

> You bringing up something unrelated doesn't mean anything just because you keep bringing it up.

It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language.

> There is one singular question and you seem to think it's absurd to answer it and not veer off into a hundred different directions about unrelated projects and your favorite influencers instead of being able to focus on it.

You made me do it by repeatedly talking down on me in a condescending tone, when I tried to keep it simple and referred to external sources. What the heck. You want a simple reply. I cannot give you one, except for, "RAII is this simplistic solution that makes the language complicated while still being by far not enough to handle interesting use cases. It has turned out to be wrong and misguided every time I've tried to use it, and here are a million examples why".

> If it automates things why would it have a typing cost? That makes zero sense.

It automates generating boring boilerplate code (which is good on one hand but it doesn't reduce the semantic complexity AT ALL, so actually it just promotes doing the wrong thing by making the wrong thing easier). To generate the boilerplate code it requires type machinery. What doesn't make sense about this?

Why don't YOU start telling ME?

>> it will "infect" your codebase,

> How? It can be used or not.

To use it e.g. in containers, you then have to also use it for the things contained -- e.g. unique_ptr<T> or vector<T> or whatever, you will have a bad time if you don't model T's destruction with a C++ destructor too. Also you can't just insert random manually managed objects within a group of RAII managed objects, because that will break the "reverse destructor calls" assumption.

It's a viral thing.

>> It will break modularization of your codebase, leading to subtle but substantive degradation.

>These are strange claims, they don't have any evidence

I explained why: internals have to get moved to public API in practice. This is almost the definition of breaking modularization.

>> This is part of what leads to long compile times

> No it isn't, it's running the same function at the end of a scope. Where are you getting this idea? Templates you could say this about, but a simple concept has nothing to do with it.

Why are you being so stubborn? Destructors (like other methods) practically require classes to be fully exposed (that you can protect them with silly public/private/protected specifiers doesn't change the fact they're exposed), requiring includers to pick up transitive dependencies. That results in huge amount of included code per TU, and results in far too many TUs that have to be rebuilt on incremental changes.

This is a very well known thing.

> "Temporal coupling" doesn't make any sense, you have to deallocate memory anyway, why would it be any different to not have to write the line explicitly?

Why doesn't it make sense? In practice, allocation is coupled with initialization and destruction is coupled with deallocation. It's literally in the name, Resource Allocation Is Initialization. You can work around it, sure, but it's painful and literally just an escape hook to escape the very thing you're arguing for.

> If you want to have a real explanation, especially to yourself, you should probably show a scenario on godbolt or something like that. It really seems like people have led you down a path that doesn't make sense and you haven't gone back and tested it yourself.

ON GODBOLT? Are you kidding me? I've been arguing all day how RAII is a simplistic rigid mechanism builtin to a language that will lead to slow creeping systemic issues, in practice, in my experience, in larger and more complicated systems, especially with performance and abstraction requirements. I CAN NOT explain to you what sucks about it in a godbolt. You can use RAII fine for simpler programs. You can use it fine in a godbolt. You can use it fine for leetcode. etc.

Asking for a Godbolt example of architectural coupling is like asking for an assembly listing proving that a database schema is hard to migrate.

[CyberDildonics]

It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language.

No, it's claiming that because someone can do something that there must not be a better way to do it. Games were written in assembly, that doesn't mean that's the best way to do it.

I've been arguing all day

You've been avoiding it all day then finally making claims after six replies.

vector<T> or whatever, you will have a bad time if you don't model T's destruction with a C++ destructor too

So? What do you think that looks like in C? For loops and nested for loops, which all need to be hand written or copy and pasted and to happen at the right time. If you start dealing with early returns or gotos you need to have all those nested for loops copy and pasted multiple times.

I explained why: internals have to get moved to public API in practice.

This makes no sense, you would just move something into a function if it needs to take ownership. In C you have nothing to indicate ownership and every function in every API needs to have auxiliary documentation to say whether it is going to own the memory you give it or not.

Why are you being so stubborn?

I keep asking for the same thing and you keep running away from it.

Destructors (like other methods) practically require classes to be fully exposed

This doesn't make any sense, it automates something you have to do any way.

ON GODBOLT? Are you kidding me?

Is there something wrong with an actual program that shows actual evidence? This seems like a basic demonstration is earth shattering to you.

I CAN NOT explain to you what sucks about it in a godbolt.

If you can't demonstrate it with actual source code then you just have claims and no evidence.

[jstimpfle]

> If you can't demonstrate it with actual source code then you just have claims and no evidence.

I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale.

I CAN demonstrate it with actual source code, but you are unwilling to look it up. You are disagreeing without making the tiniest effort. Not being willing to make an effort by itself is fine. But you're being contrarian in the worst and laziest way.

Do you not understand the concept that I can't explain the world to you from the ground up? You say no to everything without trying to understand it. Your "rebuttals" indicate you're not willing to follow me in the slightest and you reject even the most common lore (for example the thing about C++ class features (destructors, methods...) leading to exposure of internals in public headers, leading to every TU including the world). Or you are intentionally trolling me. You are being uncooperative and you're the single worst interaction I've had on this platform. Now please get off my lawn.

[CyberDildonics]

To recap, there are all sort of detrimental effects to just freeing memory when a variable goes out of scope, but they can't be explained or demonstrated in any way.

I could tell it was all going to go this way from the second comment, I'm always fascinated by people with rock solid beliefs that can't explain them in any way.

I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale.

They do because it's just automatic resources within a scope.

I CAN demonstrate it with actual source code, but you are unwilling to look it up.

Why don't you link something besides a name of a big C project and explain it. The idea that someone making a project in C somehow means other features and tools are terrible isn't even logic. That would mean that one project in a language from the 70s would negate every garbage collected and dynamically typed scripting language. It makes no sense in any way. It's like saying because someone road a bike 20 miles cars are terrible.

Do you not understand the concept that I can't explain the world to you from the ground up?

You don't seem to be able to explain anything at all.

You say no to everything without trying to understand it.

You don't give any explanations, they are just claims, do you understand that? Do you know what evidence is? It's the thing you say you can't provide.

You think that somehow something simple like automatically running a function you have to run anyway is a problem, it's nonsense.

By your own logic the fact that https://github.com/chromium/chromium has 1.7 million commits to your project's 4,385 means that modern C++ is more than 380 times as effective.

for example the thing about C++ class features (destructors, methods...) leading to exposure of internals in public headers

That's a matter of dependencies and doesn't have anything to do with destructors.

you're the single worst interaction I've had on this platform.

Now we're to the "I don't like how you're saying it" part of the no evidence playbook. This happens when someone can't admit that they don't have any information and they can't believe that people won't accept them repeating claims as evidence.

Your own project has plenty of the bugs that destructors and contained memory allocation avoid. Raw heap allocations, raw mem copies etc.

https://github.com/EpicGames/raddebugger/issues/855

Here's a complex memory cleanup race condition that's 'solved' with a sleep function. https://github.com/EpicGames/raddebugger/issues/735

even the most common lore

I think it's time to admit to yourself that you have accepted some internet youtuber personalities as a religious belief and that you haven't questioned these beliefs with thoughts that go beyond the claims of the cult.