The PImpl idiom and the C++26 std:indirect type • Hacker News Board

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

#81

Post by feelamee » Fri, Jul 24, 2026, 11:56 PM UTC

jstimpfle wrote: post #74

bluGill wrote: post #71

Earlier quoted context omitted.

Huh? The best way to prevent mistakes is to make doing it right easy. Manually doing everything just means a lot of room to mess up. Using the newer constructs my means you can't make a mistake as the hard work is done correctly for you. Zero cost abstraction means that it has no downside to manually doing it. C++ is trivial compared to the code I work on. If you are writing hello world complexity then C++ might be c…

I understand C++ as well, or better, than most (or all) of my peers, and certainly betters than people on here thinking they need to explain to me how RAII works. Do you want to argue that C++ RAII / objects stuff isn't complex and doesn't put considerably restrictions on how you design your app, then maybe you should reconsider. I would argue that if cleaning up resources properly is among the hard problems, or amon…

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?

> (as opposed to using plain C)

Also, curious - how plain C helps with this?

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

#82

Post by feelamee » Sat, Jul 25, 2026, 12:06 AM UTC

konstmonst wrote: post #12

feelamee wrote: 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…

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

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

#83

Post by [deleted] » Sat, Jul 25, 2026, 2:07 AM UTC

amluto wrote: post #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.

[deleted]

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

#84

Post by dataflow » Sat, Jul 25, 2026, 2:08 AM UTC

amluto wrote: post #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

#85

Post by gblargg » Sat, Jul 25, 2026, 5:14 AM UTC

jstimpfle wrote: post #40

gblargg wrote: post #18

Earlier quoted context omitted.

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) solutio…

The whole point of pimpl is to store additional per-object state in a separate object (to reduce header dependencies). So it should act just like normal member variables for standard constructors and assignment.

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

#86

Post by jstimpfle » Sat, Jul 25, 2026, 7:01 AM UTC

feelamee wrote: post #81

jstimpfle wrote: post #74

Earlier quoted context omitted.

I understand C++ as well, or better, than most (or all) of my peers, and certainly betters than people on here thinking they need to explain to me how RAII works. Do you want to argue that C++ RAII / objects stuff isn't complex and doesn't put considerably restrictions on how you design your app, then maybe you should reconsider. I would argue that if cleaning up resources properly is among the hard problems, or amon…

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? > (as opposed to using plain C) Also, curious - how plain C helps with this?

I've found that RAII and the stuff you have to buy into in order to use RAII come with more downsides than upsides once you scale beyond high level programs that try to get done a lot with very few lines.

> how plain C helps with this?

By staying out of the way and providing everything of what you actually need in the end. That is assuming a detail oriented approach where you deeply think about, and want to be flexible about, the organization of what your program should do. As programs grow into large architectures, and as programs get more performance conscious, they also get more detail oriented like that, and they tend to opt out of unflexible high level language features.

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

#87

Post by pjmlp » Sat, Jul 25, 2026, 7:59 AM UTC

StilesCrisis wrote: post #52

knorker wrote: post #50

Earlier quoted context omitted.

But if the pimpl size grows too big, you're forced to break ABI? And before it grows too big, it wastes memory. For your use cases it may not matter, and the saved pointer indirection may be more important, but maybe the person who has a million item vector of objects doesn't appreciate a 300% "just in case" memory overhead. The overhead may also hurt cache hits. If you're doing this to save the pointer indirection,…

"Breaking ABI" isn't an issue unless you can't compile your code anymore. It's pathetic that C++ has been so hamstrung over ABI that we're willing to stop improving.

Because outside Linux and BSD distros, the large majority of C and C++ developers care about binary libraries, and companies do make a business out of it.

So regardless of what WG14 and WG21 do, compiler vendors will ignore them, if it means angry customers.

In design by committee languages, new standards are only relevant to the extent implementers actually care about them.

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

#88

Post by pjmlp » Sat, Jul 25, 2026, 8:01 AM UTC

whizzter wrote: post #42

silon42 wrote: post #38

Earlier quoted context omitted.

That's kind of a hack, still best only used in implementation files, not headers.

The irony is that including/using many standard c++ headers is far far more expensive than including a lean windows.h these days. To make hobby-coding fun, i use a mstdp.hpp that implements "naive" versions of unique,shared,function,etc that compiles faster than including just one of the std versions (and yes, MSVC versions of those libraries seem to be excessivly complex).

Not when using modules, which I have moved into on hobby projects.

The import std is much faster than plain #include.

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

#89

Post by pjmlp » Sat, Jul 25, 2026, 8:03 AM UTC

smallstepforman wrote: post #44

Oh god, what monstrocity have we created?!? All this complexity follows unique_ptr and copy constructor madness. Anything with pointers with ownership should never be copied - period. Reference pointers - OK if scope/lifetime is known. Can we have c++11 lite?

Yes, configure clang-tidy as such.

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

#90

Post by pjmlp » Sat, Jul 25, 2026, 8:05 AM UTC

wwind123 wrote: post #25

konstmonst wrote: post #12

Earlier quoted context omitted.

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 year…

Same to other languages, e.g. someone stuck in Java 8, will be lost in modern Java 26 code.