Welcome to the RCC++ blog!
This technique allows you to change your C++ code while it's running.
Available as liberally licensed open source code, it uses no scripting, no VM, no external tools - you can apply it to your own code and you can continue to use your favourite IDE. We think the quit-recompile-restart-reload cycle we're all used to could soon be a thing of the past.
If this is your first visit, watch the first steps video on the right.
If you want to know more, start here.
04 January 2015
Developers can now call RuntimeObjectSystem::SetIntermediateDir( const char* path_, unsigned short projectId_ = 0 ); to set a path for the given project id. The main use for this is when a project might include the same source file but compile it with different settings.
Additionally the optimization level used is automatically added to the intermediate directory, so there is no need to clean a build when switching from debug to release and vice versa.
As usual, see the Pull Request for more details.
08 September 2014
The Undo / Redo feature allows developers to move backwards and forwards between changes made to code in their running program, and as this doesn't involve compilation it can be extremely fast. I find this very useful for comparing subtle changes, and for performance profiling. Note that by default the history size is 0, so the feature is disabled, and this doesn't alter or keep any source code changes. For more details on how to use the new Undo / Redo feature see the wiki.
The Optimization Level feature, used in the video to get Optimize for Debug in Release code, is a simple set of optimization controls for Runtime Compiled C++. The enumeration RCppOptimizationLevel can be used to control what level of optimization is used; for example the video demonstrates switching between RCCPPOPTIMIZATIONLEVEL_DEBUG and RCCPPOPTIMIZATIONLEVEL_DEFAULT. For many advanced developers who wish to control their own optimizations, the RCCPPOPTIMIZATIONLEVEL_NOT_SET can be used so that they can control their own settings via the additional compile options. Once again see the wiki for more information on using Optmization Levels.
The latest code also corrects a bug where the additional compile and link options were not being sent to the Posix (Linux / Mac OS X) compiler. Posix (gcc and clang++) compile options are appended to the compile string, and link options are appended with a preceding -Wl, so should use comma separated parameters.
14 March 2014
|Debug view of Kythera in action during a dogfight in Star Citizen|
Moon Collider and Cloud Imperium recently announced that the hugely ambitious crowd funded space sim Star Citizen has its AI powered by Kythera. Regular followers of our blog might spot that Moon Collider is helmed by Matthew Jack, co-founder of Runtime Compiled C++. Naturally Matthew turned to using RCC++ for making it possible to change high-level code such as behaviour selection and behaviours (more details on the Kythera website). With Kythera behind other upcoming games I expect RCC++ usage to continue to grow.
In addition to some amazing games featuring RCC++, Moon Collider (previously Intelligent Artefacts) have been contributing to RCC++ development and helping to fund me taking time away from my own project Avoyd (which uses RCC++ for almost the entire code-base) to develop new features for RCC++.
I'm looking forwards to hearing more from Moon Collider, Cloud Imperium, and other developers using Kythera about their experience with RCC++ in future, and will post any relevant news on the blog. If you happen to be in San Francisco for the GDC Conference, Matthew and the rest of the Kythera team will be there, so do try to meet up to find out more about their AI middleware and RCC++.
13 March 2014
For the complete list of changes, see the pull request.
05 February 2014
Transcript and slides
The wonderful folk who organise the yearly Develop Conference in Brighton, UK, have given us permission to publish the video we took of our 2012 talk on RCC++.
Looking back at the talk Runtime Compiled C++ has come a long way, with Mac OS X and Linux support along with a host of features which make it easier to use. Even more developers have implemented runtime compilation, with the Molecule Engine adding support for C++ code as scripts, and Seiya Ishibashi (@i_saint) having developed a commercial plugin for Visual Studio called Alcantarea along with a Dynamic Patcher available on Github which is apparently used by Riot Games.
21 October 2013
This source code discovery doesn't noticeably increase start up times, but it brought forwards my priorities on the issue of improvements to turning off RCC++. I've introduced two new methods, one which can be used at runtime and another which is a compile flag. Documentation is again available on the wiki.
Details of the changes for both these fixes are found in the pull request here and bug fix here.
Márton Tamás once again has helped finding and fixing a bug with the alternative file watcher API on Windows, and whilst testing this fix I found that the watched paths were not being cleaned of ..'s so I also fixed that. The fixes for these are in the pull request here.
29 September 2013
Build TestsThe team over at Intelligent Artefacts recently asked if I could help them add build tests for their continuous integration testing. These tests are needed to ensure that they know if they'd added code which would breaks runtime compilation. This is a really good addition to the library, and I'm thankful to them for sponsoring the work and allowing me to include the changes under the standard RCC++ zlib license so that anyone can use and modify the code.
There are two new test functions added to IRuntimeObjectSystem and implemented in RuntimeObjectSystem:
// other functions...
// tests one by one touching each runtime modifiable source file
// returns the number of errors - 0 if all passed.
virtual int TestBuildAllRuntimeSourceFiles(
ITestBuildNotifier* callback, bool bTestFileTracking ) = 0;
// tests touching each header which has RUNTIME_MODIFIABLE_INCLUDE.
// returns the number of errors - 0 if all passed.
virtual int TestBuildAllRuntimeHeaders(
ITestBuildNotifier* callback, bool bTestFileTracking ) = 0;
For the most simple use case, the following should be sufficient to perform the required tests:
pRuntimeObjectSystem->TestBuildAllRuntimeSourceFiles( NULL, false );
Have a look at the SimpleTest application example in the source file Game.cpp for a more complete example. This updates the GUI and permits cancelling mid test by closing the application normally. The tests are performed using the Options menu.
Note that the bTestFileTracking parameter should be false for most circumstances. When true this also tests the file change notification system in RCC++ by changing the modification times on the files. This will then require a full rebuild of these when you next come to normally compiling the code. The TestBuildAllRuntimeHeaders function will test the header file tracking code in RCC++. Both of these tests are mainly for those modifying The RuntimeObjectSystem or RuntimeCompiler libraries.
Running these alongside any normal compilation checks on a build server after check-ins is a great way to ensure you don't break RCC++ by accident without realizing.
The changeset for these changes is here.
Improved DocumentationI've been making some effort to increase the documentation. If you're curious head over to the wiki and take a look. As always feedback appreciated. In future I plan to move to using Doxygen so everything is part of the git repository.
An alternative Windows file watcher
- Matthew Jack at Intelligent Artefacts (and a founder of RCC++) discovered an issue when using code on machine with no development environment. I've submitted the fix here.
- Ethan Trịnh has contributed a compile fix for VS2013.
- Some further fixes, added missing license files for included dependencies and the alternate Windows file watcher API are all listed here.
31 July 2013
Runtime compile of source dependencies
Improved compiler support
- Added support for Visual Studio 2013 - however this is as yet untested.
- Added support for cross compile to 32bit on 64bit Linux/MacOSX systems, thanks to Gaoren Xu for discovering this issue and helping with the solution.
Cleaning build temporaries
23 May 2013
- The macro for the runtime source dependency has had it's spelling corrected, and is now RUNTIME_COMPILER_SOURCEDEPENDENCY (no longer missing the second D). We've also cleaned up the internals as several different wrong spellings of 'dependency' were in use!
- On initialization the runtime object system now directly uses the PerModuleInterface::GetInstance(), rather than querying the executable. This way RCC++ can be used in a DLL in the project, and multiple DLL's are supported though you will need to explicitly call RuntimeObjectSystem::SetupObjectConstructors() for each one.
- On Windows, the compiler now kills the compile cmd process by default when complete. This adds about 0.3s to the startup of following compiles due to running the batch file for Visual Studio to set up the environment variables, however it resolves an issue where the cmd process was holding onto handles (for example sockets) the main process wanted to close. This is especially a problem if the main process terminated abnormally, as a zombie cmd process is then left behind. To get faster compiles by keeping the cmd process alive (with the risks this entails), call the RuntimeObjectSystem::SetFastCompileMode() function with true as the parameter.
26 April 2013
A runtime source dependency is a source file which you need to have compiled when a given header is included by a runtime modifiable source file. Whilst having the source in a library and using the Runtime Link Library feature solves this problem to an extent, sometimes you don't want to create a whole library and thus the ability to compile in dependencies is a really useful feature. Using this feature simply requires the following lines in a header:
If the header is called SomeFeature.h then the source file SomeFeature.cpp is compiled when any runtime modifiable code is changed which includes this header. Using the same filename as the header is required at the moment, in part due to issues with getting full paths from builds on Linux with GCC.
This brings us to the bug fix on Linux - although we'd implemented a system to get the full path for runtime modified source files from GCC, this hadn't been implemented for runtime includes and making the above changes caught this bug, so it's now been fixed. GCC only embeds the path passed in for __FILE__, which can be a relative path from the compile location, so we have to embed the compile path using the pre-processor define COMPILE_PATH="$(PWD)/"; Note that this isn't required if your build system uses full paths, which the cmake builds do, as does the internal GCC runtime compiler.
Note that I'm experiencing an odd issue on my cmake builds on Linux with makefiles - the Eclipse generated files work well however the makefile ones compile but the SimpleTest program fails to create a glfw window.