how it wastes the memory? It's just a bytes array of the same size as struct.
I would be more imposed on how idiomatic pimpl with heap allocation influences memory usage and cache hits
I think nothing prevents this, but this is just not the point of unique_ptr. unique_ptr is still ptr, so it consequently follows raw pointer semantics.
> std::indirect looks for me like another pointless c++ thing that already works with forward pointer declaration. You can add it to another ton of pointless things C++ adds without fixing the old ones.
For me your comment seems pointless, because std::indirect have a precise and clear problem which it solves. And this is totaly not a "hackery fix of language drawback". In this case language works as intended and std::indirect just close the gap for facility which is still would be written by hands, if there is no std::indirect.
I'm interesting which C++ features also helps you to design such systems.
I think basic RAII/function overloading/templates should give a lot of capabilities comparing with plain C?
I think point was another.
And even if u are right - this is a silly point. In any general language you have enormous amount of ways to write something. I'm at least implemented pimpl in two different ways (despite lot of little quircks): classic pimpl with heap allocated implementation and fastpimpl which accepts size as compile time argument and create implementation directly in local stack buffer.
> In large codebases you will now have to deal with all three solutions being used, depending on how old the code is.
this is really a problem of "large codebases" and not C++ complexity. If people writing badly organized code.. than.. nothing will help them. Even such string language as Rust.
---
But, I go aside.
I can be wrong here, but this is how I see this:
- author author worked with C++ early in his career
- now his work with something like python or javascript or "promptscript" or don't programming at all
- he managed to taste C++ drawbacks
- now he reading such article just to see "what's new" in technology he was interested in the past.
- he see something what he don't understand from first sight
- this looks like a complex and quirky thing
=> he decide that problem in the language, not in his incompetence in this area
I see such comments very often and usually people don't provide any technical expertise. But just their feeling that "oh, this thing was so complex, now it even more complex".
oh yeah, how my opinion changing:
- in schools I used HTML+CSS to make my own site during homework
- after that I understand that no one truly create sites this way. You need JS, framework, database, etc, etc
- now I returned back - I really need only my text editor and HTML+CSS
> As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both.
haha, just for fun... do you want a C++ in your perfect world :D?
lol, this problem stopped me from installing GrapheneOS early.
But now.. I removed banking apps by myself because my state require room them to collect phone fingerprint and access to location EACH time they opened.
So... looks like now nothing stops me
sure, without any action from the user to increase safety, desktop OS's just allow any app to read any files.
On the other hand, desktop OS's allow a wide spread list of ways to control what applications have access too (especially Linux and BSD families).
Although, despite all this, running malware can never be safe.