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;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.
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.
> 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...
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.
usrnm•1h ago