| > You bringing up something unrelated doesn't mean anything just because you keep bringing it up. It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language. > 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. You made me do it by repeatedly talking down on me in a condescending tone, when I tried to keep it simple and referred to external sources. What the heck. You want a simple reply. I cannot give you one, except for, "RAII is this simplistic solution that makes the language complicated while still being by far not enough to handle interesting use cases. It has turned out to be wrong and misguided every time I've tried to use it, and here are a million examples why". > If it automates things why would it have a typing cost? That makes zero sense. It automates generating boring boilerplate code (which is good on one hand but it doesn't reduce the semantic complexity AT ALL, so actually it just promotes doing the wrong thing by making the wrong thing easier). To generate the boilerplate code it requires type machinery. What doesn't make sense about this? Why don't YOU start telling ME? >> it will "infect" your codebase, > How? It can be used or not. To use it e.g. in containers, you then have to also use it for the things contained -- e.g. unique_ptr<T> or vector<T> or whatever, you will have a bad time if you don't model T's destruction with a C++ destructor too. Also you can't just insert random manually managed objects within a group of RAII managed objects, because that will break the "reverse destructor calls" assumption. It's a viral thing. >> It will break modularization of your codebase, leading to subtle but substantive degradation. >These are strange claims, they don't have any evidence I explained why: internals have to get moved to public API in practice. This is almost the definition of breaking modularization. >> 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. Why are you being so stubborn? Destructors (like other methods) practically require classes to be fully exposed (that you can protect them with silly public/private/protected specifiers doesn't change the fact they're exposed), requiring includers to pick up transitive dependencies. That results in huge amount of included code per TU, and results in far too many TUs that have to be rebuilt on incremental changes. This is a very well known thing. > "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? Why doesn't it make sense? In practice, allocation is coupled with initialization and destruction is coupled with deallocation. It's literally in the name, Resource Allocation Is Initialization. You can work around it, sure, but it's painful and literally just an escape hook to escape the very thing you're arguing for. > 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. ON GODBOLT? Are you kidding me? I've been arguing all day how RAII is a simplistic rigid mechanism builtin to a language that will lead to slow creeping systemic issues, in practice, in my experience, in larger and more complicated systems, especially with performance and abstraction requirements. I CAN NOT explain to you what sucks about it in a godbolt. You can use RAII fine for simpler programs. You can use it fine in a godbolt. You can use it fine for leetcode. etc. Asking for a Godbolt example of architectural coupling is like asking for an assembly listing proving that a database schema is hard to migrate. |
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.