Tag Archives: github

ris – a lightweight cross-platform resource compiler for c++ projects

Why a resource compiler in the 21st century?

Starting a c++ project that will potentially need static string resources (i.e. Lua scripts) makes one search for an easy way to embed large strings in an executable. There are many ways of including static resources, but there seems to be no simple but robust, platform-independent way 1. For fast prototyping and one-shot projects, I’d like to have lightweight, minimum-configuration and install solution to the problem of embedding binary resources without having to use a large framework.

Premake, my favourite light-weight meta-build system contains a number of Lua scripts in its binary. These are embedded using a Lua script into a simple array of C-string constants. This is the simplicity that in my view should be strived for. ris is an attempt to do something similar for general c++ projects with a possibility of embedding binary blobs.

ris – cross-platform resource compiler for c++

The project (ris@github) is in its infancy, but seems already to be usable. Here’s a preview:

Defining and compiling resources

ris <path_to>/<resources>.json

with an input file as this self-explaining one:

    "namespace" : "test",
    "header" : "acceptance_test/resource.h",
    "source" : "acceptance_test/resource.cpp",
    "resources" : [
            "name" : "string_test",
            "source_type" : "string",
            "source" : "plain text"
            "name" : "binary_file_test",
            "source_type" : "file",
            "source" : "test.bin"

will generate two c++11 files to include in your project, enabling easy resource retrieval:

std::string res = test::Resource::string_test();


std::string res = test::Resource::Get("string_test");

Update 30.07.2015: now resources can be defined more concisely in YAML. A minimal resource definition in YAML looks like the following:

header: "res.h"
source: "res.cpp"

    compression: "LZ4F"
    name: "some_text"
    source: "some text"
    source_type: "string"

Enumerating the resources

Resource keys in the compiled resource can be enumerated passing a callable to GetKeys:

std::vector<std::string> keys;
test::Resource::GetKeys([&keys](char const* key){


Using an optional compression library bundle, adding a compression property to a resource description enables transparent (de)compression:

"compression" : "LZ4HC"


updated 24.11.2014:
ris now uses text resources generated and bootstrapped by its own early version. The goal is to make The code generator is customizable. The default template can be seen in template.json, and the generated header in template.h. The generation sequence can be seen in ris.cpp.

Using the second parameter to ris, it’s possible to override strings in the generator template. See an example below.


updated 27.11.2014:
One such customization is available in template_cpp03.json, where the C++11 constructs are replaced with generateable C++03 constructs.

To generate the resources using the C++03 template:

ris my_template.json template_cpp03.json

Why C++?

Such code generator as ris could most probably be developed more rapidly using any other programming language with a huge framework and a ton of libraries behind them. My personal preference for certain kinds of small projects lies in the area of self-contained single-binary/single-file executables or libraries, such as Lua. Lua is the primary motivation for this project, as it is itself a compact library for building flexible and extensible prototypes and tools. ris can act as a bootstrapping component to embed resources for building specialized shell-scripting replacements, i.e. for massive scripted file operations.



There is a number of paths this project can take from here. Features, such as robustness, performance or flexibility could all be addressed, but most probably ris will be shaped by its usage or absence of such.

A simple github + travis-ci project for quick c++ to lua binding tests

It’s sometimes necessary to create a simple example for C++ to Lua bindings on the run. Travis-CI might be of great help in that, while online C++ compilers will not suffice.

Here’s the project and a sample code:


#include <lua.hpp>
#include <LuaBridge.h>
#include <RefCountedPtr.h>
#include <LuaState.h>
#include <iostream>

void luabridge_bind(lua_State* L) {
	class Test {
		Test() {

		~Test() {


int main() {
    lua::State state;
    try {
    } catch (std::exception& e) {

[string "blabla()"]:1: attempt to call global 'blabla' (a nil value)

note the automatic lifetime management

In the process of searching for a quick header-only wrapper for the Lua state I came across LuaState which was the first one that compiled out of the box. Its advantage over other wrappers for my needs was that it did reveal the actual Lua state, with the effect of other binding libraries being usable. It could itself provide an alternative to LuaBridge for writing bindings and could be investigated further.

It’s now easy to fork the project and try out bindings online.

header-only non-intrusive json serialization in c++

A while ago I’ve started a convenience, zero error-handling, json serializer wrapper around picojson based on the Boost.Serialization and hiberlite APIs. Today the wrapper got even less intrusive for DTOs that expose their members.

Given a class that cannot be extended in its declaration, but the internals are accessible (following to the Boost.Serialization free function API):

struct Untouchable {
    int value;

With a free function defined in the ::picojson::convert namespace,

namespace picojson {
    namespace convert {

        template <class Archive>
        void json(Archive &ar, Untouchable &u) {
            ar &picojson::convert::member("value", u.value);


serialization is “again” possible:

Untouchable example = { 42 };
std::string example_string( picojson::convert::to_string(example) );

Untouchable example_deserialized = { 0 };
picojson::convert::from_string( example_string, example_deserialized );
CHECK( example.value == example_deserialized.value );


Setting travis-ci with github for a c++ project for the first time


Here, I’m trying to use travis-ci, c++, github, CATCH, premake together with my undoredo-cpp library to reduce entropy, try out continuous integration and behavior-style tests.

As a “one-man show” programmer at least at home, I’m trying to keep the discipline of writing tests first. “Growing Object-Oriented Software Guided by Tests” is perhaps a good, although a comparatively dry book for those who are not yet convinced. The blog post by Phil Nash about his latest version of the c++ single-header testing framework CATCH, moved me to finally get my hands on the free continuous integration service travis-ci, along with CATCH with a goal to rewrite the tests for my undo-redo c++ adventure in a more behavior-driven-style.

The undo-redo library is already there, and the tests as well – in gtest (see the master branch). I’d label them “explorative” at the moment since there are just too many assertions per test case, which means I’m repeating myself.

Starting continuous integration at travis-ci for c++

To start my CATCH-“BDD” exploration I’ve setup the branch first: https://github.com/d-led/undoredo-cpp/tree/catchmoci. At my landing page the project is switched on for catching the commit hooks:


The following configuration file .travis.yml is placed for travis-ci to know what to do with my non-conforming repo:

language: cpp

   - catchmoci

before_script: ls

  - make -C Build

As in all TDD practice, the build fails due to the reason that the build doesn’t work yet at all. Adding a status image to my README shines:


Fixing the build

The makefiles are created using premake4, which is a single-file makefile generator based on lua. Unfortunately, I couldn’t force the CI-virtual machine execute my binary premake4, so I had to add the generated makefiles. Now that the make process works, the tests still don’t compile:


Fixing the tests

Once the bulk of the assertions have been rewritten for CATCH, the build still failed due to an ambiguity in serializing std::nullptr_t. Fortunately, Phil has thought of (or rather tested) that, and has a macro which can be defined for the build, fixing it: CATCH_CONFIG_CPP11_NULLPTR.

Voila, travis-ci vm is happy:


Just checking locally if test reporting is fine by adding a spurious test temporarily:


The test-rewrite has been successful and all pass, the badge is green and I can go to bed


But! It’s not the end of the story! BDD! Mock-objects!

a generic c++ lua stack crawler

Sometimes one needs to walk the Lua stack on the C++ side, for example, if passing tables to C++ via the new extended LuaBridge functionality.
For that I’ve started luastackcrawler (see on github). The small test shows that it works at least in principle.
A possible use case – configuration. If the layout of a stack entry, such as a table is known, one can write own wrappers around those to easily access the values. Right now one can iterate through stack and Lua table values, which can be of several types, represented by a boost::variant.

Example, lua:

and the c++ implementation of ArraySize:

int ArraySize(boost::shared_ptr<LuaTable> T)
    if (!T)
        return 0;

    return std::count_if(
        [](std::pair<LuaMultiValue,LuaMultiValue> const& entry) {
            return GetType(entry.first) == LuaType::NUMBER;

lua + pugixml via LuaBridge

Started working on a binding of pugixml for lua: https://github.com/d-led/pugilua

pugixml supports utf-8, so, using icu4lua one could, in principle, have a nice lua-style processing of XML files. The interface is right now kept almost one-to-one to the original. It shows, at least for me, how easy it is to make bindings to C++ using LuaBridge and how easy the usage of pugixml is.