React on Rails HN RSC Demo

quietbritishjim 36m ago

I followed the link near the start to the article about std::indirect<T>, which you can use instead of std::unique_ptr<T> for the pImpl idiom: [1]

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

dgrunwald 5m ago

> It would've been much more useful to make the move constructor of indirect be deleted

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.

usrnm 1h ago

15 years ago I would've been happy reading about all these cool new things coming to C++, nowadays I'm happy I don't use it anymore and don't need to relearn everything again. Am I getting old?

nananana9 50m ago

We've been doing this for 50 years, you don't need a class hierarchy for your event struct.

  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;

quietbritishjim 46m ago

That doesn't work if you are writing a library where users of the library are able to implement their own event types.

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.

nananana9 36m ago

It does.

  enum EventType {
     ...,
     EVENT_USER_START = 0xF0000000,
  };
  struct UserEventData { uint8 placeholder[64]; }
  struct Event {
     EventType type;
     union {
         UserEventData user;
     };
  }

That aside, have you ever felt the need to implement your own Win32 event, or SDL event, or X11 event, or epoll_event, or a custom DOM event or whatever?

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.

adev_ 34m ago

What you wrote there is just an unsafe way to do std::variant. This has nothing to do with what the blog post is about.

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.

nananana9 32m ago

> This has nothing to do with what the blog post is about.

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.

adev_ 28m ago

> it's an alternative way to solve the problem presented

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

nananana9 17m ago

My point is that you don't need open polymorphism for the example given, and if you give me another example, I can show you why you don't need it there either -- because you do in fact never need it. It's an XY problem over the set X.

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.

fooker 27m ago

When this piece of code exists in a library, it makes it pretty much impossible to extend by the user of the library.

Panzerschrek 39m ago

Typical C approach. In C++ this should be done with std::variant instead. It has the exact same binary layout, but is type-safe (compared to union usage).

Panzerschrek 41m ago

Does std::polymorphic require passed types to be copyable?

aw1621107 30m ago

Looks like it depends on the specific operation(s) you want to perform [0]. For instance, constructing a std::polymorphic<T> from an object of type T or derived from T requires that that object is copy-constructible (among other requirements), but copy-assigning one std::polymorphic<T> to another only requires that T is complete.

[0]: https://eel.is/c++draft/polymorphic

ho_schi 54m ago

I need default security with a #secure and #insescure.

Not adding more stuff. So I get security, legacy compatibility and the existing flexibility.

Composite objects and C++26 the std:polymorphic type (mariusbancila.ro)