Thursday, March 24, 2016

Reflection in C++

Topics: C++, Serialization, Reflection, Templates, JSON, Visitor pattern

I've posted a new article here titled "Automating Object Serialization/De-serialization in C++":

 http://inspired-code.blogspot.com.au/p/automating-object-serializationdeserial.html

Overview


Some languages support reflection better than others. C++ has its runtime type information system which is reasonably limited. It won't help you much if you are doing serialization and de-serialization, so you end up writing a lot of boiler-plate code which feels like you are repeating yourself a lot.

Serialization though is just one example. In the article I give a bit of a run down on some of the alternatives and present a solution which reduces how much you have to repeat yourself.
In the end, this is an example of all you should end up needing to write to define and declare a struct with members and the code needed for being able to serialize/de-serialize it:

    DECLARE_CLASS(Color)
       DECLARE_MEMBER(int, red)
       DECLARE_MEMBER(int, green)
       DECLARE_MEMBER(int, blue)
    END_DECLARE_CLASS

That is it. No duplicated info anywhere. I show how this isn't locked in to just serializing/de serializing too, and give examples of hashing and other uses. In follow up articles, I can elaborate on some of those other uses and the details of those.

Full article here:

  http://inspired-code.blogspot.com.au/p/automating-object-serializationdeserial.html


Monday, March 21, 2016

Using C++ Template Meta-Programming to expose C functions in Lua


I've written an article on auto-magical language bindings, which you can find here: http://inspired-code.blogspot.com/p/automagical-language-bindings-using-c.html

The specifics of the article shows how to expose C functions to lua.

The summary is, all you need to do to expose a function is add it to the list of exposed functions wrapped with the macro AUTO_BIND_C_FUNTION_TO_LUA such as in the following code snippet:


// Some function prototypes to expose
void someFunc(int arg1, int arg2, const char* arg3);
void anotherFunc(const char* arg1, double arg2, int arg2);
// ... etc ...
// Import table
static const struct luaL_Reg scriptCallableFunctions[] =
{
  AUTO_BIND_C_FUNTION_TO_LUA(someFunc)
  AUTO_BIND_C_FUNTION_TO_LUA(anotherFunc)
  // ... etc ...
};

// Register all the functions we want wrapped
void registerLuaBindings(lua_State* L)
{
  // Register all of our bindings
  for (luaL_Reg r : scriptCallableFunctions) {
    lua_pushcclosure(L, r.func, 0);
    lua_setglobal(L, r.name);
  }
}


That certainly simplifies the work of exposing a function to Lua. I believe the approach could be adapted relatively easily for possibly other languages, such as python also.

Hope you like it.

Sunday, March 20, 2016

Idiomatic way in C++ to test debug/release etc

Idiomatic way in C++ to test debug/release etc.



This is just a quick post on how one can improve their code by removing some #ifdefs and doing things a better way.

It is common to see this style of code:


void SomeFunction(int x)
{
      ...
#ifndef NDEBUG    // Double negative - if ! ! debug - eg: is debug
      ...
      // extra debug checks
      ...
#else
      ...
#endif
      ...
}


Usually NDEBUG is the define that is checked for release/debug checking as it is defined in the C standard in regards to assert.h. I don't know of any other defines the language specifies in relation to release/debug modes. So typically release builds will have NDEBUG defined, and non-release builds do not.

However using preprocessor checks is not very idiomatic C++. It also means the preprocessor hides part of the code from the compiler, skipping important compiler checks of the other half of the code, which means that if not regularly compiling all the permutations of defines that some sides of #if conditions can rot and then require additional maintenance when enabling them. Better is to have the compiler parse both sides and allow it to determine that one side of the branch is never taken and allow the compiler to eliminate it.

So what is a good way to formulate turning a define in to an idiomatic way to test this in C++?

One can do this in a header:


enum BuildType
{
#ifndef NDEBUG
 isRelease = 0,
 isDebug = 1
#else
 isDebug = 0,
 isRelease = 1
#endif
};


And then in code check the condition like this:


void SomeFunction(int x)
{
      ...
      if ( isDebug ) {
         ...
         // extra debug checks
         ...
      } else {
         ...
      }
      ...
}


Using an enum means that we don't need to create any variables to do this.

Obviously you can extrapolate this to testing for things besides debug/release. Also in the place where we declare the enum, if wanting to make it a runtime setting, instead of compile time setting, it becomes quite trivial to change that.
Where this doesn't work so well is if using #ifdef to choose between two options that will either work or not depending on the compiler or target platform, eg if one side is iOS code and the other Win32 code, obviously it may not be worth making the compiler able to accept both sides of the #if/#else. I believe in these cases where you have platform specific code, generally you want to hide that from the generic code and abstract the platform code and put platform specific implementations in their own separate files.