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.
> 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.
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.
> 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.
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.
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.
Now you've provided two links and they contain little evidence to back up your claims. Linking issue 735 suggests that you've misunderstood the part about a "Sleep", which evidences either your lack of capacity to grok the context of the issue, or evidences your unhealthy adversarial stance (I strongly suspect the latter).
> 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 haven't been able to take the most obvious uncontentious claim from me. But if I'm not explaining as you say, what are YOU doing?
Are you seriously too stubborn to accept that exposing a destructor (or any other method) in a header file requires exposing the class's definition (private method declarations including signatures, include internally used headers for internally used data structures, which again have methods, which have dependencies...) in C++? And when any of those not-real-dependencies changes, you have to rebuild everything needlessly? Are you somehow mentally unable to see how long compile times can subtly degrade a project over time?
Because I didn't need any youtuber personality to find that out for myself. And for some humility, the fact that I was able to see that suggests it's not particularly hard to find out.
> 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.
And also I didn't claim it, you fantasized it and I can't help but ridicule you for having such wild ideas. To make such claims you would actually have a closer look at a project.
> 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.
How is that by my own logic? But please accept that this is the work of mainly 1-2 persons, and compare _hours_ of build time (35 MLOC) to 3 seconds of build time (300K LOC).
> You think that somehow something simple like automatically running a function you have to run anyway is a problem, it's nonsense.
You are misrepresenting what I've said so badly it's not funny anymore. I've said multiple times that maybe this function shouldn't even exist. And even if the function has to exist, maybe it shouldn't be coupled so hard, at a language level, with the actual state & logic definitions. I did provide reasons why I've perceived the coupling to be an architectural problem.
I would be very open to a discussion when this can or can not be a serious problem and what are possible tradeoffs and points in the design space. It wouldn't make me feel bad and wouldn't take away from my claim that there is actual evidence for the issues being discussed. But with a person like you, that's not possible.
> That's a matter of dependencies and doesn't have anything to do with destructors.
I've explained multiple times why I think it does. If you want a destructor declared in C++, you have to give the full class definition.
> 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.
No, it happens when I can't believe how you haven't managed to stop talking down on me instead of making an effort to be anything other than an annoying adversary. That's all.
> 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.
I think it's time for you to shut up. You are providing zero evidence for your baseless (even counter-factual) accusations towards myself. What you say makes ZERO sense.
your lack of capacity to grok the context of the issue
Now we're firmly into the insults phase. You can just admit that you don't know about something or that you don't have evidence, or you can ask questions, but resorting to insults instead of just saying "I don't know" or "I haven't considered that" or "I'm fine with what I'm using so I haven't worried about what other people are doing" is unfortunate.
you've misunderstood the part about a "Sleep"
I repeated what was in the comments. This is another example of claims without evidence, you realize that right? You didn't explain it and how I was wrong, you just said "no, nu uh".
3 seconds of build time
Are you talking about build times now? What happened to all the stuff about being terrible for the APIs and so toxic for the whole system that you can't write anything in godbolt?
how you haven't managed to stop talking down on me
Now it's time to play both sides and fling insults but pretend that me asking for evidence is talking down to you.
I've explained multiple times why I think it does. If you want a destructor declared in C++, you have to give the full class definition.
Finally an explanation of some sort. Too bad this isn't true. Do you know that the implementation can be in a compilation unit just like C?
you are providing zero evidence for your baseless (even counter-factual) accusations towards myself. What you say makes ZERO sense.
You believe things without evidence and you have said where they come from. Then when asked for evidence you grasp at anything from insults to completely unrelated things like a single program that you like which demonstrates nothing. Those are the actual facts.
> I repeated what was in the comments. This is another example of claims without evidence, you realize that right? You didn't explain it and how I was wrong, you just said "no, nu uh".
I was merely giving you a second chance to notice by yourself that the Sleep-Code in question is code that is being debugged, not part of this project. But instead of double checking, again you've been relentlessly continuing on your trajectory.
You've ended up furthering your wild accusations without entertaining the possibility that I might be not completely wrong on all fronts, and you might be only half right (or less).
> Are you talking about build times now? What happened to all the stuff about being terrible for the APIs and so toxic for the whole system that you can't write anything in godbolt?
It's one of the topics, one of the manifestations of the systemic issues I was talking about, if you had paid any sort of attention.
> Finally an explanation of some sort. Too bad this isn't true. Do you know that the implementation can be in a compilation unit just like C?
You are still not understanding? I gathered you seem to be a game developer of some sorts but you don't understand the simplest basic facts about C++?
Please show me how you can call a destructor in C++ without seeing the declaration of the destructor. (I mean calling it directly of course, since calling it indirectly would refute your claim that a destructor is needed -- since you can't have an arbitrary intermediate function called automatically by RAII).
Or show me how you can see the declaration of the destructor without seeing the definition of the class.
> Nope, destructors have nothing to do with this and this was never something you mentioned before. If it was you could show it with godbolt.
How about you simply Ctrl+F for "build time" or "compile time" and admit you have been lying, have been extremely adversarial, and have been incredibly lazy?
> Show me. They are just functions, usually one or two lines.
Isn't it strange that I'm now creating a godbolt containing absolute C++ basics as a youtuber personality fangirl, since apparently I'm only repeating stuff I don't understand, which has to be why I can't express myself and provide evidence?
It is beyond me how you don't seem to know what I'm talking about, but here you go... This should provide reasonable evidence of the lack of ergonomics when using C++, and how problematic this class stuff is from various technical standpoints.
As you mentioned, in C style programming, we could instead simply forward declare a struct, than forward declare some functions. One line for each. Good header hygiene. Clean. Done. But noo, this is C++ and we can't have straightforward code and low coupling.
How about you simply Ctrl+F for "build time" or "compile time" and admit you have been lying, have been extremely adversarial, and have been incredibly lazy?
More insults but there is no difference here.
I looked at your godbolt link, which part of this does C avoid? Is your whole argument here that you have to define a class' data even though you have to do the same thing in C?
Is it your argument against an optional feature seriously that you can't use the PIMPL pattern from the 90s ? Holy mother of god, that's what is so important? Every struct and class definition you have ever written compiles in a fraction of a second on hardware from 15 years ago this makes no sense at all. It even took you an entire novel of "nu uh" and "this program was written in C so everything else is bad" to get there.
What happened to all the toxic program destroying architecture effects? Now it boils down to something that is no different but without it all the same memory bugs persist.
Rebutting your wild and easily disproved claims where it's necessary.
> I looked at your godbolt link, which part of this does C avoid?
Should I spell it out again for you? With non-class programming, you can do
struct Foo;
struct Bar;
Bar *bar_create();
void bar_destroy(Bar *bar);
void foo_doThing(Foo *foo);
Foo *foo_create(int x, int y, Bar *bar);
void foo_destroy(Foo *foo);
And that's literally the API, clean and readable. Now granted, it doesn't do RAII, but here's the essence of the API, in a form that you can actually improve and develop and refactor, and which doesn't require you to rebuild the world if you changed something in a remote corner of the codebase.
This is super well known common lore, and if you haven't noticed this yourself and haven't heard many people talking about this, you simply don't know what you're talking about.
> Every struct and class definition you have ever written compiles in a fraction of a second on hardware from 15 years ago this makes no sense at all.
I'm not repeating once again how this requires you to include the world for the smallest thing which is extremely painful.
> Is it your argument against an optional feature seriously that you can't use the PIMPL pattern from the 90s ? Holy mother of god, that's what is so important? Every struct and class definition you have ever written compiles in a fraction of a second on hardware from 15 years ago this makes no sense at all. It even took you an entire novel of "nu uh" and "this program was written in C so everything else is bad" to get there.
This is not about single-build times (which are much more affected by by template metaprogramming), but about quadratic incremental rebuild scaling. And "in a fraction of a second" is a ridiculous argument when it's well known that C++ single build times are spectacularly bad and developers have to wait way too much for clean rebuilds too.
You just don't get it. And no, you don't do PIMPL. It doesn't scale at all. It's realistic to PIMPL a plain struct once in a while, but NOT with C++ classes with methods etc on a regular basis. It's not ergonomic to do so, it requires even much more boilerplate to do the simplest thing, and it makes it incredibly hard to change and fix and evolve anything. Plus, PIMPL does add a runtime indirection btw. It's BAD.
Again, I know what I'm talking down not because I'm repeating what "my heroes" said but because I've actually tried to make it work, many times. It doesn't work. And you're not doing PIMPL either. Want to know how I know? BECAUSE IT DOESN'T WORK AND YOU ARE JUST TALKING.
> Now it boils down to something that is no different but without it all the same memory bugs persist.
You can't be serious. Now you claim that's the only thing I said? No, I've said many other things. You're a loudmouth who doesn't understand the most basic thing, so we have to spend days before you accept the tiniest straightforward common sense argument that you could just google. Do you want to go down the next rabbit hole? Because I don't, I'm so done with you.
Now you have a destructor, you just have to remember to run it when the pointer goes out of scope. If you have early returns, error handling gotos, better remember to put in all the right places and none of the wrong places. At least in this scenario you know you own the memory. If you aren't making and destroying the data structure pointer and you just get it from a function or another data structure what now? Do you destroy it or is it just a reference? What function do you use? Time to check the header file and the documentation, hopefully that exists.
Not only that, but you have a pointer to the structure instead of it living on the heap. Now you have unnecessary indirection, allocation and pointer chasing when in C++ you could just treat it like a value. If you have a heap allocation in there you are now hopping from one pointer for the struct allocation to another pointer for the actual data allocation.
With your API you created an object with none of the huge advantages of being able to treat it like every other value in modern C++.
Everyone figured out how fragile this was since it started 50 years ago. Decades ago people worked out that the same problems happened constantly and came up with solutions which brought us (most of us) to where we are now.
This is not about single-build times
Now it's not about build times? I thought it was and you had said that all along? Now the story changes again.
I'm not repeating once again how this requires you to include the world for the smallest thing which is extremely painful.
Nope. You only need a class definition. Definitions don't take up any compilation time.
And "in a fraction of a second" is a ridiculous argument when it's well known that C++ single build times are spectacularly bad and developers have to wait way too much for clean rebuilds too.
People don't get themselves into bad build times because of simple class definitions. All 6MB of sqlite compiles in a single second. When people have C++ build time problems it's because of templates.
you don't do PIMPL.
I never said I did, I avoid it because that's basically what you are doing here.
Plus, PIMPL does add a runtime indirection btw
You added one already. PIMPL is the same as your indirection from heap allocating a predeclared struct so that you can return it from your constructor. The price is heap allocation and indirection.
It's long been clear that you don't understand what you're talking about when you're criticizing what I say. You don't realize that I understand everything you say and I'm only explaining where your line of reasoning breaks. The concerns you raise are beginner level C++ object thinking. You still haven't understood what I've said. It has turned out that the actual zealot is you, you're just a follower of mainstream ideology, following conventions without understanding them. Being part of the mainstream seems to mean you feel legitimized to talk down on others who are looking for solutions to genuine, serious problems. Following the mainstream will give you predictable results, but also with a low ceiling of what you can achieve this way.
> Nope. You only need a class definition.
How hard is it to understand that to get a class definition, all the stuff that's used inside the class, including declarations of internals like private fields and methods, needs to be included first? How hard is it? It seems like you are terminally unable to see it. Have you never touched a seemingly unimportant header file and had to rebuild 80% of your project? Because that's the common case in most real world C++ projects (and also some badly designed C projects btw.), in my experience.
> Now it's not about build times? I thought it was and you had said that all along? Now the story changes again.
Are you insane, you first critized me for making too many different points, then later you claimed I had NEVER talked about build times, which I refuted with a simple Ctrl+F argument. Then later you critized me for talking ONLY about build times. Now you critize me again for talking about a variety of things?
While I have stressed from the beginning that I'm talking about systemic problems, which manifest in lots of ways. Maybe Ctrl+F for "and here are a million examples why" for example?
You are a weasel with no purpose other than talking down on me, and you haven't made a single interesting argument. Get lost.
> All 6MB of sqlite compiles in a single second
Sure, a while ago, I even compiled it in 300ms using tcc (as a test). Do you know why that works? Because sqlite is written in C, without insane C++ classes and features. They compile everything as a single file (like raddebugger does too btw., a legitimate approach but I'm not saying this is the solution for everyone), circumventing the quadratic translation unit scaling problem.
> You added one already. PIMPL is the same as your indirection from heap allocating a predeclared struct so that you can return it from your constructor. The price is heap allocation and indirection.
A PIMPL object is one that is referenced as a pointer (of void-type or forward declared type) in a struct trying to protect implementation details and dependencies, because C++ doesn't exactly want you to do that.
The price of an actual C++ PIMPL object is that you'll go insane duplicating all the methods and writing all the call forwards.
This is NOTHING like a forward declared C struct, which is the exact opposite. There is NO duplication and call forwarding. You haven't got a clue what you're talking about.
A forward declared C struct does not add another level of indirection. You can't put the object itself directly on the stack unless you know the struct definition, that is obvious. It's the price to pay for true abstraction, abstracting from the internals of the object and treating it uniformly as a pointer value. But that's not a problem at all, since you would never want to put abstracted objects on the stack. Putting objects on the stack is how you write tiny scripty toy applications. In systems programming, object lifetimes don't correlate to function call lifetimes, so you cannot put objects on the stack. If you are able to put most of your objects on the stack by value, you are working on a toy app.
Contrast objects here with plain structs, for example struct Float3 { float x, y, z; }. Of course you expose those as values, these are stateless objects. And putting them on the stack is fine. That has nothing to do with PIMPL or implementation hiding AT ALL.
> With your API you created an object with none of the huge advantages of being able to treat it like every other value in modern C++.
There is no "like every other value" in C++, regardless of how hard people are trying, and regardless of how much complexity these people pile on top of this language.
The only successful "every other value" is plain data, which you can simply copy as bytes. I could queue a lecture now why Unix was successful with its file concept of "raw bag of bytes", but I'm done with you. Good bye.
you don't understand what you're talking aboutAre you insane,You are a weaselGet lost.
Lots of insults, but the difference here is that I know exactly how to do what you're doing in C, but it doesn't seem like you ever tried out modern C++.
How hard is it to understand that to get a class definition, all the stuff that's used inside the class, including declarations of internals like private fields and methods, needs to be included first? How hard is it?
This is a matter of dependencies and if your dependencies are simple definitions too it isn't going to matter. You are going to have to have definitions of your structs and functions in C too. A data structure without dependencies in C++ is no different than a data structure without dependencies in C. This isn't a language issue and has nothing to do with destructors.
without insane C++ classes and features.
It isn't destructors that cause long build times, if it was you could prove it. I said this multiple times but you're mixing a bunch of stuff together because you know staying on topic doesn't match what you're upset about.
I'm talking about systemic problems, which manifest in lots of ways
You didn't give any explanation of these, you just made a lot of claims. You still seem to think claiming something with no explanation is evidence. A kid saying they run fast over and over doesn't prove anything, you have to show it.
You haven't got a clue what you're talking about.
They are both forward declarations which I avoid like the plague for all the reasons I outlined before. Your whole schtick is that you want forward declarations and don't care about all the ownership and value semantics that save you from 50 years of C bugs.
There is no "like every other value" in C++, regardless of how hard people are trying, and regardless of how much complexity these people pile on top of this language.
Another claim without evidence. Make a value, it goes out of scope. Make an 'object' data structure, it goes out of scope. Move it if you need to, so simple!
which you can simply copy as bytes.
Copy constructors do this if you need them to. You can't just use plain structs with static sized arrays for everything, at some point you need to make real data structures that use the heap and then you will need to manage their memory. It could be automated for you but you might have to be a little more open minded.
You are continuing to fight strawmans I have never said and continuing to not get what I said and continuing to lecture me about beginner level C++. I am bored.
> Move it if you need to, so simple!
Move it, so simple, pointer invalidation.
Have you thought about... not moving it? So simple! "I need to move the outermost layer of a complicated structure, because I'm too stubborn to have just put this structure on the heap in the first place -- with nodes that link to it, and I'm not sure if other structure point to it... but anyway I NEED to move it, and I'm happy to implement all silly move and copy constructures and conform to this rigid ruleset even though there is no point in 90% of the cases, and that will lead to incredibly hard to diagnose bugs", said... no competent systems programmer ever.
Have you considered why C++ is like a pile on top of a pile of fixes, exceptions, copy semantics, move semantics, rvalue references... That is the polar opposite of simple.
Obviously you have not. But if you want to know, the reason why is that they are trying to treat things as values that are not values but stateful objects. They are trying to make a toolbox of hacks to treat everything the same. It does not work. It is a beginner level cardinal sin.
> at some point you need to make real data structures that use the heap
Do you remember when you were arguing that you want to avoid putting things on the heap because performance, and I said allocating things on the stack is for toy programs, like.. in my last post from 1 hour ago? I think you must have forgotten. Now you're claiming you want to allocate on the heap and I am not doing real datastructures on the heap???
Please give up. It is embarassing.
Or better, please go read any C++ codebase with templates and classes and copy semantics and move semantics. Get more brain damage as a result. And please leave me alone.
It works for everyone else, I'm not sure why this is controversial.
You are continuing to fight strawmans
Like bringing up PIMPL for no reason?
Have you thought about... not moving it?
No, because I want to have ownership semantics and be able to return data structures from functions while having clear ownership that is part of the program and not knowledge that has to be gleamed from source code or learning from crashes.
Have you considered why C++ is like a pile on top of a pile of fixes, exceptions, copy semantics, move semantics, rvalue references... That is the polar opposite of simple.
Which one is the argument against destructors? The simplest thing in the world. Copying and moving are solutions to problems you already demonstrated, you just don't want to admit that you and everyone else has them.
Now you're claiming you want to allocate on the heap and I am not doing real datastructures on the heap??? Please give up. It is embarassing.
It's interesting to claim (without evidence) that I don't know what I'm talking about while saying stuff like this. If you follow what I said before the fact is that with your forward declarations you are putting the structs on the heap so that they become globals and can outlive the constructors. Then whatever fields they contain are going to be pointers to the heap for the actual data of the data structure. When you want that data you have to dereference the pointer to the struct, then dereference the pointer to whatever arrays you are using. This is double indirection. It is more allocations, more memory frees, more pointer dereferencing (all of which are slow) and not necessary. In C++ with value semantics that first struct would be on the stack and gets moved or elided out of the function that creates it. You can't do this with forward declaration because you don't know the size yet.
Or better, please go read any C++ codebase with templates and classes and copy semantics and move semantics. Get more brain damage as a result.
How many did you read?
And please leave me alone.
You don't get to fling a bunch of insults then tell someone to leave you alone. I know you want it both ways but that isn't how it works.
> It works for everyone else, I'm not sure why this is controversial.
Show the evidence. It does not. It introduces vast amounts of complexity. So much that they were thinking they had to extend the syntax. Great, from rule of 3 to 7, from 41 ways to blow your leg off to 118 ways.
I'm betting it means you can easily google LOTS of memory bugs stemming from this complexity. It "just works" for everyone else, until it does not, and then nobody understands what's wrong because they created a complexity monster.
And what do you think how many intended "moves" get silently converted into copies because some failure to properly forward rvalue references and similar?
Show the evidence. It does not. It introduces vast amounts of complexity.
The evidence is that everyone could do what you showed and they don't, they do this instead. In my experience memory ownership bugs are almost non-existent, an entire class of problems is wiped out.
It's clear that since you're asking about this stuff you haven't actually gone down this road yourself, which means that you're railing against something you don't understand out of fear of something different.
#include <vector>
using namespace std;
vector<int> makeVec() {
vector<int> v{1,2,3};
return move(v);
}
int main() {
auto a = makeVec();
return 0;
}
Not difficult or complex. In this case you have something that isn't a constructor returning a data structure that contains heap allocation. You don't have to guess at ownership or dig through documentation (if it exists).
Keep an open mind, there's a reason people consider old C style archaic.
I was not asking, and certainly not for a toy example, are you STILL under the impression you need to explain beginner level C++ to me? You can btw remove the move() from the return statement in this example. It's normal to omit it as it is implicit and specifying it does not make a difference. Did I mention that move semantics introduce a ton of complexity and make it non obvious what is happening?
> Keep an open mind, there's a reason people consider old C style archaic.
It is superficially a little bit archaic but it's not as bad or cumbersome as people make it, like baking a good bread from old grains in a modern oven. The point is if you focus on superficialities and micro optimize everything, you will make a mess and get what you deserve (i.e. modern C++).
The result from baking with simple ingredients is better tasting and healthier than a modern factory bread.
What people consider archaic or in particular insufficient is a function of their knowledge and experience. Check out the raddebugger code and the many excellent explanatory videos about the design of the codebase. You will learn a lot and you might change your mind about many of your mainstream positions.
are you STILL under the impression you need to explain beginner level C++ to me?
Yes
you can btw remove the move() from the return statement in this example.
First you say you have a problem with not knowing if something will copy or move, now you have a problem with an explicit move to rely on copy elision.
Seems like you just want to complain about problems that don't exist.
This is why I think it's necessary to explain the basics.
function of their knowledge and experience
Now we are to the "get good" part of the C true believe argument. People have been trying to get good for 50 years and all the same bugs still happen.
You will learn a lot and you might change your mind about many of your mainstream positions.
I've already been on both sides of this argument. I like data structures, value semantics and avoiding double indirection.
Check out the raddebugger code
Check out the code to every other piece of software you use.
What disorder are you suffering from? Please check who was bringing up PIMPL. Hint: it was the person who does not know what they're talking about.
> Which one is the argument against destructors?
oh. my. god. THE COMPLEXITY. The systemic issues.
> Copying and moving are solutions to problems you already demonstrated
Which? I presented my solution to the move problem, it was: just don't move. And for copying: it's very context dependent what "copy" should even mean. There is no point in general in making a single function.
This whole semantics infrastructure is all just there to allow generic template code, which results mostly in: very bad, bloated, and slow code that is full of forgotten edge cases. For example, to take a very popular example, std::sort. you can sort a vector of vectors, it would then use move semantics to swap elements. Fine: I would just sort pointers instead or come up with an ad-hoc solution that is way faster anyway. (other than the fact that general purpose sorting of longer chunks is quite rare in systems programming).
> This is double indirection. It is more allocations, more memory frees, more pointer dereferencing (all of which are slow) and not necessary.
My friend, you don't understand the first thing about how computers perform their work, let alone how you have to balance these concerns with software architectural concerns.
You could convert all the std::vectors in your programs and access them using pointers, in most cases you probably wouldn't notice the tiniest bit of a performance difference.
But the reason why C++ likes to embed "objects" as values (even though that's almost invariably bad from an architectural standpoint) is almost entirely unrelated to performance (with the caveat that embedding might save you a couple heap allocs and frees, but for real stateful objects & data structures, that isn't a good reason to embed). Of course you shouldn't add any indirection for objects that aren't really objects but merely a scope-exit, like lock_guard for example.
The primary reason is because it painted itself into that corner. It's syntax & semantics. You wouldn't "profit" from RAII if you added pointer indirection to your objects. (To fix that, later std::unique_ptr<T> was popularized, which again is an embedded struct but contains only a pointer -- which in typical C++ manner introduced its own additional horrors).
Another reason why C++ wants to embed objects is that its operators (like operator[], operator+ etc.) are defined on "value" type syntax expressions. Well it's basically the same reason as above RAII argument, since that argument is about the destructor-"operator". You cannot call methods & operators on pointers. You cannot do `std::vector<Foo> *ptr = ...; do_foo(ptr[i]);`. Get it? The best you could do would be `do_foo(ptr->at(i))` but it's not the same. Part of the reason why C++ calls methods on value type expressions is of course C compatibility, C++ can't afford to mess with pointer syntax and arithmetic.
I'm hearing it, I'm not seeing it. Repeating the same thing isn't evidence.
My friend, you don't understand the first thing about how computers perform their work, let alone how you have to balance these concerns with software architectural concerns.
Seems like projection when you're fine with double memory allocations and double indirection. Again you can make these bold statements but saying pointer chasing has no performance impact is what people say when they don't understand the cost of TLB misses and caches misses.
C++ likes to embed "objects" as values
"C++" doesn't like to do anything. It has things in the language like destructors that basically no one has ever been against until now.
You wouldn't "profit" from RAII
I don't know what this means but people using features a certain way doesn't have anything to do with destructors. That's the definition of a straw man fallacy.
It's like your C program doing double indirection. You can't blame C for that (unless you want to try to say that not defining your structs is a good idea).
You cannot call methods & operators on pointers. You cannot do `std::vector<Foo> ptr = ...; do_foo(ptr[i]);`. Get it?*
Yes you can, an operator is just a function, get it?. You don't need to because you can use things as values and not fragile pointers that have to have their ownership semantics memorized for every individual data structure and function (interesting that you never addressed this). You don't get operators in C, so it's bold to be wrong and about a feature you are somehow denigrating.
Also one separate function being different than the operator is not a language level feature, it is how that one library data structure is made.
I'm sorry. C++ is broken.
Based on you misunderstanding it because youtubers steered you wrong?
All I was arguing was that destructors are good and you are having a massive reaction to that that seems to include every misguided frustration with the whole language you can think of.
> Again you can make these bold statements but saying pointer chasing has no performance impact is what people say when they don't understand the cost of TLB misses and caches misses.
You are right to call this out but I did not mean to imply that it would not increase load on the cache at all. The most important optimization is keeping data structures simple, flat, and coherent. Making many micro optimizations can backfire because it reduces clarity and flexibility. I should not argue that vector metadata block should not be embedded as value in a struct, but move semantics is where it is getting silly, complicated, and we are losing control of program behaviour.
For example, with your cache concerns, don't forget to group data by access patterns and write patterns. Not doing so may hurt the cache more than an indirection. If you blindly embed everything by value religiously, you deserve neither flexibility nor correctness nor performance.
> Yes you can, an operator is just a function, get it?
An operator is just a function but with different syntax. You can not do my example, that snippet does not do the intended job. Get it?
> (unless you want to try to say that not defining your structs is a good idea).
It is a good idea when it's about architecture. It is right to embed small and in particular stateless structs directly, but otherwise adding one level of indirection is often absolutely the right call.
> All I was arguing was that destructors are good
All I'm saying is that destructors, while they may seem convenient, are way overrated and the systemic issues caused by reliance on C++ classes and class features (including destructors) are still not well enough understood by the mainstream in 2026.
If you blindly embed everything by value religiously, you deserve neither flexibility nor correctness nor performance.
I don't know what 'deserve' is supposed to mean, but I just showed how to get all three.
don't forget to group data by access patterns and write patterns
Values on the stack are going to be grouped together and they are going to be in cache.
You realize using two heap allocations means twice the frees, twice the heap contention from multiple threads and chasing through two pointers for every data structure access right? In what universe does this work better than a single pointer lookup?
Making many micro optimizations can backfire
This is an even more handwavey than usual.
All I'm saying is that destructors, while they may seem convenient, are way overrated and the systemic issues caused by reliance on C++ classes and class features (including destructors) are still not well enough understood by the mainstream in 2026.
You can say that but you have given zero evidence of any of this. It took you a very long time to even get to your claim, maybe now you can start to back it up.
Meanwhile I gave extensive evidence based on your own examples of how the same bugs have happened over the last 50 years and double indirection and vague ownership cause problems on small and large levels.
You don't understand even the first things of what I say. That's because you apply beginner level concepts and understand to argue, and are not looking for nuance or deeper understanding at all.
> Also one separate function being different than the operator is not a language level feature, it is how that one library data structure is made.
That's not so much the point: the point is that even when calling a regular method conveniently as ptr->methodname(), you are calling the method name not on a pointer expression but on a value expression. ptr->methodname() is effectively (*ptr).methodname().
You don't get it. That's because you still don't understand some basic things about the language. There is no method call here on a pointer expression. There is only a call on a value expression.
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.