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

91–100 of 122 posts

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

#91

Post by daemin »

zabzonk wrote: 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.

It was used extensively at a former workplace of mine where each class that wasn't a message or data type was a pimpl. They had implemented their own private pointer class to handle it. It worked well enough to avoid pulling in lots of headers, but was still a PITA when you wanted to change methods as you'd always need to change the method signature in at least 3 places - header file declaration, source file definition, source file impl definition.

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

#93

Post by daemin »

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.

Do you have the code shared somewhere, via a blog post or code snippet somewhere?

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

#94

Post by daemin »

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

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

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

#95

Post by maccard »

pjmlp wrote: post #88
whizzter wrote: post #42

Earlier quoted context omitted.

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 .

This is a fair point. Last time I tried modules in anger, it wasn't viable. Cmake didn't support them (well, they were experimental), intellisense didn't work and there were many ICE's in MSVC.

Maybe it's time to move my hobby project over and see how well it works.

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

#96

Post by pjmlp »

maccard wrote: post #95
pjmlp wrote: post #88

Earlier quoted context omitted.

Not when using modules, which I have moved into on hobby projects. The import std is much faster than plain #include .

This is a fair point. Last time I tried modules in anger, it wasn't viable. Cmake didn't support them (well, they were experimental), intellisense didn't work and there were many ICE's in MSVC. Maybe it's time to move my hobby project over and see how well it works.

I give you that Intelisense is broken as always, and the best experience appears to be with Clion, but I can live with it.

Best experience is VC++ with MSBuild, cmake/ninja work great with latest clang however import std support is not yet enabled by default in CMake.

I only care about VC++ for hobby coding, hence using modules.

See for example, https://github.com/pjmlp/RaytracingWeekend-CPP

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

#97

Post by feelamee »

jstimpfle wrote: post #86
feelamee wrote: post #81

Earlier quoted context omitted.

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

thx, I don't understand fully, but see something truthy in this. It would be interesting to read more detailed blog post about this.

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

#98

Post by feelamee »

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

I think nothing prevents this, but this is just not the point of unique_ptr. unique_ptr is still ptr, so it consequently follows raw pointer semantics.

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

#99

Post by feelamee »

knorker wrote: post #50
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,…

> And before it grows too big, it wastes memory

how it wastes the memory? It's just a bytes array of the same size as struct. I would be more imposed on how idiomatic pimpl with heap allocation influences memory usage and cache hits

Post reply on HN