> Never null: it always holds a value, except in the moved-from state (but features a member function called valueless_after_move() that lets you check the state)
Ugh, what a mess. Surely the whole point of using this rather than unique_ptr is to avoid such a trap! A safe move constructor isn't possible here because you'd either have to re-init your moved-from object, or do element-wise move (with `MyClass(MyClass&& other): impl(std::in_place, *other.impl) {}`) but those would stop your move constructor being noexcept. It would've been much more useful to make the move constructor of indirect be deleted, which is what people typically did with a pImpl-based classes in the past.
[1] https://mariusbancila.ro/blog/2026/07/23/the-pimpl-idiom-and...
No, that would be less useful. As-is, you can use a class with a `std::indirect<T>` member in a `std::vector` just fine, thanks to the move constructor.
With `std::indirect` in `std::vector`, the vector can use move the `indirect` internally when reallocating, and as a user of the vector you will never encounter the moved-from state.
It's annoying that C++ doesn't have destructive move and thus needs to relax class invariants after a move happened, but in practice it's usually not a big deal because use-after-move is usually a bug, nothing anyone would do intentionally.
std::variant has a similar issue with valueless_after_exception, which given the semantics of the language, it has to have. But similarly, this essentially never happens in practice, and I've never encountered a bug with a valueless std::variant.
The docs for Boost.Variant state that avoiding a valueless state requires some kind of additional storage beyond that strictly required for the intended value. In the current implementation this means that assignment may allocate (modulo optimizations described further down the page) [0], which is obviously unacceptable for some use cases.
The proposal for std::indirect and std::polymorphic describes similar costs for avoiding a valueless state, though for moves instead of assignment [1]:
> Without a valueless state, moving indirect or polymorphic would require allocation and moving from the owned object. This would be expensive and would require the owned object to be moveable. The existence of a valueless state allows move to be implemented cheaply without requiring the owned object to be moveable.
Presumably the committee made a similar decision with respect to a valueless state for std::variant as they did for std::polymorphic/indirect.
[0]: https://www.boost.org/doc/libs/latest/doc/html/variant/desig...
[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p30...
Perhaps move-assignment would have been a better example? That one at least mentions construction using an rvalue so I think that specific operation would work for move-only types.
Though now that I think about a bit more I suppose it's a bit of a moot point since the constructors all look like they require a copy-constructible T
Not adding more stuff. So I get security, legacy compatibility and the existing flexibility.
enum EventType {
EVENT_NONE,
EVENT_TEMPERATURE_READING,
EVENT_SMOKE_DETECTED,
EVENT_CARBON_MONOXIDE_DETECTED,
};
struct Event {
EventType type;
union {
TemperatureDeadingData temperature_reading;
SmokeDetectedData smoke_detected;
CarbonMonoxideDetected carbon_monoxide_detected
} data;
};
std::vector<Event> events;A way to see it is some sort of type-erasure over destruction and copy-construction (plus another corner case for mismatched allocators).
The constructor of polymorphics captures the type of the subclass during its constructor (they didn't make the same mistake as with shared_ptr of giving it a pointer constructor, like the UB in case the destructor is not virtual in Base *b; shared_ptr<Base> sp{b}). With this, it can instantiate a template (a control block) where the subclass is known.
https://www.boost.org/doc/libs/latest/doc/html/poly_collecti...
Code that turns into an unmaintainable mess the moment even one of the types involved contains dynamically allocated data? Yes, seen that thousands of times.
The article creates a type that has typesafety, resource management and basic copy/assignment operations backed in.
The blog is about Open polymorphism. Where the list of compatible Object can be extended dynamically (Which is handy for some type of error report for instance).
You can do that since forever in C++ (Since the first support for inheritance), the only thing std::polymorphism brings is the ability to do it without dynamic allocations, emplacement new or lifetime problems.
It's an alternative way to solve the problem presented, which trivially allows you to make a std::vector<Event> (the whole point the article is building up to).
> the only thing std::polymorphism brings is the ability to do it without dynamic allocations, emplacement new or lifetime problems.
Which the version I showed has none of.
No it's not and you apparently did not understand the concept behind it (or more likely, do not want to understand the concept behind it).
Your solution is not an implementation of Open Polymorphism, it is just a poor man implementation of std::variant.
> Which the version I showed has none of.
Because it is not the same thing like explain by my previous comment and in around 5 other comments around mine soon I guess.
But you are entirely free to grunt around and continue to imply that C++ committee people are implementing something useless (Which they are not, this is useful).
If a programmer is reaching for a library, they want it to solve a concrete task. Nobody wants to subclass your Event type, if I have to do it, you've failed at your job.
Because it's well known that subclassing is used only for Event type and never EVER anything else requires polymorphism #irony.
The only part of this discussion where you are right is that closed polymorphism (std:: variant) is better than open polymorphism when it can be applied.
And even there, your proposed implementation is utter garbage that leaks memory and that I would refuse straight away in any PR.
No, it has something much worse, it has a memory leak. The nested types inside the union allocate memory, and they don't get destructed when Event gets destructed. Don't do this in modern C++, it's a terrible terrible idea, these kinds of constructs are very hard to get correct manually. Just use std::variant.
Tagged unions (especially with resource-managing types) is hard to implement correctly in C++ (and not trivial in C either). Don't do it, use std::variant.
Even for a self-contained code base, it's a pain compared to a type that just works with any current or future derived class.
enum EventType {
...,
EVENT_USER_START = 0xF0000000,
};
struct UserEventData { uint8 placeholder[64]; }
struct Event {
EventType type;
union {
UserEventData user;
};
}
If you're writing a good library, give the user the data they need, and let them handle it however they wish, don't force them int your framework.
Typically with your pattern, you'd use a switch statement on the event type, but what do you do if it's in the user-defined space (type>=EVENT_USER_START)? You could add mandatory function pointers for relevant handlers in a header prefix, but now you're just reimplementing virtual methods. As is common in C, you end up making your own object-oriented language, only with more effort and not as good.
-or- in places where you simply want to maintain a compilation firewall, for compile times, or encapsulation... i.e. you don't want to update the "visitor" in a pile of unrelated files each time you come up with a new Event.