Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
Yes, if you actually care compile times.
The PImpl idiom and the C++26 std:indirect type
11–20 of 122 posts
Re: The PImpl idiom and the C++26 std:indirect type
#12C++ is getting more and more complex. It used to be said that people use only a small percentage of it when writing C++, but I am beginning to think that the cake is a lie here.
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
Re: The PImpl idiom and the C++26 std:indirect type
#13Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
This std::indirect thingie looks more like a general helper for any data 'dangling off' an object, not limited to pimpl.
Not sure how much pimpl is used in reality, but it's a pretty ok solution to speed up build times (apart from unity builds), because it avoids having to include headers that are only needed for the private state into the public interface header.
Re: The PImpl idiom and the C++26 std:indirect type
#14C++ is getting more and more complex. It used to be said that people use only a small percentage of it when writing C++, but I am beginning to think that the cake is a lie here.
where "more and more complex" do u see in this article? This is a basic C++ idiom, which constantly used by developers
Yes. If anything, this is taking a complex yet common idiom and making it simpler.
Re: The PImpl idiom and the C++26 std:indirect type
#15Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
It's often used in libraries where you need to guarantee ABI compatibility. Fixing a bug or implementing a feature may require adding a new member into the class, which would change its size (thus break ABI compatibility). PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI.
I also like to use it sometimes to "hide" private methods and their documentation into PIMPL, so the public header is kept clean.
Re: The PImpl idiom and the C++26 std:indirect type
#16C++ is getting more and more complex. It used to be said that people use only a small percentage of it when writing C++, but I am beginning to think that the cake is a lie here.
where "more and more complex" do u see in this article? This is a basic C++ idiom, which constantly used by developers
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.
Re: The PImpl idiom and the C++26 std:indirect type
#17Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
It's often used in libraries where you need to guarantee ABI compatibility. Fixing a bug or implementing a feature may require adding a new member into the class, which would change its size (thus break ABI compatibility). PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI. I also like to use it sometimes to "hide" private methods and their documentation into PIMPL, so the pu…
> PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI.
Yep, that's what I've used it for. Didn't find it too difficult to implement it myself, but I guess every bit of convenience/bug avoidance helps.
Re: The PImpl idiom and the C++26 std:indirect type
#18Earlier quoted context omitted.
where "more and more complex" do u see in this article? This is a basic C++ idiom, which constantly used by developers
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.
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.
Re: The PImpl idiom and the C++26 std:indirect type
#19This looks great indeed - I wonder if there are any particular gotchas, though, as things often are in C++next land. With many of the features coming into the language over time, I kinda wish that a bit more restricted subset of it eventually becomes a thing, but I know in practice it might as well be a completely different language. That, and I expect that still many other things have not been resolved as well as th…
"Holds a value, except sometimes"
Re: The PImpl idiom and the C++26 std:indirect type
#20This is actually useful, but despite it is another extra thing you will have to remember when reading C++ code. I guess with LLMs things aren't so bad.
I don't really get why people keep repeating the "C++ is too big" complaint together with the implication that you need to remember the entirety of the standard library. In comparison Java has networking, GUI framework and even MIDI in its standard libraries. Is it because C++ is more closely related to C which library is so small that it barely contains anything useful? I much prefer code that uses a library feature rather than yet another poorly implemented and not documented hand rolled version of it.