It's been a while since I wrote a new blog so here it goes. So After a few weeks of revamping my previous C++ Reflection System, found here , I've decided to write a short summary on the new features, and trials that went into designing the new system.

 The previous iteration of the Archetype System was a step in the right direction, but had a few limitations that I was not fond of , in both efficiency and reflection capabilities. My first step in updating the sdk was to create a new reflection creation suite. After planning, I ended up with two systems that work in conjunction to provide users with the an automated reflection generator. The suite consists of a reflection generator and an alias system, which is used to define new container types that will gain the same reflection capabilities as the currently supported stl containers.

The container types that are currently supported are ; vectors(arrays), deques, lists, sets, multimaps, stacks, queues, and all types of smart pointers. Through the use of defines, the user may gain functions such as push_back/pop_back , for vectors, to ease the process of accessing data. Below shows the registration of the stl library with the alias system.




       The statements that have the extension "FREE_XXX" allow the user to supply exterior functions for containers that require additional steps, such as std::multimap.insert(std::make_pair<XXX,XXX>). The creation of the alias system allows users to forego the previous requirement of the reflection system. By registering containers with the alias system, the previous requirement for FSTRUCT/FCLASS constructs are eliminated, which is beneficial to users that may be using an external template library.       

         The update to the reflection generator focused on providing a better workflow for generating the reflection information after a user updates a header. I began working on a new parser implementation, in the previous iteration the parser was the bottleneck. After a few days of working I designed a parser implementation that was 98.7% faster than the previous iteration. This new parser generates the reflection information at the same time as the parsing phase, and also allowed me to add the feature of generating reflection for namespaces. Because of this new parser, I was able to add a second new feature, users may now access the reflection of an FCLASS/FENUM/FSTRUCT through a string that is indicative of the structures scope. 

The FEnum "HulioCentric" is within the namespace "Hulio", which is within the namespace "Janis". To access HulioCentric through the FEnumManager, the user supplies the string, "Janis::Hulio::HulioCentric".

The run-time reflection sdk was updated to reflect concerns found from software developers in the field of game programming. A previous limitation of the FCLASS structure was that each defined FClass would have to be derived from FObject. This was an issue because it required users to use multiple inheritance, an implementation that is frowned upon beyond inheriting from multiple interfaces. Because of this, I removed the requirement for FObject inheritance, and the user may now subclass from as many classes as they require, both reflected and non reflected.

Another added feature to Archetype2.0 is the "CastTo" function. The CastTo function allows users to Cast their FClass/FStruct reflection data to a parent classes reflection data. This allows the user to call functions that were marked for reflection on a parent class from a child class. A limitation is that FClasses may only be derived from FClasses and FStructs may only be derived from FStructs.

All reflected functions generate a parameter struct that users may use to pass arguments to the function. This method becomes an alternative to the previous method of using the alloca function and templated function calls to FCall.

The new archetype run-time system is now supports multithreading. I've been using previous projects, game engines and etc, for testing purposes and will hopefully be able to release a bug free sdk soon.