CyberDildonics

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.

It is the point since you compared two things that have different uses, then said you can't call an operator on a pointer, which is wrong.

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.

Do you have a program that doesn't need to run fast?

What are you talking about

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;
  }

Keep an open mind, there's a reason people consider old C style archaic.

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.

> How many did you read?

Way too many.

And you said it causes brain damage?

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.

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.

  Bar *bar_create();
  void bar_destroy(Bar *bar);

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.

I've said many other things.

You have, not all of them on topic.

You're a loudmouth

This is text.

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.

Nope, if you think forming beliefs from youtubers is so negative, don't do it.

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.

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.

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++?

Show me. They are just functions, usually one or two lines.

Please show me how you can call a destructor in C++ without seeing the declaration of the destructor.

You have declarations of functions the same as in C, did you try this?

JUST DO IT. SHOW THE EVIDENCE. DONT TALK.

Show me what you're talking about in godbolt.

I think it's time for you to shut up

you fantasized it

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

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.

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.

It just seems to be wholesale aggravation so they want to reject things without a sound reason.

If someone asked me why I avoid inheritance I would go on a well thought through rant that connects real problems to the pragmatic reality of what that feature brings.

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?

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.

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?

C++’ish approach to memory management (RAII) - that’s not how systems programming or games (I’m told) tend to work

This is the statement that no one seems to be able to back up. Instead it's fans of some internet programmers saying that they must be right about everything because they shipped a game.

I actually like hearing what they have to say, but they aren't right about this and there is no evidence or explanation here from you, them or anyone else.

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.

In the last 20 years, everything’s just CGI. Movies like Mad Max: Fury Road and Fall Guy are few and far between.

There is no world where naming a random longer movie with more effects makes mad max an example of a movie that doesn't use cgi. Something completely unrelated doesn't make a false statement true. There was some marketing that got people to believe this and it's an outright lie.

This isn't true and doesn't make any sense. Smart pointers don't need to enter into it. If you need a lot of something you make a vector and allocate once.

Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back.

It is an extremely niche scenario to need a program to shut down so much faster that you can't even deallocate memory. If you don't make lots of small allocations in the first place the deallocations won't take any time.

Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.

It's actually a pretty big advantage to destructors to deal with stuff like this as well as memory and locks.

IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.

I think it gets polarizing because they are both undeniably sharp programmers but don't have any real evidence of this stuff, they are just grasping at rationalizations.

My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it.

They might say this, but there isn't a good technical rationalization here since anyone can create a global data structure just as easily in C++.

What does this mean? Who told you that?

https://www.fxguide.com/fxfeatured/a-graphic-tale-the-visual...