Introduction

There have been many libraries that attempt to provide Reflection tools for C++ programs. The most robust solution is the Boost Mirror library. Despite its ability to reflect just about every c++ construct, the Boost Mirror library requires the developer to enter more text to describe the interface than it took to write the interface in the first place.

Boost.Reflect attempts to find a middle ground with a focus on providing the most useful features while minimizing the amount of work a developer must do to reflect those properties. Boost.Reflect goes one step further and provides a generic Type Erasure construct, boost::reflect::any_ptr<Interface>.

Motivation

It is not uncommon for developers to write some code that needs to interface with many different systems in slightly different ways. The result is ususally the creation of many different "wrappers" each exposing the core function of an object in a slightly different way.

• Remote Procedure Client / Server Stubs
• Scripting Language Hooks
• Type Erasure Interfaces
• Command Line Arguments
• Actor Paradigmn
• Configuration

All of these tasks represent the creation of code that is derived from the core interface in a well defined manner. Each wrapper is tightly coupled to the core interface, such that if the core interface changes then all the wrappers must make a similar change. Coding these wrappers is the type of task that makes your hands ache just thinking about all of the mindless typing involved.

Reflection

The reflection provided by Boost.Reflect focuses on exposing typenames, inheritance, return values, method names, parameter types, constness, and public members. All reflection is non-invasive and may be added to any class or struct.

Type Erasure

In the world of generic programming, type information tends to propogate as template parameters. "Type Erasure is the process of turning a wide variety of types with a common interface into one type with that same interface."

• C++ Template Metaprogramming by Dave Abrahams & Aleksy Curtovoy

Common uses of type erasure include boost::any and boost::function. Boost.Any erases all type information except its name and copy semantics. Boost.Function erases everything about a type except the calling signature. Algorithms written with Boost.Any and Boost.Function can be agnostic to the huge amount of type variation possible for functors, function pointers, member function pointers, or storage.

This article on type erasure shows how Generic Programming (Templates) often conflicts with good Object Oriented design because generic programing exposes the internal implementation details that good Object Oriented design goes to great lengths to hide.

Good engineering involves compromise at every turn. A good, working, finished product is never pure by the standards of any one idiom or methodology. The art of good engineering is not the art of discovering and applying the one right idiom over all others. The art of good engineering is to know what your options are, and then to choose your trade-offs wisely rather than letting others choose them for you.

I found the following quote from the article really helps put the debate between 'fast' generic programing and 'slow' object oriented programming.

Optimization whose effect no user ever notices is the root of many evils, among them the failure of software projects and the subsequent failure of businesses.

Boost.Reflect focuses on being as efficeint as possible without sacraficing development speed and proper Object Oriented abstraction. If you don't use boost::reflect::any_ptr<Interface> in your inner loops, then your users will never notice one extra layer of indirection or an extra couple of bytes of RAM. Your company, managers, and customers will notice the cost savings in reducing your development time, decouping components, and added resiliance to change that developing with Boost.Reflect can provide through type erasure.