Pretty much all the C++ features I've used are good enough to write some toy code snippet, but it's hard to use them to good effect at scale without causing massive problems.
Even classes are an instance of this, they were to solve some perceived problems, but they created much bigger issues, such as readability issues and introducing many more compile time dependencies.
PIMPL wasn't even a C++ feature but an idiom pushed by some people. It is next to unusable because you have to duplicate the API and write all the call forwards.
One problem with std::unique_ptr for example is that there is no ergonomic way to use it to hide implementations. The reason is it relies on destructors and to use destructors the class definition needs to be visible.
Well that's a lie. I've long been back to raw pointers and it's by far the easiest way to do it. All of Pimpl, unique_ptr, and whatever other clever mechanism (I'm not even looking at std::indirect anymore) just aren't really ergonomic.
Nobody needs "deep copying", ever. It's not even well defined what it should mean (i.e. how deep etc.). It's purely a theoretical problem with no good practical (one-fits-all) solution. The only practical way is to copy what you need copied, when you need it. Done.
> It's your claim that destructors are harmful so the burden of proof is on you.
I have given a variety of arguments why I think the C++ RAII specifically has downsides. You can accept them or ignore them, but don't act like I didn't give arguments.
> People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate,
Once again you're explaining beginner C++ do me. Are you still doubting if I understand this argument? My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs. This is scripting and plumbing. It's not interesting to me. Systems programming is not so much about stack scoped lifetimes.
RAII systematicing object lifetimes and cleanup, thus enabling exceptions and implicit or uncontrolled control flow, may sound nice on paper, but turns out we shouldn't want them in the first place. What RAII leaves for me is a system that will automatically call nested object's destructors when I delete something. It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.
> This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
If I were you, my response would be: The burden of proof is on you, show the evidence. But my answer is, yes that is right, but everything is a tradeoff, and the issues caused by manual cleanup are also somewhat exaggerated by C++ people, and the issues caused by blindly buying into the corset of C++ types are not well understood by C++ zealots (I've done my best at explaining them).
Issues caused by C approach are also a matter of design and approach to programming in general. It also depends on the actual problem you're solving. The linux kernel for example doesn't exactly have the easiest or most beautiful code to follow, but surely it's one of the most technical codebases out there, one that solves difficult problems (performant resource multiplexing for programs that it doesn't even know). On the other hand, the debugger code base I've referenced doesn't have any gotos for example, nor even early returns (or almost none, not sure).
Find me a single example of programs that run as fast and are as productively maintained as these two codebases in their respective areas? I believe there aren't any.
This should be plenty evidence to a reasonable mind, but that isn't you.
You keep "asking" for evidence but the only evidence presented by yourself is that you have merely surface-level understanding of the subject matter, and are looking for arguments, not insight and critical examination.
I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).
Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.
The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).
I've argued elsewhere some things that are wrong with RAII and C++ objects in general.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
Designing something good for me means going through at least 11 seriously bad approaches before half understanding the problem and having a half-working solution. Trying to use a notebook to aid a learning or research process at all has always meant wasting a lot of time "perfecting" those bad approaches. And ending up with lots of notes that document nothing but a painful struggle to make sense. Looking back through the notes that I did take, in notebooks that I have been gifted over the years, is almost unbearable. The approaches I tried before arriving at the right one were fundamentally wrong, there is no fixing them, and it's painfully obvious when looking back. Aside from the emotional problems I perceive there, it's obvious to me that there is no engineering value in keeping those notes at all.
The current best design always lives in my head, and by the time it exists, the solution and understanding is so clear and detailed that I can't be arsed to write it down.
I do think there is value in taking notes for others, though.
What works a little bit for me is having a lose stack of papers at work. The topmost paper serves to put a coffee mug on top, that will take the coffee stains so the table stays clean. From time to time I actually scribble something on a sheet, and since the sheets are all loose it's very easy to discard any sheet after it's served its (diminishingly small) purpose as a thinking aid.
> 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().
> 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.
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.
> 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?
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.
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'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.
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.