Serious Changes

Serious Changes from RuntimeCompiledC++ on Vimeo.

In our second video, we show that Runtime-Compiled C++ can also handle much bigger changes - in this case adding new member variables and methods to a class to bring in entirely new features. You can add whole classes too when required.

Our first video's one-line change could actually have been achieved with "Edit and Continue" - a standard feature of Visual Studio. This essentially patches in changes to your original binaries while your app is running, and it's an enormous time-saver! However, E&C has major limitations. Most significant is that it will reject "changes to a data type that affect the layout of an object, such as data members of a class".
That essentially rules out everything but non-structural tweaking of your code. In practice however there seem to be many undocumented limitations to E&C - which mean that in a real codebase, whether it will work for a given file or a given change can feel like pot luck, and often when it fails there is no explanation as to why.

(You can read an old, but very detailed, discussion of E&C workflow here, and a list of its documented limitations in VS 2010 here)

In this video we show that RCC++ has no such limitations. This is because we compile changed classes from scratch, rather than using any binary patching technique. This also means the compilation is just as dependable as your regular compilation and when it does fail, you have an ordinary compiler error to explain why.

What's up next? Well, the ability to make quick changes is all well and good, until your changes crash the game. On our first null pointer, we have to start from scratch. Right?

Teaser

First Steps from RuntimeCompiledC++ on Vimeo.

Here's our first video: the briefest possible demo of what you can expect from the RCC++ testbed code.

The main thing you see here is our core feature: you can edit the source code for your game or application and see the changes applied, while it is running. 

How do we do that? The runtime-modifiable classes use a macro that registers the files themselves to be monitored. Whenever one of those files changes, we pick it up and recompile it into a DLL. By linking that DLL we can switch over to the new code, leaving the original EXE file untouched. This way we avoid any interpreter and use native compiled C++ throughout.

For projects with long compile or load times - like AAA games - this makes an enormous difference to iteration times while keeping all the advantages of pure C++ development.

You can also see that we haven't created a new editor or tool for working with the source you're changing - we continue to use Visual Studio, just as you would normally. The key difference is that you don't have to close and recompile your app to see the changes.



We'll explain more in our upcoming posts - or you can also check out the forums, the wiki, or download the source and have a play yourself.