
Reflection in C++ - danschuller
http://donw.io/post/reflection-cpp-1/
======
zvrba
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.

~~~
anewhnaccount
This guy has packaged it:
[https://github.com/stephenrkell/liballocs/](https://github.com/stephenrkell/liballocs/)

------
ascotan
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.

------
aappleby
"is a bad idea".

~~~
danschuller
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.

~~~
colordrops
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?

~~~
Matthias247
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.)

------
rwj
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.

------
Kristine1975
If you search for "reflection" in the list of papers at [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/](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

------
bogomipz
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?

~~~
robbbbbbbbb
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.

~~~
bogomipz
Great explanation, thanks.

------
nurettin
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.

?

~~~
maxlybbert
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...](https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html) ). 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](http://www.stroustrup.com/C++11FAQ.html#extern-templates) ).

~~~
userbinator
_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.

~~~
maxlybbert
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.

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

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

------
known
[http://xmlrpc-c.sourceforge.net/](http://xmlrpc-c.sourceforge.net/) is a real
world implementation

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

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

Alan Kay (inventor of Smalltalk)

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

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

------
partycoder
There's a typo.

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

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

