Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mariusbancila.ro

Post reply on HN
Print view View original

41–50 of 122 posts

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

#41

Post by jstimpfle »

einpoklum wrote: post #34
wwind123 wrote: post #25

Earlier quoted context omitted.

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…

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

Pretty much all the C++ features I've used are good enough to write some toy code snippet, but it's hard to use them to good effect at scale without causing massive problems.

Even classes are an instance of this, they were to solve some perceived problems, but they created much bigger issues, such as readability issues and introducing many more compile time dependencies.

PIMPL wasn't even a C++ feature but an idiom pushed by some people. It is next to unusable because you have to duplicate the API and write all the call forwards.

One problem with std::unique_ptr for example is that there is no ergonomic way to use it to hide implementations. The reason is it relies on destructors and to use destructors the class definition needs to be visible.

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

#42

Post by whizzter »

silon42 wrote: post #38
maccard wrote: post #35

Earlier quoted context omitted.

We put #define WIN32_LEAN_AND_MEAN 1 #include In precompiled headers to solve that particular problem.

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

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

#43

Post by whizzter »

Where are we with modules, isn't pimpl there largely to avoid costs related to including the world?

I was pondering on why he was putting the defaulted methods in the cpp, any particular reasons?

I did realize that the indirect version is required to be in the cpp since the header won't know how to copy without knowing the definition of the impl class.

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

#44

Post by smallstepforman »

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?

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

#45

Post by ghosty141 »

whizzter wrote: post #43

Where are we with modules, isn't pimpl there largely to avoid costs related to including the world? I was pondering on why he was putting the defaulted methods in the cpp, any particular reasons? I did realize that the indirect version is required to be in the cpp since the header won't know how to copy without knowing the definition of the impl class.

pimpl helps more since its trivially implementable in existing codebases while modules are a much bigger pain.

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

#47

Post by cemdervis »

whizzter wrote: post #43

Where are we with modules, isn't pimpl there largely to avoid costs related to including the world? I was pondering on why he was putting the defaulted methods in the cpp, any particular reasons? I did realize that the indirect version is required to be in the cpp since the header won't know how to copy without knowing the definition of the impl class.

pimpl also helps to keep data structure layout stable, e.g. Qt's d-pointer convention

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

#48

Post by knorker »

whizzter wrote: post #43

Where are we with modules, isn't pimpl there largely to avoid costs related to including the world? I was pondering on why he was putting the defaulted methods in the cpp, any particular reasons? I did realize that the indirect version is required to be in the cpp since the header won't know how to copy without knowing the definition of the impl class.

pimpl also makes it much easier to make changes without breaking ABI. E.g. shared libraries.

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

#50

Post by knorker »

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.

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, you should benchmark it for every use case, since negative cache effects may dwarf that gain.

Then again, extra padding can also help performance, for some workloads (especially multi threaded read/write against a vector of objects).

So without further context, there's no way to say if your way hurts or helps. It's certainly not a general solution.

Post reply on HN