Live data from Hacker News

The PImpl idiom and the C++26 std:indirect type

mariusbancila.ro

21–30 of 122 posts

Re: The PImpl idiom and the C++26 std:indirect type

#21
post #5

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.

Indeed. I primarily used PIMPL when I want to avoid polluting public header files with implementation detail #includes in cases where forward declarations are impossible or unwieldy and inline methods are irrelevant.

Re: The PImpl idiom and the C++26 std:indirect type

#22
> Never null: it always holds a value, except in the moved-from state

I am wondering why C++ can't implement "non-null" unique_ptr version in the same way? As I know, that the main argument against implementing it is, that it's can't be done, since move-out unique_ptr still can be null.

Re: The PImpl idiom and the C++26 std:indirect type

#23
I have a little class called EImpl that is kind of like std::indirect except that it embeds the impl instead of pointing to it. It takes three template parameters: an embedded struct, a size and an alignment. It static_asserts that the embedded struct fits in the size and alignment, and it embeds it with approximately zero overhead. It’s about as easy to use as any other pImpl technique.

Re: The PImpl idiom and the C++26 std:indirect type

#24
post #5

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.

My approach to reducing the compile time of code which uses a class is moving the functionality out of the class and into standalone functions; or at least moving the method definitions into a non-header `.cpp` file.

Re: The PImpl idiom and the C++26 std:indirect type

#25
post #4

Earlier 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

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…

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.

Re: The PImpl idiom and the C++26 std:indirect type

#26
post #5

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.

Lucky for you, I don't.

Re: The PImpl idiom and the C++26 std:indirect type

#27

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

Besides being a common idiom, for how many warts C++ might have, no one is rewriting LLVM, GCC, V8, JVM/ART and .NET runtimes, CUDA/Metal/DirectX, Unreal, Godot,.... into something else, RIR is not happening there.

People will contend themselves with "C++ the good parts", helped by clang-tidy, PVS, MSVC analyse, and move on.

Re: The PImpl idiom and the C++26 std:indirect type

#28
post #4

Earlier 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

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.

Re: The PImpl idiom and the C++26 std:indirect type

#29
post #5

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.

Back when I used to write C++ it was used all over the place. Admittedly that was a log time ago.

How you doin' fellow Qt-kids? ;)
Post reply on HN