Comment by jjoonathan | Hacker News Reader

Comment by jjoonathan | Hacker News Reader

It's nice to see that C++ is finally getting reflection. The real question is why it took so long: reflection is a killer feature in a large number of commonly occurring practical settings (GUI creation, user scripting, serialization, multithreading/IPC) yet it came to C++ relatively late in the game, to wit, after C++ got a turing-complete template system and long after grotesque workarounds like Qt's moc grew to maturity and metastasized. When there are large numbers of people using workarounds ranging from "don't use C++" (see: desktop frameworks other than Qt) to "implement your own restricted C++ parser to add reflection" (see: Qt) you would think that reflection would have found itself higher on the priority list. Is there someone here who can help me understand why the C++ standards committee had priorities that were so different from these communities for so long?

Are people making desktop apps, games, and other heavy users of reflection simply not well represented on the standards committee? Did bikeshedding delay reflection for a decade? Did language lawyers resist adding it because there exists a "clever" template-infested strategy for emulating it (at the expense of using arcane and sinfully ugly syntax in your declarations, naturally)? It sounds like it could make an interesting case study, but I'd settle for a tl;dr.

>The real question is why it took so long

Remember one of C++'s promises: if you don't use it, you don't pay for it. Your C++ programs have to be as fast as C as long as you're not using any C++-only features. The only way to have reflective information is to add all of this reflective information to your binary. But when do you add it? How? Obviously you don't want to add if the calling program never uses reflection, but it's difficult to predict in advance when this is going to happen. Worse, what if a program wants to use reflection on a pre-existing external library?

I suppose they're finding ways around this problem, but that's essentially why it's taken so long. RTTI is expensive enough, and reflection even more so. If you want polymorphism in your reflection (and reflection seems kind of useless to me without it) I don't think you can do all reflection at compile time, so some sort of payment will have to be done at runtime.

I suppose non-polymorphic reflection is enough for Qt, but it's still a very limited form of what is usually desired from a reflective interface.

You're confusing compile-time reflection (what is needed for moc) with runtime reflection (which affects binary size and execution time).

They got move semantics, smart pointers, concurrency primitives, type deduction, etc. out the door first. While I agree that reflection is important, it's not as important as those. I don't see any problem with comittee's prioritization.

Consider the metric of "damage done by the workaround."

Smart Pointers: have to put explicit refcounting in the root "Object" class

Concurrency Primitives: dependency on the POSIX API and its various "ports."

Type deducion: a few extra keystrokes, a bit of extra ugliness.

Reflection: Duplicate all ivar definitions in several places (if you control all the code) / create a new C++ parser (!) in order to add the feature to the language (if you don't). Also, you have to learn a new MOS every time you work on a different application. Interfacing two MOSes is always a nightmare.

Reply on news.ycombinator.com