Understanding the Odin programming language

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 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 *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 sorry. C++ is broken.

> How many did you read?

Way too many.

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

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

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

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.