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

101–110 of 122 posts

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

#101

Post by StilesCrisis »

knorker wrote: post #61
StilesCrisis wrote: post #52

Earlier quoted context omitted.

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

Not everyone works at Google and builds all binaries from scratch from a monorepo every time. And even then, maybe even Google doesn't rebuild libstdc++ as part of this. GNURadio consistently uses pimpl for blocks, as I understand it mainly for ABI. > willing to stop improving. I think that dismissing it like that shows a naive understanding of execution environments, binary interface design, and in general systems s…

If you want a fixed build environment, pick a toolchain and stick with it.

If you want the latest and greatest, a willingness to rebuild your code seems like a reasonable prerequisite to me.

If you need a binary blob that can withstand toolchain versioning, use a dynamically linked library.

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

#102

Post by maccard »

pjmlp wrote: post #96
maccard wrote: post #95

Earlier quoted context omitted.

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

I've just spent an hour trying to set up import std to use std::print on MacOS. I got there, eventually with cmake + ninja. I hit an absolutely ludicrious number of errors for effectively a hello world, and I don't understand why in 2026 it is as complicated as it is.

But, no ICEs and it's working! I'll start writing some code with them tomorrow.

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

#103

Post by knorker »

StilesCrisis wrote: post #101
knorker wrote: post #61

Earlier quoted context omitted.

Not everyone works at Google and builds all binaries from scratch from a monorepo every time. And even then, maybe even Google doesn't rebuild libstdc++ as part of this. GNURadio consistently uses pimpl for blocks, as I understand it mainly for ABI. > willing to stop improving. I think that dismissing it like that shows a naive understanding of execution environments, binary interface design, and in general systems s…

If you want a fixed build environment, pick a toolchain and stick with it. If you want the latest and greatest, a willingness to rebuild your code seems like a reasonable prerequisite to me. If you need a binary blob that can withstand toolchain versioning, use a dynamically linked library.

Not sure what toolchain has to do with your code retaining ABI compat like size. Nor how dynamic linked library helps. Dynamic linked libraries are exactly the ones that have the most use for pimpl to maintain ABI compat.

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

#104

Post by knorker »

feelamee wrote: post #99
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,…

> 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

I read the parent commenter as proposing headroom.

Because if it's an exact match, then it doesn't help at all with ABI compat, and arguably doesn't add anything. Well, aside from compile time, but that's maybe better solved with modules?

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

#105

Post by feelamee »

knorker wrote: post #104
feelamee wrote: post #99

Earlier quoted context omitted.

> 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

I read the parent commenter as proposing headroom. Because if it's an exact match, then it doesn't help at all with ABI compat, and arguably doesn't add anything. Well, aside from compile time, but that's maybe better solved with modules?

pimpl can solve several problems and allowing to extend struct without breaking ABI is the one is them. But even such implementation of pimpl breaks compile time and ABI dependency. You can't change size without breaking ABI, but still can change members, etc (e.g. replace current fields with heap allocated to extend without breaking ABI :))

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

#106

Post by knorker »

feelamee wrote: post #105
knorker wrote: post #104

Earlier quoted context omitted.

I read the parent commenter as proposing headroom. Because if it's an exact match, then it doesn't help at all with ABI compat, and arguably doesn't add anything. Well, aside from compile time, but that's maybe better solved with modules?

pimpl can solve several problems and allowing to extend struct without breaking ABI is the one is them. But even such implementation of pimpl breaks compile time and ABI dependency. You can't change size without breaking ABI, but still can change members, etc (e.g. replace current fields with heap allocated to extend without breaking ABI :))

Sure, but you could have done that without pimpl, too. At least without defaulted or inlined constructors/destructors/etc.

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

#107

Post by CyberDildonics »

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…

In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs

Which part of the STL are you expecting to be thread safe?

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

#108

Post by jstimpfle »

CyberDildonics wrote: post #107
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…

In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs Which part of the STL are you expecting to be thread safe?

Where did I imply that I am expecting any part of the STL to be thread safe?

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

#109

Post by CyberDildonics »

jstimpfle wrote: post #108
CyberDildonics wrote: post #107

Earlier quoted context omitted.

In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs Which part of the STL are you expecting to be thread safe?

Where did I imply that I am expecting any part of the STL to be thread safe?

If you aren't, wouldn't that imply that the concurrency problems are with you and not with the standard library?

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

#110

Post by jstimpfle »

CyberDildonics wrote: post #109
jstimpfle wrote: post #108

Earlier quoted context omitted.

Where did I imply that I am expecting any part of the STL to be thread safe?

If you aren't, wouldn't that imply that the concurrency problems are with you and not with the standard library?

Why don't you read again what I said instead of continuing to make implications?
Post reply on HN