Comment by feelamee
4 days ago
where "more and more complex" do u see in this article? This is a basic C++ idiom, which constantly used by developers
4 days ago
where "more and more complex" do u see in this article? This is a basic C++ idiom, which constantly used by developers
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. The issue with c++ is that it is so big, that everyone uses some kind of dialect of it and the fancier it gets, the less readable it becomes and the more magic happens behind the curtains. A developer of a C++ codebase now has to learn a specific meta language of this codebase. Fuck that, I have enough languages and their idiosynchronies to remember for my work now. After using Go for a pair of years returning to C++ is like coming back to a big archaic mess. I'll just go learn Rust instead and forget all those new useless C++ templates like std::indirect
I think it's kind of awkward either way. The standard committee keeps adding new features to the language to address common pain points in the industry. But many people don't have that much time to learn the new features, and hates it when seeing something in the code but can't intuitively understand what it's doing. I once witnessed a 10+ year C++ coder (that had been immersed in some old C++ code base for many years) seeing a piece of C++14 code for the first time -- he said it reads like an entirely different language, not the C++ he's familiar with at all.
> But many people don't have that much time to learn the new features
Because they spend so much of their time struggling with the pain points of the older code.
> but can't intuitively understand what it's doing
For (most?) new vocabulary types, it is rather intuitive to understand what they do. optional, variant, indirect - you may not remember the details by heart immediately, but you get the general idea and expect that they would behave in some reasonable way. And mostly, they do. That's not to say they're perfect: I feel like vomiting looking at std::variant's and how you have to work with them, as opposed to a proper case classes / algebraic union types in the language itself. And yet - when someone puts one in their class, instead of a bunch of code in a bunch of methods, you know what's going on. It does "read like a different language" somewhat, and that's good. The nicer language has been struggling to get out, as the saying goes.
1 reply →
Same to other languages, e.g. someone stuck in Java 8, will be lost in modern Java 26 code.
> 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.
Part of the problem is that features are not added fully
This here should not need to happen:
> document that moved-from objects cannot be used
It's moved from, so of course it cannot be used. Shouldn't have to add an assertion in every method to guard a fundamental invariant.
I think the parent's point is that we started with raw pointers to implement PIMPL, then we had std::unique_ptr, and now we have std::indirect. So there are now three different ways how PIMPL can be implemented, each has its gotcha's and subtle differences that one needs to keep in mind. In large codebases you will now have to deal with all three solutions being used, depending on how old the code is.
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".
The article's point of view is that using unique_ptr to implement a PIMPL idiom is inadequate since it doesn't allow copying of the outer type without implementing your own dedicated operators. Hence the new type which does act more like a value, leaving the decision to have the outer class move-only or copyable up to that class, without needing to write any special code.
The point of each improvement is fewer easily-made errors. Having implicit deep copying handled avoids lots of errors with manually implementing it the oldest way.
Well that's a lie. I've long been back to raw pointers and it's by far the easiest way to do it. All of Pimpl, unique_ptr, and whatever other clever mechanism (I'm not even looking at std::indirect anymore) just aren't really ergonomic.
Nobody needs "deep copying", ever. It's not even well defined what it should mean (i.e. how deep etc.). It's purely a theoretical problem with no good practical (one-fits-all) solution. The only practical way is to copy what you need copied, when you need it. Done.
8 replies →
Yes. If anything, this is taking a complex yet common idiom and making it simpler.
Is it actually simpler, though? The unfortunate reality of this world is the fact that C++ is not the latest standard of the language or the newest shiny library, it's all of them at the same time. Adding a new way of doing the same thing decreases complexity only if you migrate all of the existing code, which nobody ever does.
In cases where I assume that enough test coverage exists, I simplify code that I am currently working on or which I need to read very often.
This way I have already replaced a lot of for-loops by range-based for-loops. It helps me to understand code faster.
But code parts that noone needs to touch or see do not need to be more readable.