Reflection in C++ | Hacker News Reader

Reflection in C++

donw.io

78 pointsdanschuller33 comments

We already do have it, except nobody bothered to package it: DWARF4 debugging information. It's nicely structured, well-documented, easily accessed throught libdwarf; the only remaining thing to do is to package it nicely and submit to boost. It contains complete information about data layout, etc. (otherwise the debugger wouldn't know how to display your data and locate variables).

The downside is that shipping DWARF debugging info alongside of your program is not far from delivering the source code too. I guess it can be post-processed so that it only contains relevant data structures and nothing more.

Similarly, there's a COM component to access PDBs on Windows.

This guy has packaged it: https://github.com/stephenrkell/liballocs/

This seems like a bad idea. It looks like the author is attempting to reinvent java in C (there is no c++ here) because he really likes c# or java.

Most applications use an embedded interpreter to do runtime inspection and modification. The tools for the job is usually lua/python. Creating your own type system seems like a bad idea.

"is a bad idea".

To clarify, I tried to do something like this back in the 90's and it was _not_ worth the effort.

Using something like Google's Protocol Buffers or a similar system where you generate a standard serialization backend for all the plain old data types you want to send across the network is way less of a pain in the ass.

If you're concerned about the overhead, look at MsgPack or Cap'n Proto - plenty of ways to shave the yak out there without needing to roll your own.

You're talking about serialization, and I agree that using reflection for that is both an overkill and somewhat hacky (you still have to define the serialization format).

Reflection on the other hand is immensely useful if you want to, for example, automatically generate type-safe bindings for, say, Python or .NET or Java, from your C++ classes.

Wouldn't you prefer to generate type-safe bindings at compile-time?

Definitely. That's why I'm to hyped for compile-time reflection in C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/ (search for "reflection")

One of the authors of that paper, Matúš Chochlík, has been working on this for years. He has a pretty nice implementation that I've used successfully on a number of occasions, even though it requires a pre-compiler pass to generate the necessary data.

If I'm not mistaken, he has been working into getting the necessary data available from the compiler directly (which this paper would confirm).

Link to his existing library: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/

Absolutely great guy, as well. Really happy to see him still working on this, year over year.

Edit: DYAC.

In game development it tends to help solve some common problems.

Games need a lot of iteration, C++ compile times can easily get very long i.e. minutes. You might object that compile times should never be long: "oh this never happens if you do X or Y" but in reality every C++ gamedev shop I've worked at has had long compiles times. Templates and other things of that nature tend to bloat it.

Anyway so reflection helps with:

  - Hot-reloading code
  - Tweaking reflected values at runtime
  - Exposing functions for scripting languages (without having to write lots of repetitive boiler plate code) 
  - Saving / Loading

(And networking but that's not something I've experimented with personally!) Depending on how it's implemented, at least for games, it's worth it.

The first two reasons are development/debugging concerns, and the last two are somewhat hacky. Could you elaborate how reflection is the optimal solution for your last two examples?

I would say the optimal solution for the last 2 depends on the total requirements - aka there is no general optimal solution.

Both concerns are about having the need for boilerplate code (either for bindings or for serialization), which is quite repetitive to write and depends on the input types.

Now the possible solutions are from my perspective:

- Write that code by hand, which is quite tedious and error-prone.

- Use some code generator tooling (like protoc) for it. However that might require you to define your types in an IDL before going to code, which leads to an extra step in the development and build process. In my experience this works really well for big teams (because you also have an extra interface documentation against which all parties can work), but it might not be optimal for small teams and rapid iterations.

- Generate the code automatically from the type definitions in your program. Either during compile-time (which would require good compiler support for extracting the relevant details and using them for code generation) or during runtime by reflection. With reflection you are most likely getting the slowest code. But iteration times should be the fastest (no need to change IDL files, run codegen tools, etc.)

Why do you think that? Seems like a very useful tool to have.

