| oh. my. god. THE COMPLEXITY. The systemic issues. 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? |
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.