Hacker News Reader

Comment by jfkebwjsbx | Hacker News Reader

What is definitely missing is compile time reflection. I don’t think many devs care about the runtime one.

For a statically-compiled language, runtime reflection is probably a violation of the zero-cost overhead principle. There is a limited amount of reflection that can be done cheaply that has some value: getting the address of the vtable of an object [assuming it has one] for uniqueness, or getting function pointer identities for generic invokable objects.

Given compile-time reflection, providing standard library functionality for certain runtime reflection tasks (such as providing a list of field information for a struct/class/union, or listing function arguments) could be useful. On the other hand, it could end up being a locale-like scenario where it's either overkill or too weak for your use case, never in the middle.

> a locale-like scenario where it's either overkill or too weak for your use case, never in the middle.

well put.

We can anyway generate the runtime one at compile time, that is how many Java and .NET compiler plugins and annotation processors work.

Exactly, with a compile-time one it would be relatively easy to build portable runtime reflection frameworks/libs, for those that really need it.

Otherwise it would be a feature like RTTI that everyone "hates" if enabled by default.

This might come true some day, but it seems not in C++20 and in recent static reflection proposals there was no way to distinguish reflected from non-reflected members in the same class.

Yep that is post C++20.

I am hardly a C++ user nowadays, but such stuff interests me, because the Windows Development team managed to push C++/WinRT as replacement for C++/CX, but are declining any improvement to Visual Studio support (at least comparable to C++/CX) until ISO C++ gets similar capabilities to C++/CX.

So given that some C++ usage is required depending on which APIs you want to access from .NET, you can imagine there are many WinDevs not very happy with the downgrade in tooling support.

Back to your point, in what cases might such distinction be relevant?

One example is in: https://github.com/arc80/plywood/blob/master/repos/plywood/s...

Here, only one data member is meant to be serialized. The others members are there to accelerate lookups into the first data member. (Full disclosure: that structure isn't actually serialized yet, but the Arc80 Engine which uses Plywood has similar examples.)

Interesting! Could sufficiently enhanced compile-time reflection (say we do get supercharged CT reflection in C++2b*) be used to implement fully transparent&automatic versioning in serialization frameworks? I know very little on this subject but I think boost serialization, though capable of handling multiple versions of a given class, requires manually 'tagging' source files as being say, version 1,2,etc.

Thanks!

I haven't looked at the C++ reflection proposal in a bit, but I think that attributes are reflected so you should be able to use your own attributes to mark non serializable objects

Perhaps, but it's easily overlooked because every project that needs runtime reflection badly enough has already rolled their own. (Some game engines have multiple reflection systems, eg. shader parameters vs. serialization.) This framework takes a particular approach and makes it an (almost) standalone component.

Why do/did you go for runtime reflection for all that? I thought you would use it for external scripting or mods or things like that, but not for eg serialization. I guess I am missing something.

Everyone misses compile time reflection because it solves many use cases easily (like serialization) without having to go for a complex solution or incur in performance penalties of runtime reflection. In contrast, I doubt many people care about general runtime reflection which I’d expect to be a mess in C++ and most likely not as fast as people wanted.

The biggest advantage I find with runtime reflection it that it's possible to load and manipulate data that has no C++ definition at all. This is actually handy when working with 3D geometry consumed by a GPU.

Reply on news.ycombinator.com