Showing posts from 2016

Reflecting with Coffee (Part 4)

The journey so far ... Part 1 - all about the wonderful things we get with reflection,  Part 2 - what a type introspection runtime might look like and Part 3 - extracting the symbols from our source code with clang.
The final step is to connect the two together and fill in a few details. The reflector code is deliberately simple, the script does all the processing work. It is relatively straightforward and does not really require any explanation. Its job is to the JSON output from reflector and fill in the TypeInfoImpl::Create() specialisation.
Any scripting language would do here. In the past I probably would have reached for Perl but my language de jour is coffeescript. There are various reasons for this but feel free to insert language of choice here :) Preferably one with a handy template engine, I happen to be using doT.js.
There are a few extra bits and bobs I added that maybe worth a mention. For convenience, fundamental types (floats, ints, etc) get "type converters"…

Clangerizing (Part 3)

After a long and tedious disquisition on the specifics of implementing a RTTI system we get to the fun (!?) stuff ... generating the data, or clangerizing as I am calling it.
This is a two phase process Using clang to parse the source code and extract symbolsRunning a script over the output to generate the C++ code As I often change my mind about the RTTI implementation, having the second part as a script makes it easier to pander to my whimsical nature.

For the clang bit, we are going to write a recursive AST visitor. There are plenty of examples of how to do this online already but one more won't hurt :) The sample code for this post is on github.

Clang is awesome, modular and easy to build tools that plug into the underlying libraries. Getting it to compile on the other hand, not so much.

Once you have compiled all the source, the easiest way to get started it to copy and modify an existing tool from the llvm/tools/clang/tools folder. You'll also need to modify the CMakeList…

Reflections on Introspection (Part 2)

Following on from part 1, the idea is to create a run-time type system using clang to auto-generate the content.

But before we can get onto all the fun stuff, we what does the run-time type data look like anyway? If you want to play along at home, I have thrown the code up on github.
One of the things we want to do is automatic serialisation, because writing load and save code is just dull. For example, given some data we want to walk the structure and convert it to JSON. So given a class, we need a name, description of its fields, types and so forth. Something like this ... struct TypeInfo { // name // list of fields // list of base classes // any custom attributes }; For starters, we should probably be able to grab the type data for any class. C++ gives us the typeid() operator for static types. This is a nice feature so lets steal it for our own Type() function :) Thingamajig thingy; TypeInfo* type = Type< Thingamajig >(); …

Reflection on Reflections (Part 1)

The holidays, always a good time for reflection ... and being a programmer, reflection of course can only possibly mean "the ability of a program to examine the type or properties of an object at runtime".
Yep, this is hardly breaking new ground but I have to amuse myself somehow. So why bother with reflection? Well it gives us some cool things, such as ...

Automatic serialisation Who likes writing loading and saving code? Or packaging data for a network stream? Surely there is more interesting code to write. Tool and script integration Also, adding script bindings for functions or populating editor controls is a hardly a scintillating task. It would be nice if our classes integrated automatically with the rest of the game systems.Attaching additional attributes to variables And for that matter, validating input or adding meta data (like ranges for values) should be be at least somewhat streamlined.
In short, type introspection simplifies of a lot of tedious and error prone s…