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

71–80 of 122 posts

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

#71

Post by bluGill »

jstimpfle wrote: post #64
bluGill wrote: post #63

Earlier quoted context omitted.

Easiest way to make a silly mistake and have your program break from memory safety errors.

Well, the best way to prevent mistakes is to make everything super complicated and damn hard to do. The best way to prevent mistakes is to approach it to do the essential stuff and avoid the fluffy stuff.

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 complex but some of us work on hard problems.

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

#72

Post by HarHarVeryFunny »

torginus wrote: post #53
3form wrote: post #6

This looks great indeed - I wonder if there are any particular gotchas, though, as things often are in C++next land. With many of the features coming into the language over time, I kinda wish that a bit more restricted subset of it eventually becomes a thing, but I know in practice it might as well be a completely different language. That, and I expect that still many other things have not been resolved as well as th…

The gotcha is that this is a 90s C pattern, and software that actually needed this has been written for 3 decades by now

Sure, but this interface/implementation split is such a common pattern that it would be nice if the language handled it implicitly (NOT this std::indirect solution) rather than forcing the developer to use some explicit pimpl/handle pointer.

You'd essentially like to derive a class/module implementation from it's corresponding class/module interface (which is all the user sees), but have the language automatically add a hidden "pimpl" pointer to the interface class. The implementation would then essentially use "this" to access public members, and "pimpl" for private members.

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

#73

Post by HarHarVeryFunny »

Maxatar wrote: post #60
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?

So data structures like std::vector should never be copied - period?

I think the parent is just referring to pointer types, not anything (like std::vector) that may use pointers internally.

This "std::indirect" tries to have value semantics, but in fact it's just another type of smart pointer and uses pointer syntax (pimpl->foo : forced since C++ allows "->" as a user defined operator name, but not ".").

But it's a weird sort of "pointer" given this copying behavior, which is maybe why they didn't give it a "_ptr" name.

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

#74

Post by jstimpfle »

bluGill wrote: post #71
jstimpfle wrote: post #64

Earlier quoted context omitted.

Well, the best way to prevent mistakes is to make everything super complicated and damn hard to do. The best way to prevent mistakes is to approach it to do the essential stuff and avoid the fluffy stuff.

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 among the most error-prone problems in your code, then maybe you're problems aren't that hard or complex after all.

I'm currently working on a distributed caching system and on real time voxel geometry boolean operations simulation (on GPU), both on the scale of >= 10^9. Is that "complex" enough? Both are done in C++. C++ helps exactly 0 in achieving any of these things (as opposed to using plain C), well the one help is I don't have to type 'struct' all the time.

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 and performance problems from using them. The code was not obvious and using STL containers (std::deque is very bad specifically) meant the actual runtime characteristics depend on which STL implementation is being compiled in. It would have been easier to just do straightforward obvious manual code.

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

#75

Post by coffeeaddict1 »

skrebbel wrote: post #7
coffeeaddict1 wrote: post #3

This is actually useful, but despite it is another extra thing you will have to remember when reading C++ code. I guess with LLMs things aren't so bad.

Why? It’s still the good (bad) old pimpl pattern. It just got a bit shorter. When reading you dont even need to grok “std::indirect”, you see the word pimpl and you know what’s going on.

Because I will still encounter people who use the old of writing pimpl. So I now I'm forced to remember the old way + new way. People aren't magically switching to use std::indirect. I bet that even in 10 years, half of projects will still be using the old way.

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

#76

Post by coffeeaddict1 »

einpoklum wrote: post #33
coffeeaddict1 wrote: post #3

This is actually useful, but despite it is another extra thing you will have to remember when reading C++ code. I guess with LLMs things aren't so bad.

You need to remember _less_, rather than more, when you use this kind of vocabulary types. Think about std::optional. Before that (and if you didn't write something like it yourself), you had to, for each class, remember the bespoke semantics of when and how it represents the lack of some members, and you would have to have non-defaulted ctors, move assignments and dtors, and then whenever you used that class you wou…

No. This is not what I meant. I absolutely agree that std::indirect is an improvement. My point is that when dealing with C++ code, now there is yet another way of doing the same thing. I will have to remember both ways, because people will still keep using the old way.

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

#77

Post by einpoklum »

coffeeaddict1 wrote: post #76
einpoklum wrote: post #33

Earlier quoted context omitted.

You need to remember _less_, rather than more, when you use this kind of vocabulary types. Think about std::optional. Before that (and if you didn't write something like it yourself), you had to, for each class, remember the bespoke semantics of when and how it represents the lack of some members, and you would have to have non-defaulted ctors, move assignments and dtors, and then whenever you used that class you wou…

No. This is not what I meant. I absolutely agree that std::indirect is an improvement. My point is that when dealing with C++ code, now there is yet another way of doing the same thing. I will have to remember both ways, because people will still keep using the old way.

Ok, well, you have a point, in that you might see the old way of doing things and you might see the new way. This is, however, one of the detriments of the language's commitment to backwards-compatibility: Old-C++ code is (almost without fail) valid new-C++ code.

When you write new code, this is (mostly) not an issue; when you have to maintain old code, it is. Especially if the existing codebase is somewhat of a patchwork of code introduced at different points in time - pre-C++98, C++98, C++03, C++11 and so on. For this reason it is a saintly virtue to manage to unify the C++ "vernacular" used in a project, for better readability by newcomers and for facilitating uniform changes to the entire codebase later on.

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

#78

Post by binary132 »

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.

The article explains why, indirect and unique_ptr are templated and require the complete definition of the type, and the default impls of those methods use methods of the templated types.

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

#80

Post by feelamee »

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.

I think point was another. And even if u are right - this is a silly point. In any general language you have enormous amount of ways to write something. I'm at least implemented pimpl in two different ways (despite lot of little quircks): classic pimpl with heap allocated implementation and fastpimpl which accepts size as compile time argument and create implementation directly in local stack buffer.

> In large codebases you will now have to deal with all three solutions being used, depending on how old the code is.

this is really a problem of "large codebases" and not C++ complexity. If people writing badly organized code.. than.. nothing will help them. Even such string language as Rust.

---

But, I go aside. I can be wrong here, but this is how I see this: - author author worked with C++ early in his career - now his work with something like python or javascript or "promptscript" or don't programming at all - he managed to taste C++ drawbacks - now he reading such article just to see "what's new" in technology he was interested in the past. - he see something what he don't understand from first sight - this looks like a complex and quirky thing => he decide that problem in the language, not in his incompetence in this area

I see such comments very often and usually people don't provide any technical expertise. But just their feeling that "oh, this thing was so complex, now it even more complex".

Post reply on HN