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.
Yup, agree that in some cases this fixes it. Indeed, in another comment[1] on this comment branch I said "Not everyone works at Google and builds all binaries from scratch from a monorepo every time".
So you're only trying to solve compile time issues (incremental and not)? Maybe the right long term solution is C++ modules, instead? And maybe "just" a matter of having your build environment support modules?
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 :))
"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 software engineering.
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.
Unfortunately I have some customers of my library that won't recompile. Hard to blame them because it is safety critical and needs recertification. In just glad the certification process is willing to not recertify my code when I change it
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.
Sadly, you can't easily do the full pimpl idiom in C++.
The pimpl idiom is a C idiom where a header declares an opaque structure and prototypes of functions that take pointers to that structure. In C the OP example would look something like
// widget.h
typedef struct Widget_t Widget; /* opaque! */
Widget* Widget_Create(const string* pName);
Widget* Widget_Clone(Widget*);
void Widget_Destroy(Widget*);
void Widget_click(Widget*);
int Widget_clickCount(const Widget*);
const string* Widget_label(const Widget*);
// widget.c
struct Widget_t {
int clicks;
string *name;
};
// ... implementations of the functions from the .h ...
In particular, in C `Widget` directly has `clicks` and `name` as fields.
But in c++ we like to use methods on objects, and in order to do this, you need the class declaration in scope, which means your current compilation unit needs to have seen all of Widget's data members. In practice this means if you try to use "pimpl" in C++, you do something like the OP where there is a pointer to an opaque type inside your class.
However, this is not the same thing. Methods are called with a `this` pointer, which means every access to the internal structure adds a second pointer dereference. This is why this isn't the true pimpl -- it wastes an extra deref on every access.
You can get true pimpl in current C++ but it's a lot of boilerplate and heavily relies on compiler inlining. An implementation of the example from the OP: https://godbolt.org/z/6EznxeG1n . In practice this is too much work, hard to read, and so nobody does it.
For the c++ standards committee: please add an "opaque class" feature where the class can only define non-virtual method prototypes. Then the full class declaration, in the associated cpp file, could include its parent classes, actual data layout, and function implementations.
> 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've been thinking about things like that a bit. I see a very useful and safe Rust pattern, and wonder if I can possibly implement it in C++. Mostly the answer is no, because C++ is too powerful.
I would love to proved wrong, but everything I can think of still leaves a footgun that's easy to trigger by accident, and thus negates the point of the solution.
I think the can't-reference-after-moved-from and objects-are-not-Copy-by-default are key to creating these types (at least enforced at compile time). And that would require major language changes, at least as big as the C++11 changes.
Static analysis is the answer for some of these questions.
While many of us that like C++, would wish for a different evolution process, some of this stuff can be enforced by static analysis tooling.
Just like despite being safer than C++, we still use Sonar, FindBugs, FxCop/Roslyn Analysers, go vet, rust clippy, one more reason to actually use Sonar, clang-tidy, PVS, MSVC analyse,... with languages like C and C++.
In some of these you can add your own rules even, even if not always that straightforward.
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.
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's often used in libraries where you need to guarantee ABI compatibility. Fixing a bug or implementing a feature may require adding a new member into the class, which would change its size (thus break ABI compatibility). PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI.
I also like to use it sometimes to "hide" private methods and their documentation into PIMPL, so the public header is kept clean.
This std::indirect thingie looks more like a general helper for any data 'dangling off' an object, not limited to pimpl.
Not sure how much pimpl is used in reality, but it's a pretty ok solution to speed up build times (apart from unity builds), because it avoids having to include headers that are only needed for the private state into the public interface header.
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.
Indeed. I primarily used PIMPL when I want to avoid polluting public header files with implementation detail #includes in cases where forward declarations are impossible or unwieldy and inline methods are irrelevant.
My approach to reducing the compile time of code which uses a class is moving the functionality out of the class and into standalone functions; or at least moving the method definitions into a non-header `.cpp` file.
I remember using it all the time for the Windows headers because they pollutes the compilation unit like you wouldn't believe — the rule was to only include them in c/cpp files.
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).
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'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.
That may be true, but it's a "hack" that has caused me approximately 1 issue in 15 years of writing C++ professionally, and that issue was a problem with our build system not the precompiled header.
> Still best only used in implementation files, not headers.
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 they are elsewhere, such as build system and dependency management (although I haven't touched this stack for a while now, so I would love to be surprised).
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.
Small nitpick, but a post about C++26 should really not be using `const std::string&` parameters. We have had `std::string_view` for this exact purpose since C++17.
1. click() should not be a member of the widget. A widget does not click; a user clicks a widget. A click can change a widget's state, but the state might change because of other effects, e.g. pressing a key when the widget is focused. But then, that's just one of the issues with treating UI widgets this way.
2. More to the point - clickCount. If this is a button, it shouldn't keep a record, or aggregate, of its clicks within it; and if it's a widget where this does really matter, like a range control where more clicks mean a value that goes farther along the range - you still would not keep the count of clicks, but the current position. Statistics about the interaction with an object should not be part of the object itself. At most it might be legitimate to have, say, a Widget class, a template like <class Stats> StatisticsTracker , and then class TrackedWidget which uses that as a mixin, i.e. inheriting both Widget and StatisticsTracker<ClickStats>. And that's already stretching it beyond what I would find reasonable.
3. Having something named is another aspect of objects which may be a good fit for a mixin class.
Anyway, an 'indirect' type for objects you don't know the definition of sounds nice.
A few more nitpickis about the example:
1. Instead of explicitly applying the rule-of-0 with `= default` for the copy&move ctor&assignment and the destructor - just _don't_ write anything:
class Widget
{
public:
void click();
int clickCount() const;
std::string label() const;
private:
struct Impl;
std::indirect<Impl> pimpl_;
};
and that's the beauty of the rule of 0.
2. Why return an std::string for the label? The label() method should return an std::string_view
This is just a simple example, therefore nitpicking on the semantics of the Widget methods is a bit silly.
> 1. Instead of explicitly applying the rule-of-0 with `= default` for the copy&move ctor&assignment and the destructor - just _don't_ write anything:
The blog post explicitly explains why this doesn't work. You have to define these methods in the source file because they need to see the definition of the Impl struct.
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.
Even with modules, if you expose such types over the ABI, naturally the machine code memory layout will change, this is an issue regardless of the language.
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.
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.
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 would need to think about what those custom method do, which might be different than other classes which have optional members. Now you just tell yourself "oh, it just has an optional member, no biggie". Look at my comment above regarding how short the implementation of Widget becomes when you squeeze the juice from having the rule of 0.
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.
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.
I don't really get why people keep repeating the "C++ is too big" complaint together with the implication that you need to remember the entirety of the standard library. In comparison Java has networking, GUI framework and even MIDI in its standard libraries. Is it because C++ is more closely related to C which library is so small that it barely contains anything useful? I much prefer code that uses a library feature rather than yet another poorly implemented and not documented hand rolled version of it.
Networking, GUI frameworks, and MIDI are presumably all self-contained and you would not need to be familiar with them except when working on networking, GUIs, or MIDI files, respectively. This is a general-purpose thing that could show up in any c++ code.
I thought C++ is unnecessarily complex, and then I see Rust following the same pattern... I've just thought of a complexity metric that would calculate the ratio of alphanumeric characters to punctuation.
C++ is getting more and more complex. It used to be said that people use only a small percentage of it when writing C++, but I am beginning to think that the cake is a lie here.
Besides being a common idiom, for how many warts C++ might have, no one is rewriting LLVM, GCC, V8, JVM/ART and .NET runtimes, CUDA/Metal/DirectX, Unreal, Godot,.... into something else, RIR is not happening there.
People will contend themselves with "C++ the good parts", helped by clang-tidy, PVS, MSVC analyse, and move on.
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 now has to learn a specific meta language of this codebase. Fuck that, I have enough languages and their idiosynchronies to remember for my work now. After using Go for a pair of years returning to C++ is like coming back to a big archaic mess. I'll just go learn Rust instead and forget all those new useless C++ templates like std::indirect
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 years) seeing a piece of C++14 code for the first time -- he said it reads like an entirely different language, not the C++ he's familiar with at all.
> 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 expect that they would behave in some reasonable way. And mostly, they do. That's not to say they're perfect: I feel like vomiting looking at std::variant's and how you have to work with them, as opposed to a proper case classes / algebraic union types in the language itself. And yet - when someone puts one in their class, instead of a bunch of code in a bunch of methods, you know what's going on. It does "read like a different language" somewhat, and that's good. The nicer language has been struggling to get out, as the saying goes.
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.
> 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.
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".
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) solution. The only practical way is to copy what you need copied, when you need it. Done.
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.
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.
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.
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?
You said you had concurrency problems with the STL, but none of it has any intersection with concurrency, that is left to the users. There are no expectations there unless you were using threads, atomics, mutexes etc. and they had bugs.
I'm not trying to prove anything, I'm asking why you "had concurrency problems from using the STL" when the STL doesn't have anything to do with concurrency.
You have repeatedly proven, and continue to do so, also by way of your exchanges with other commenters, that you're not asking out of curiosity. After all the previous comments we've exchanged, your line of asking was, "Which part of the STL are you expecting to be thread safe?" i.e. you were continuing to assume that I was somehow naive or uneducated. I did not assume anything to be thread safe in the way you imply (I used a simple mutex based approach to protect accesses).
If you'd been asking in good faith, the question would have been, "how did the concurrency problems look like"?
To which I'm going to answer, one of the bugs I hit was due to unexpected invalidation of a std::deque iterator. This came from being mislead to use std::deque as a quick & dirty implementation of a producer-consumer queue, and keeping iterators to track the read and write positions. Almost nobody has actually used std::deque (I hadn't either) but there is a common understanding (perhaps misunderstanding) that it is something like a chunk-queue. That vague understanding led me to believe that I can (and should, to avoid O(n) random access ) keep iterators after write operations. And using them that way did work for quite some time, I only hit confusing issues later.
(Actually random access is specified to be O(1) but this is even less widely known and makes std::deque a quite arcane data structure).
The problem with an abstract iterator interface here is that it doesn't help understanding what std::deque actually is. In case of std::deque, keeping read and write cursors works mostly fine, but it stops working (for example) if the read cursor pointed to the current end (was equal to deque::end) and the deque gets an append, which will invalidate the old end (read) cursor.
This is a good example of the complexity we have to deal with if we don't want to write a simple straightforward solution from scratch (chunk list) but instead code against something that we don't understand well. Not trying to use the STL but instead doing straightforward low level code would have made potential pitfalls more clear, and would have made bug search easier. It would have required less work to get the code to a working and maintainable state.
Another problem with std::deque is that the sizes of the chunks are not specified. They vary wildly between implementations, such that you can in practice get no performance guarantees from using std::deque, unless committing to a specific STL implementation (which is rarely practical). In fact, it is not even specified that deque uses something like chunks internally. It's too abstract to be useful.
If you have an underlying data structure that is being used from multiple threads, you can't hold on to raw pointers into the data structure. There is no way for other threads to know that it can't be changed, moved, freed or invalidated.
You need to copy the data out while a mutex is still locked (if doing simple mutex style concurrency) or you need to hold a reference count in the object that is returned so that the underlying structure knows that it can't touch that data from other threads.
I hope it isn't lost on you that the reference counting approach is much easier to do with a destructor, since the reference count can be incremented before it is given to you from the API and decremented automatically when it goes out of scope.
If you want some good concurrent queues for C++, look at this person's work:
Serious question, are you an AI programmed to be annoying?
> This isn't a problem with the standard library because a std::dequeue or any other core data structure doesn't make any promises about concurrency.
Dude, I KNOW I need to handle concurrency myself. But I'd contend the point that it isn't a problem with the STL: It is a bug (that I introduced myself) that I had to deal with because of complexity, or rather because non-obvious behaviour, because bullshit boilerplate.
> If you have an underlying data structure that is being used from multiple threads, you can't hold on to raw pointers into the data structure. There is no way for other threads to know that it can't be changed, moved, freed or invalidated.
This is totally irrelevant because if you paid attention, the problem wasn't even threads. It was concurrency, more abstractly. Iterator invalidation based on the "manifested" order of execution.
But anyway, you want to jump to reference counting. I'd say you can absolutely hold on to raw pointers from multiple threads, it entirely depends on what you do. If the threads have unpredictable lifetimes, then yes, some form of reference counting is indicated.
But when you know that isn't the case, then it isn't the case and you probably don't need reference counting.
> I hope it isn't lost on you that the reference counting approach is much easier to do with a destructor, since the reference count can be incremented before it is given to you from the API and decremented automatically when it goes out of scope.
Except when you're passing around stuff and have to duplicate or move references, and have to use APIs that receive pre-incremented or un-incremented pointers. In some cases your data structures might even be so messy that you end up with cycles.
I have my scars from making my own COM pointer classes with copy and move semantics, and also from using "official" COM pointer classes. After a couple of iterations I've decided to cut all the boilerplate and C++ ceremony that doesn't do anything, and get rid of ugly method wrappers that are a pain to step through in the debugger, and stopped clinging to a cargo cult which simply leaves you with harder to detect bugs.
You heard right, I'm back to completely manual reference counting (and only counting where I _have_ to), somehow the code is much shorter and easily understandable, I got back control over what happens. Have been able to keep atomic ops at a minimum, with RAII superfluous ops can happen easily. (Remember Chromium's 25000 copies per keystroke bug?) And there has only been a single instance where I introduced a leak, that was immediately pointed out by the D3D11 debug layer. I'm doing this approach for my second project already and have found it to work great.
There is no solution except good understanding of what you do, and good code structure that expresses this understanding. Generic "RAII" type understanding is rarely helpful IMO, you give up control and sometimes end up throwing hands in the AIIR and hope it will not break.
Thanks for the pointers to what is probably 5K lines of C++ boilerplate. But I have written half a dozen concurrent queues myself, locking and lock-free ones. Some in less than a hundred lines. Also one in ~2K lines, that was for a longer-term project where the queue needs to safely persist to disk every couple of milliseconds, while ingesting millions of messages per second and billions of bytes per second (was hitting the ~2GB/s that I could get out of my flash drive).
If you want an approachable source that leaves out the fluff, I'd recommend 1024cores by Dmitry Vyukov (only issue is formatting).
I gave you great information on how to make your queues thread safe again.
I don't know where this expectation comes from that you can reply to me and I can't reply to you. If you don't want to continue you don't have to reply.
This is totally irrelevant because if you paid attention, the problem wasn't even threads. It was concurrency, more abstractly. Iterator invalidation based on the "manifested" order of execution.
This is really just mixing terms. You aren't going to notice all your concurrency bugs without threads. If you're holding a raw pointer to an internal resource of a data structure while other threads can modify it, you aren't going to see all your bugs until multiple threads are modifying and reading from the queue.
If the threads have unpredictable lifetimes, then yes, some form of reference counting is indicated.
It isn't about threads having unpredictable lifetimes, they could all be running at the same time and have predictable lifetimes.
In some cases your data structures might even be so messy that you end up with cycles.
Then don't do that.
Thanks for the pointers to what is probably 5K lines of C++ boilerplate.
Lots of people get a lot of good out of them.
But I have written half a dozen concurrent queues myself,
You might want to benchmark and test those bad boys thoroughly if you think you can hold a raw pointer into
a data structure that can change from other threads. If you use a template you won't have to rewrite them over and over.
Also don't forget that allocations can lock and that your double allocations of the struct and data in a data structure can amplify that.
If you want an approachable source that leaves out the fluff,
Thanks, but I haven't made the same assumptions about raw pointers in concurrent data structures then blamed the STL, so I haven't had the bugs that you're talking about here.
"Great" is quite debatable. In any case, nothing I hadn't already known.
> You aren't going to notice all your concurrency bugs without threads.
True, but my problem was neither proper locking / thread safety, nor reference counting.
You still felt the need to explain to me because you don't realize the problem isn't that I don't understand what you say. The problem is that you don't understand / don't want to accept what I say, and you prefer assuming I'm talking out of my ass.
> Lots of people get a lot of good out of them.
Well if they don't want to create and understand their own but instead prefer to invite tons of unnecessary boilerplate to the point where you can't find the actual functionality -- good for them.
> You might want to benchmark and test those bad boys thoroughly if you think you can hold a raw pointer into a data structure that can change from other threads
I DO NOT THINK THAT. Why do you keep implying that my thinking is wrong? That is so arrogant of you.
Reference counting (how you keep something alive) is completely orthogonal to the queue's functionality. In my case, the queue was used as a "global" kind of object, so no reference counting needed.
> Also don't forget that allocations can lock and that your double allocations of the struct and data in a data structure can amplify that.
In general I avoid unnecessary allocations, where did I imply making "double allocations"? What I argued is that indirection may not be as bad as you think, may in fact be the correct way to make your program both more maintainable and more performant.
I try to organize memory allocation upfront to keep memory local to subsystems, which reduces or avoids contention in many cases (for example there might be only a single thread doing allocations for a subsystem at a time).
> Thanks, but I haven't made the same assumptions about raw pointers in concurrent data structures then blamed the STL, so I haven't had the bugs that you're talking about here
You're arguing all the time for just buying into stuff as a cargo cult, I'm only trying to describe how much weight all this ceremony introduces, which makes it more painful to maintain, makes it more likely to introduce bugs, and harder to find bugs. Don't explain basic C++ stuff to me. I understand it. What I'm saying is that this is not the best way to write things at all. There's a lot of "abstraction" slop that brings more downsides than upsides.
But I'm sure you never run into this type of problem... Good for you!
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?
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.
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.
Is it actually simpler, though? The unfortunate reality of this world is the fact that C++ is not the latest standard of the language or the newest shiny library, it's all of them at the same time. Adding a new way of doing the same thing decreases complexity only if you migrate all of the existing code, which nobody ever does.
