Opinions?
Opinions?
However with template metaprogramming and constexpr if there is already quite something when can do into supporting it, today, specially with C++20.
Post C++20, there are ongoing plans to have support for static reflection at compile time, and metaclasses.
Microsoft demoed the current state of their VC++ prototype at Virtual C++2020 days.
"Dynamic Polymorphism with Metaclasses and Code Injection"
If you do not mind relying a bit too hard on the preprocessor you can also do it in plain C [2] (i mean, the C++ approach still relies on it a lot, but the C one goes all the way :-P).
A game engine (for a big published game, not my own stuff) i worked on at the past used this approach (the C++ one) heavily and i think it is also quite common in some frameworks.
Though personally outside of experimentation i just use Free Pascal which provides the functionality as a core feature of the language (and next version will allow attaching arbitrary attributes to properties, which addresses my "i'd like to have a description for this property for the editor without writing a GetPropertyDescription method" wish :-P).
[0] https://pastebin.com/eCYs1tv8
I've read simliar statements before but I don't think I understand how it helps.
struct foo {
int a;
int b;
const char *c;
};
and I want to automatically generate this function: void serialize_foo(foo &obj, ostream &out) {
out.serialize_int(obj.a);
out.serialize_int(obj.b);
out.serialize_string(obj.c);
}
With some sort of reflection, you can automatically build that method with something like this: void emit_serialize_method(class_definition &clazz) {
emit("void serialize_foo(" + clazz.name + "&obj, ostream &out) {");
for (auto &field : clazz.fields) {
emit(" out.serialize_" + field.type + "(obj." + field.name + ");");
}
emit("}");
}
(syntax of course varies).[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p059...
I have to say that framing reflection in terms of deriving an implementation of an interface is pretty powerful. But C++ makes it harder to do this than Rust, because you need to mutate the class definition to insert these methods in C++, but the Rust definition happens outside of the class (as vtable pointers are not contained within the class but passed around separately).
> I have to say that framing reflection in terms of deriving an implementation of an interface is pretty powerful.
Just wait till you see Haskell's Generic. (Not to be confused with generics in other languages.) It turns out for most applications you don't even need to derive an implementation of an interface.
[1] the currently non existing equivalent in C++ has been sometimes refererred as virtual concept. Once upon a time, in the 2.x era, g++ had an extension known as 'signature' which would do exactly that.
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.
well put.
Otherwise it would be a feature like RTTI that everyone "hates" if enabled by default.
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?
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.)
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.