Comment by CyberDildonics | Hacker News Reader

Comment by CyberDildonics | Hacker News Reader

Parent Full thread

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?

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

That's not so much the point:

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.

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.

Reply on news.ycombinator.com