For a statically-compiled languages, I don't see why people would prefer runtime reflection to compile-time code generation. You can reduce code duplication, but at the expense of runtime speed. But if that was the use case, I'm not certain why you would be using C++ to begin with.

If you search for "reflection" in the list of papers at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/ there are some proposals to add compile-time (as opposed to the run-time reflection described in the article) reflection/introspection to C++.

Of course compile-time reflection can be used to generate the code/data structures necessary for run-time reflection.

P.S: The blog post is from 2011

Can someone please clarify:

"What is Reflection?

A reflection API is a very basic, powerful tool that every game studio should have at their disposal. It normally contains some or all of the following features: ..."

This doesn't actually tell me what reflection is. Telling me what it normally contains or that its something that every game studio should have does not explain the concept. Could someone someone please explain what exactly reflection is as it relates to a language feature?

Reflection is the concept of having a program have knowledge about it's own structure. Kinda like having your code look into a mirror.

A really basic example of this is having you code get a list of all the names of fields of a class. This would be very useful if you want to create a generic object serializer.

In the past I used this to create a framework that would generate a UI for you based on class definitions.

Reflection can also include being able to modify your own code structure during run time.

Great explanation, thanks.

To my knowledge, only code paths that are used are generated through templates. For example if you don't use std::list<int>, you won't get std::list<int> generated. So why does the author say:

>>Template meta-programming approaches suffer from increased compile-times and along with code generation, result in larger than necessary executables.

There are two reasons:

* If you use std::vector<int>, std::vector<double> and std::vector<string> you will (probably) end up with three instantiations of std::vector ("probably" because the implementation has some leeway). This it no different than what you would get if you implemented std::vector with macros or by hand, but for some reason people like to count it as code bloat.

* Modern compilers have a tendency to instantiate the same template multiple times, (e.g., std::vector<int>, std::string) and then get rid of any duplicates ( https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.ht... ). This affects compile times, but if the compiler/linker does a good job of getting rid of the duplicates it shouldn't affect executable size. Sadly, many compilers do a bad job of getting rid of duplicates. extern templates are supposed to help out now ( http://www.stroustrup.com/C++11FAQ.html#extern-templates ).

This it no different than what you would get if you implemented std::vector with macros or by hand, but for some reason people like to count it as code bloat.

Not if you implement it as a resizeable array of bytes, which is what a lot of the std::vector-ish structures I see being used in C are. There's just one set of functions which work with different element sizes, not a set of nearly-identical ones for each element size (and sometimes even multiple identical ones for elements of the same size but different type.) It's definitely bloat when the result is highly redundant and bigger than necessary.

Just as it is possible to implement a std::vector-like container using void* without templates, it is possible to do it with templates and partial specialization. It's a question of how much work the implementor put into things.

>>but for some reason people like to count it as code bloat

Again, used code being generated is counted as bloat. This, I can't understand.

Isn't code bloat "defined" as code that is unnecessary? If it's used, it's not unnecessary. In C# with generics, the JIT compiler will generate seperate code paths for List<int>, List<double>, List<string>, etc. in order to speed up execution. The only difference with C++ templates is that it affects the executable size and is done before hand instead of at runtime (or ngen time).

The referenced Reflex/gccxml/CINT approach has now been replaced in ROOT6 with an LLVM based system called Cling.

What are those for .. in loops (as opposed to for .. :)?

http://xmlrpc-c.sourceforge.net/ is a real world implementation

That's an RPC library. I don't understand how that's relevant to reflection.

"I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind"

Alan Kay (inventor of Smalltalk)

Upvoted for the value of that quote (it's new to me), despite it not contributing to the discussion.

Interesting. But this wouldn't work in a shop because the internal API would need to be maintained.

There's a typo.

"struct Class : pubic Type". It says "pubic" instead of "public". I hope it can be fixed.

I know a C++/Java instructor (with a very dry wit) who would deliberately do this to see if his students were paying attention.

Reply on news.ycombinator.com