Reflect
From Nocturnal Initiative
|
Overview
Reflect is an implementation of C++ reflection. It supports:
- Factory Allocation: Reflect objects can be allocated purely from their type id (signed 32 bit integer)
- File and Byte Stream Serialization: Reflect objects can be stored and re-created from a flat file
- Cloning: Reflect objects can automatically make deep copies of themselves
- Comparison: Reflect objects can be tested for equality
- Visitor Hosting: Reflect objects can be introspected by external APIs
- Type Conversion: Reflect objects of different types can copy common information between themselves
- Polymorphic Introspection of STL Containers: Reflect objects can examine and traverse containers without container-specific code being written (meaning the same code can traverse a string set as well as an int set)
In many ways Reflect is the backbone of Insomniac's tools code. Insomniac relies on Reflect to store most all of our tools content. This includes export data, asset definitions, placed objects, and more.
Reflect is designed to store data in a format to maximize flexibility without sacrificing a lot of speed. It also it automatically handles simple data format changes over time. In simple cases (where a static_cast would be used) Reflect can automatically range cast data stored in a file into compatible types. In complex cases it will defer to objects via virtual API to perform legacy conversion work. This helps programmers focus more on their pipeline and tool set rather than on rote legacy data conversion problems.
To accomplish this, Reflect constructs type information at run time using C++ standard RTTI and C++ template code. Reflect makes minimal use of cryptic macros, but where the benefit outweighs the cost it will use them. Reflect does not use a compile-time parsing mechanism. It does so to avoid data synchronization issues or build-system specific custom build steps.
Type Registry
All reflection information is stored within a global singleton instance of Registry. It is populated on program startup and released during shutdown. The Registry stores the type information for the currently executing process, and is never out of date. Since information is built from code during startup there is no special compile time work to do in Reflect.
Most Reflect operations make use of the centralized registry to get type information.
File Formats
Reflect can serialize to and from two different file formats:
IRB - Insomniac Reflect Binary
IRX (XML) - Insomniac Reflect XML
Getting Started
One doesn't need to understand the internals of Reflect in order to use it in practice.
For a primer on getting started with using Reflect, go to Reflect Usage.
Reference Materials
Reflect's most fundamental class hierarchy are the classes derived from Object.
Reflect Object Class Hierarchy
Reflect has a separate class hierarchy to store reflection information in memory. This information is used for all the advanced features that Reflect provides.
Reflect Reflection Class Hierarchy
Reflect currently supports a custom binary file format as well as its own schema of XML. These formats are implemented in another class hierarchy based in Archive. Other formats could be supported by implementing more Archive derived classes.
