Hacker News Reader

Comment by logicchains | Hacker News Reader

>C++26 is also a joke imho.

C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.

View on HN

Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.

Reflection is likely useful for a lot of things, but I agree serialization need a better framework.

Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.

I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

> and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

Out of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?

Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)

I can't think of a time where using reflection for serialisation hasn't come back to bite me.

Reply on news.ycombinator.com