The Little Things.

They are the little things, you know. Little things that can create a smile across somebody’s face. Like, umm, waking somebody up with a slight pat and a gentle peck on their cheek or forehead, getting somebody their tea to the bed as they like it, getting somebody a toffee which they’ve been craving for since days, coming and helping them even if they never asked for it, giving somebody not-so-familiar a ride to their stop, giving them your share of food, sending long write-ups about them, wishing them birthdays and on and on it goes. Yeah, small things, people. You don’t need a Mercedes or you needn’t be a billionaire to make anybody feel good. You can just do it anywhere and every time you want to. And I’m sure, this would make YOU feel even better. And I think these are the stuffs that actually counts.

C++ NextId Generation

This class will create the NextID. This NextID class is templated so that it can be unique for each class.

#include <cstdint>
#include <atomic>

namespace blib {
  namespace utils {
    template<typename ThisClass>
    class NextID {
      typedef ::std::uint_fast64_t IdType;
      NextID( ) { 0 );
      IdType next( ) {
        return ++_id;
      ::std::atomic_uint_fast64_t _id;

C++ Templated Singleton

#include <boost/noncopyable.hpp>
#include <memory>
#include <mutex>

namespace blib {
  namespace utils {
    template <class T>
    class Singleton : private boost::noncopyable {
      static T* i( ) {
        if ( !m_pInstance ) {
          std::unique_lock<std::mutex> lock( m );
          if ( !_i ) {
            _i = std::make_unique<T>( );
        return m_pInstance;
      static std::unique_ptr<T> _i;
    template <class T> std::unique_ptr<T> Singleton<T>::_i = nullptr;

Tree Container in C++ – n ary Tree – NodeHandle

Added the NodeHandle class

        // Node Handle Implementation
        class NodeHandleImpl {
          typedef NodeType Node;
          typedef NodeHandleImpl SelfType;
          Node const* _handle;
          friend class NodeUtility;
          Node const* const pointer( ) const {
            return const_cast< Node const* const >( _handle );
          NodeHandleImpl( Node const* const aPtr = nullptr ) :
            _handle( const_cast< Node const* >( aPtr ) ) {}
          NodeHandleImpl( SelfType const& aNode ) :
            _handle( aNode._handle ) {}
          NodeHandleImpl( Node const& aNode ) :
            _handle( aNode.handle( )._handle ) {}
          ~NodeHandleImpl( ) {
            _handle = nullptr;
          bool operator==( SelfType const& aNode ) const {
            return aNode._handle == _handle;
          bool operator==( Node const& aNode ) const {
            return aNode.handle( )._handle == _handle;
          SelfType& operator=( SelfType const& aNode ) {
            _handle = aNode._handle;
            return *this;
          operator bool( ) const {
            bool ret = false;
            if ( _handle ) {
              ret = true;
            return ret;
        class NodeUtility {
          NodeType const * const getNodeInternal( NodeHandleImpl const& aNodeHandle ) {
            return const_cast< NodeType const * const >( aNodeHandle._handle );

This class will be useful in abstracting the raw pointer pointing to the parent node. In situations where allocators are there it may be useful also, in these scenarios the handle can be a index to a allocated storage.


Tree Container in C++ – n ary Tree – Part 1

While working for a small novice game engine, I wanted to create a scene graph/scene tree. I had the choice of either using st_tree /tcl or creating my own. I thought I will create one of my own just for fun. For the basic use I will be creating a simple container, that has basic usages and has pre-order, post-order, in-order iterators. In these series we will discuss about different trees, their traversing etc.

So what is a tree?

As per wikipedia:

A tree data structure can be defined recursively (locally) as a collection of nodes (starting at a root node), where each node is a data structure consisting of a value, together with a list of references to nodes (the “children”), with the constraints that no reference is duplicated, and none points to the root.

There is currently no standard defined Tree structure. But there is a proposal for Hierarchical data structures. We will see gradually if it will be possible to address all the features of the proposal, but before that in this first part we will create a basic node based tree and some iterators.

The article is in codeproject now.

Table of Content

Making a simple game – nanowars – Part1

Through this series we will develop a simple game called “nanowars”.

We will use the following:

  • A C++11 complaint compiler
  • Boost libraries
  • nanovg

The concept is simple. In the game small nano machines will compete with each other. This will give us an idea of a full-fledged game.

The essential headers and source in the game is listed in the github. The source code has ample amount of comments.

The first phase will be building a scene graph and rendering.

Gentle Introduction to Boost Phoenix


Boost Phoenix is a library for functional programming in C++. To understand Boost Phoenix we need to understand what functional programming is. In next part we will go through little bit of introduction with functional programming. Then we will proceed with boost Phoenix.

Functional Programming & Phoenix

I love Wikipedia so we will quote it out here

In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions. In functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time. Eliminating side effects, i.e. changes in state that do not depend on the function inputs, can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

For some time functional programming has only been the tool of academia and research. But recently there has been a revamp with people adopting them for general purpose use. Some of the most complex systems with the most rigid requirements are written using functional programming elements. In general functional programming has its root in Lambda calculus, which is the mathematical tool which tells us how to construct terms from terms. In simpler terms it is the theory of creating functions from functions. We have small functions, we construct larger and more complex functions from them. Stricter functional programming languages are typically used when a system’s performance and integrity are both critical. The real benefit of adopting a functional style is that our programs can be broken down into smaller, simpler pieces that are both more reliable and easier to understand. As described by Wikipedia the states in functional programming are immutable. So we can only construct new states, we cannot change them. This makes it easy to optimize and reason about the program. It also lets us lets us write powerful constructs using smaller atomic constructs.

I will not write more about functional programming here, there are already a lot of articles. Links are given in the end of article.

Boost phoenix is a library which helps us write functional programs in C++. As we will see in certain cases it makes the constructs compact and less cumbersome. The Phoenix library enables functional programming techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to functional programming principles.