Dimajix Developer Blog

One hot topic I am currently busy in, is reflection for C++. Reflection for a computer language means that you can access all types toegther with their methods and members at runtime using a simple string-based interface. Such a feature especially simplifies binding scripting-languages to a program by providing one wrapper that operates on the reflection information instead of binding each class, method or function by hand. Other possible usages are remote-method-invocations, serialisation, XML based configurations etc.

C++ offers only some very basic runtime type information (RTTI) out of the box and lacks full reflection. There are some projects on the net that try to close this gap (most notably the Reflex framework), but none of them really seem to be as powerful, flexible and easy-to-use as their native counterparts in Java or C#.

Dimajix's framework Magnum soon will contain some new modules that try to fill this gap, by offering the following tools:

• A generic Meta-Compiler based upon gccxml together with a specialised XML-based transformation language.


• Non-intrusive, full reflection for all public elements of any C++ program given in source.


• A Java-like scripting language built on top of the reflection together with a custom bytecode compiler.

With these tools, one can easily add generic scripting capabilities to any C++ program with only some little one-time effort. Plus it is possible to use the Metacompiler for automatically transforming any type-information given in C++ headers in any kind of text-based files, by providing a set of transformation rules which will be applied to the C++ metainformation generated with gccxml.

The new package is not completely finished yet, there are some features still missing, but work is steadily progressing. For a preview, you can simply check out the latest version of Magnum using Subversion at svn://subversion.dimajix.de/magnum.

A short intermission with a status report of Magnum. Finally I put up a public SVN repository which can be reached under svn://dimajix.de/magnum. The repository has public read access for everyone and is synched with my private development repository every night, so it is always almost up-to-date.

The most important feature that will be included in the next release version is full reflection. This means that one can access the complete type information including classes, structs, unions, enums, methods, functions, fields and variables via a dynamic interface at runtime. You can even invoke any method or create new instances of arbitrary objects. This should make it rather easy to make up a small scripting language which can access all types defined in Magnum.

This is a really huge undertaking, but most of the really hard stuff is already working (you can download the newest version via Subversion, as indicated above.). Still missing is some intelligent automatic argument casting for method-invocation (so you do not have to care about the exact needed types), some fixes for non-public class members and - most importantly - the integration into the build system.

The really special about my implementation of the reflection is that you will not need to modify your source-code (at least I try really hard to avoid the need of changes to the source code for which reflection is to be generated.) to make your classes accessible via reflection. The meta-compiler, which reads in all headers and creates some cpp files containing the needed runtime information for reflection, is also outstanding in that it uses a generic XML-based language to transform the meta-information parsed from the original header files into a new text-based output file. The metacompiler is not tied to my implementation of reflection and can (and will) be used for many other automatic header-transformations. For example one could write an XML template that generates serialisation code for arbitrary classes (this actually shouldn't be too hard). Other possible uses include the generation of COM or .Net wrappers (or for any other scripting language), etc.

As I already promised in this blog and in some emails to various people, I prepared a new developer release 0.4 of my framework "Magnum". It already contains a lot of changes and supports SCons for building it.

I also packed another archieve containing all data sets that are used for the demos - unfortunately you really need it in order to build the framework and all examples using the build scripts.

Among the changes are:

• SCons as build system.


• A much better directory structure.


• Much more pure virtual interface classes.


• XML parser and DOM-like document model.


• HTTP Server functionality.


• The skeleton of a meta-compiler for reflection and more.


• Lots of other changes that even are not documented in the changelog

I am also thinking about publishing a copy of my subversion repository online, so you can follow the development and access the most current version - but I am not sure about that and I currently don't have enough time to set up a replication mechanism.

I really tried hard to post an entry onto this blog once a month - almost 9 months ago. Now I will retry to populate this blog again with some information. So what am I doing at the moment? I am still working a lot on Magnum in my spare time. Expect an intermediate release soonwith lots of changes inside and outside; among those are:

• Switch to subversion as a source control system.


• Switch to scons as a build system.


• Removal of NVI (non virtual interface) pattern from API.


• Basic functions for a generic meta-compiler.


• Added some kind of unittests.


• Lots of API refacturing and bugfixing.

As you can see, although I haven't updated Magnum for a while, I really have been busy making it a better framework. I guess the rework of the API and the final metacompiler won't be ready for some time, so there will be an intermediate release (I don't want to say "development release", as all releases are mainly for developers) giving a glimpse of the new features mentioned above. And I promise to you, the metacompiler will be really hot!

When working with inheritance and virtual methods, there might be some surprises when one tries to call a virtual method inside a constructor - and this is the reasons why one should never ever call virtual methods inside a constructor or inside a destructor.

Consider the following simple code

class A {
public:
  A() {
      printf("A::A() calls ");
      f();
  };
  ~A() {
      printf("A::~A() calls ");
      f();
  };
  virtual void f() {
      printf("A::f()\n");
  };
};


class B : public A {
public:
  B() {
      printf("B::B() calls ");
      f();
  };
  ~B() {
      printf("B::~B() calls ");
      f();
  };
  virtual void f() {
      printf("B::f()\n");
  };
};


void main(void) {
  B obj;
  obj.f();
};


Continue reading "Inheritance, Constructors, Virtual Methods and typeid"

Today, there was the question if VBOs are really as fast as display lists in OpenGL. Normally one would expect that VBOs should be at least as good as the old methods, but it seems that depending on the batch size and on the number of batches, the opposite might be true. I found a page with a small tool for measuring performance. At least on NVidia cards, VBOs do not seem to be the ideal solution for static geometry, whereas on ATI ther performance of VBOs should be almost equal to display lists.

So maybe I have to include another render path in Magnum using display lists...