Droplet of reflection for C ++. Part One: Development Retrospective

Create objects by the string names of their classes and receive information about the heirs of classes during program execution. C ++ either does not support or poorly supports similar functionality out of the box.

In this series of articles I will talk in detail about how I created my own micro-library that implements such behavior and how I prepared it for publication.





My conscience will not be clear if I do not confess one cunning thought that pushed me to write this cycle of articles. As it concerns marketing, I use hide-and-seek under cat. I warn you: there is a lot of text there.



This series of articles consists of three parts:

The first part, retrospective . It details the history of the development of the micro-library.
Why read: This part is intended for people who are interested in what kind of bumps can be stuffed in the process of writing code to register information about classes before the start of the main () function. Serious C ++ programmers may find this part naive and not interesting.

The second part, the publication . Describes the preparation of the library repository for publication: the choice of license, the organization of the repository structure, the study of CMake, etc.
Why read: This part can be useful for people who have their own library gathering dust and want to know how to present this library to people.

The third part, the documentation . Here is a look at the library from the user's point of view: the main use cases of use, the mechanism for registering classes, the API for creating objects using string class names, the API for accessing information about inherited classes through specifying the parent class during program execution. This part contains sample code as well as future plans.
Why read: This part can be useful for people who want to get the functionality provided by cpprt in their project, and also, again, for those who want to contribute to the development of the library and, perhaps, even to the development of the “main library”.

For this, I finish the cycle, and turn to the essence of this particular article.

0. Introduction

The structure of this article:

Section number 0 . This section. It tells about the cpprt library analogues and gives some thoughts on why cpprt has a right to exist if there are serious analogues.
Section number 1 . Why do I need reflection in C ++.
Section number 2 . About finding a solution for the arisen task.
Section number 3 . About the first implementation of the class registration mechanism.
Section number 4 . About what problems there were in the first decision about how I corrected them.
Section number 5 . Adding the ability to register information about inheritance.
Section number 6 . Conclusion

And now, finally, we start the conversation.

At the time of publication of this series of articles, my library allows very little:
1. Create objects by the string name of their classes.
2. Get information about the successors of classes at runtime.

Already when working on an article a friend threw a link to this review of existing libraries. It refers to really powerful projects. They allow you to equip C ++ classes with a thick layer of meta information and related functionality: create objects using string class names, get a list of fields and methods of classes during program execution, call these methods ... In short, they allow you to bathe in whole oceans of meta information. My achievements seemed insignificant in the shadow of competitors. However, having calmed down a bit, I thought: perhaps there is a certain meaning to tell about the work I have done.

First, in these articles a lot of attention is paid to retrospective: what difficulties I encountered in the process of work, as I solved them. This can be useful as an educational material.

On the other hand, this cycle talks about how I prepared the library for publication: I researched licenses, dealt with CMake, with the world of open source software, and how it is common to design my projects in this world. This can also be useful to someone.

Well and, finally, yes, let my micro-library really be very limited in its possibilities in comparison with the existing bison of the C ++ reflection. But perhaps this is its advantage. The smaller the library, the easier it is for the user to become aware of the features of her work and the easier it is for her to integrate into the project. Need a heaped reflection - use a powerful library. We need a set of several simple features - you can try cpprt.

1. Why did I need this functionality

C ++ is known for its effectiveness. The code written on it comes out well optimized primarily due to the possibility of fine-tuning the use of computer resources. C ++ - really allows you to write very well optimized code. But you have to pay for it.

On the altar of efficiency, among other things, put the possibility of using some metadata during the execution of the program. Yes, there is RTTI with its typeid and dynamic_cast. There are Boost.TypeTraits . But RTTI is often turned off to save resources ( link about ), and Boost.TypeTraits, being a template-based library, is not particularly friendly with the logic of program execution time and generates a lot of service specializations of its templates.

However, sometimes it is impossible to do without the possibility of creating a class by its string name. For example, I needed such an opportunity within the framework of the serialization mechanism: for saving and loading objects stored by pointers to the parent class. Sounds maybe not very clear. I will explain in more detail.

Suppose we have a system for maintaining the state of class objects. Let its use look something like this:

//      ISerializable  //   ,    class ISerializable { virtual void save(Serializer *inSerializer) = 0; virtual void load(Deserializer *inDeserializer) = 0; } class Base : public ISerializable { virtual void save(Serializer *inSerializer) { /*     inSerializer */ } virtual void load(Deserializer *inDeserializer) { /*     inDeserializer */ } }; class Derived : public Base { virtual void save(Serializer *inSerializer) { /*     inSerializer */ } virtual void load(Deserializer *inDeserializer) { /*     inDeserializer */ } }; 

Test code that saves / loads data:

 Base *theBase = new Derived(); . . . Serializer theSerializer("save.txt"); theSerializer.save("name", theBase); theSerializer.flush(); . . . Deserializer theDeserializer("save.txt"); theBase = theDeserializer.load("name"); 

When saving an object stored by pointer to the parent class, the serializer will call the heir's save (...) method due to polymorphism. But when loading, the deserializer must somehow find out exactly what class the object had at the time of saving in order to be able to create it.

It follows that at the stage of saving you need to have a certain object class identifier, by which at the stage of loading we will be able to find out which class object you need to create and, using this identifier, through a certain API you can create an object of the required class.

The same thought in the form of code:

 class Serializer { void saveInt(const char *inName, int inValue) { ... } void saveString(const char *inName, const std::string &inValue) { ... } // . . . //      –    //  save( )       save(...) void saveObject(ISerializable *inObject) { inObject->save(this); } }; class Deserializer { int loadInt(const char *inName) { ... } void loadString(const char *inName, std::string &outValue) { ... } // . . . ISerializable *loadObject() { //     -  ,  //     –   ,  //    ISerializable *theObject = new < ??? >( ) theObject->load(this); return theObject; } }; 

Output: the code of methods for saving objects should be extended using some kind of API. Time to prototype!

 void saveObject(ISerializable *inObject) { //  ,     this->saveObjectType(inObject->classID()); // <<<--– classID() inObject->save(this); }; ISerializable *loadObject() { //         ISerializable *theObject = objectFabric().create( this->loadObjectType());// <<<--– objectFabric().create(...) theObject->load(this); return theObject; }; 

Throwing in this way the general view of the desired API, I took up the search for a solution that would provide similar functionality.

2. Search for a solution

For a start, I googled to find out what people think about the right behavior. I wanted something lightweight, without a thousand dependencies, without using auxiliary systems like Qt MOC (another article on the topic) and, among other things, easy to use. It was not possible to find a ready-made solution in the form of a library that meets the specified criteria.



I started to think how to implement similar functionality on my own.

Solutions, by and large, revolved around the description of factory functions and / or classes that were registered and used further through a mechanism that selected the right factory depending on the class name transferred. In this article, I decided to highlight this answeroverflow answer (by Johannes Schaub , thanks to him for the idea), since it embodies the main approaches found in the network.

The first idea proposed by Johannes Schaub implied the use of a template factory function and the preservation of its specializations in the dictionary. I didn’t really like the idea by itself - the mechanism looked somehow incomplete, without a beautiful object wrapper. However, some echoes of such an implementation can be found in the resulting final cpprt implementation (using factory classes).

The second idea from Johannes Schaub: the inclusion of the mechanism for registering factories in class constructors that [constructors] were invoked when creating static objects of these classes. I liked this idea, especially considering the proposed macros: the macros allowed to hide the details of the registration mechanism, due to which this mechanism could be changed from version to version of the library without side effects for code users.

I quote here the solution of Johannes Schaub with minimal changes and with my comments:



Johannes Schaub also proposed macros to simplify type registration. They allow you to close the features of the implementation of the registration system and make the code more concise:



I took the decision of Johannes Schaub as a basis, slightly changing it to your liking.

3. First implementation

The Johannes Schaub solution had a DerivedRegister template class, whose objects of specializations were created as static fields within the registered classes (static DerivedRegister reg). First of all, I decided to transfer factory functions to the DerivedRegister class as factory methods. Due to this, in addition to simplifying the code, it was possible to expand the meta information about the registered classes by simply adding fields to the DerivedRegister class.

I also transferred information about the string name of classes to my DerivedRegister counterpart, thus starting to use it as a repository of meta-information (so far only the string name of the class was used as meta-information).

There was, in fact, the implementation of the design pattern of an abstract factory with some frills for the possibility of executing the metadata registration code before the start of the main () function:



The variable globalRuntime is a global object that is dedicated to managing all meta-information machinery. In fact, just an object wrapper around a vector storing ClassManager specialization objects.

Consider the class code whose object is globalRuntime. I think the essence of his work will be clear without comment:





It remained to describe the base class IManagedClass (analogue of the Base class from the Johannes Schaub solution) and create macros to simplify the mechanism for registering classes.

In connection with the description of the base class IManagedClass, you should recall the API for which everything was started:

1. API for loading data . Ability to create an object by ID:
objectFabric (). create (inObjectID)
This is done by the globalRuntime.createObject ("ClassName") method.

2. API for saving data . Ability to get object class identifier:
object-> classID ()
The solution proposed by Johannes Schaub did not include a similar API. You have to implement it yourself .

I sketched the use case for inheriting IManagedClass using the example of a single class. I think that here, too, everything will be more or less clear without unnecessary comments:





I ran the code using this class, namely, the call to globalRuntime.createObject ("TestClass"). The object is safely created.

It remained to describe the macros that would remove from the user the need to manually make copy-paste code for registering classes:



Macro was ready. The principle of its use did not differ from the principles of using the macro proposed by Johannes Schaub:



Done! Trembling with impatience, I wrapped the described macros with a hierarchy of my classes, implemented serialization / deserialization methods using the newly created API, launched the code ...

Hooray! Objects are correctly saved and loaded, keeping their type! I tested everything thoroughly, saving objects of different classes. It worked! I didn’t expect that everything would start so easily at once ...

4. The first problems and the fight against them

... and I was absolutely right. Actually, in the written code there was one dangerous error. At some point - namely, when I added the next registered class - everything broke. Some classes stopped registering, and I couldn’t catch the sign on which the registration of classes fell off. Random of some kind. I spent half an hour of time moving from debug to logging and back. The ClassManager constructor for each class was called. Registration, respectively, took place ... But when it came to creating an object of a certain class globalRuntime.createObject (“SomeHellClass”), it turned out that there was no ClassManager for the class SomeHellClass in the array of registered class managers.

It took me a minute to think that one of the two of us was crazy: either I or C ++. And, as always, it turned out that I had lost my mind. Everything fell into place when I tried to add / delete sources for transfer to compilation. Each time the set of classes changed, the registration of which “fell off”. That is, it was in the order of compilation of the associates.

People who have carefully read the code, I think, have already understood the reason for the error.

Notice how the globalRuntime was defined:

 //--– CPPRuntime.h --- extern CPPRuntime globalRuntime; //--– CPPRuntime.cpp --- CPPRuntime globalRuntime; 

This is a global object. Not nested in a function and thus created at the time of the first function call, but simply a global object.

In this case, we recall the implementation of the ClassManager template class constructor, in which ClassManager objects of specialization register themselves within the globalRuntime object:

 //--– ClassManager.h --- ClassManager(const char *inClassName) : IClassManager(inClassName) { globalRuntime.registerClass(this); } 

And we also recall how objects of the ClassManager specializations are created (they are described via macros):

 #define CPPRT_DECLARATION(M_ClassName)\ public:\ static ClassManager< M_ClassName > gClassManager;\ virtual IClassManager *getClassManager() { return &gClassManager; }\ protected:\ #define CPPRT_IMPLEMENTATION(M_ClassName)\ ClassManager< M_ClassName > M_ClassName::gClassManager(#M_ClassName); 

ClassManager specialization objects (for example, SomeHellClass :: gClassManager object) are also global variables! .. They must be global variables: it’s important that a constructor be executed for each such object before running main (), otherwise the registration of such objects will not be performed.

And now let's remember: in what order are the constructors of global and static variables in C ++ called? .. Yes, that's right. In random order ( stackoverflow , quotation from the Standard is also available there). What follows from this?

And this implies the possibility that the constructor of the globalRuntime object can be called after the constructors of any ClassManager specializations have been called. The situation is very bad: in the object constructors of the ClassManager specializations (objects with the names gClassManager), the methods of an object that has not yet been created (globalRuntime) can be accessed. This behavior could lead to some kind of stall, but did not lead - which is even worse in this case. Typical undefined behavior.

Do not do this. Never.



Fixing the problem was obvious: for correct access to the object, it was necessary to implement one of the variations of the singleton Meyers (a more detailed article on singletons can be found there and about this singleton):

extern CPPRuntime globalRuntime;

 //--– CPPRuntime.h --- CPPRuntime &globalRuntime(); 

CPPRuntime globalRuntime;

 //--– CPPRuntime.cpp --- CPPRuntime &globalRuntime() { // , ,      ,  //        –     // header only . ,   thread safe... static CPPRuntime sCPPRuntime; return sCPPRuntime; } 

Access through the function provides guaranteed creation of an object of the CPPRuntime class at any time, from anywhere in the code.

After fixation, all that remained was to make a change to the ClassManager specialization constructor, which accessed the CPPRuntime class object:

 ClassManager(const char *inClassName) : IClassManager(inClassName) { //     CPPRuntime  , //   globalRuntime() globalRuntime().registerClass(this); } 

I drove a good code through different hierarchies of objects, changing the list of sources sent for compilation - in order to verify exactly that now everything is fine.

Everything was really good.

As time went on, the main library lived its own life, developed. And at some point a new functional was needed ...

5. Genealogy of classes

At some point it became necessary to collect information about the heirs of classes during the execution of the program. I will not go into details, why exactly this was needed - I’ll tell you about it sometime when the time comes to publish the main library. In order to have a more substantive conversation, suppose that this was necessary for debugging purposes: for the convenience of viewing information about registered classes for especially large projects.

boost (is_base_of) compile time ( is_base_of API boost).

, … !



API - :

 std::vector< IClassManager * > theChildManagers; //      ClassManager // (       IClassManager) //  -  BaseClass. globalRuntime(IClassManager).getChildren(BaseClass::gClassManager, theChildManagers); //     –   // -  BaseClass: std::cout << "Children of class " << BaseClass::gClassManager.name() << std::endl; for (size_t theIndex = 0, theSize = theChildManagers.size(); theIndex < theSize; ++theIndex) { std::cout << theChildManagers[theIndex]->name() << std::endl; } 

, API, , .

API , , API .

: ClassManager ClassManager . :



:



CPPRuntime , ClassManager. , :




- ( inRegistry->_childs CPPRuntime:: getClassRegistries_internal). ClassManager _children, friend . , , :



friend . , — .

. , / . : … _parents , _children – . ?

: . ClassManager:



ClassManager ( &M_BaseClass0::gClassManager ) ClassManager ( M_Class::gClassManager ), setParent(...):



ClassManager … ClassManager , !

.

. . , globalRuntime(), ClassManager , . : ClassManager . gClassManager SomeHellClass, , SomeHellClass, .



, , ClassManager , , ClassManager , CPPRuntime.

, , , ClassManager. main() , dynamic initialization . , - .

, : , , , , . , , ClassManager – :





, , , , (, ).

– – - gClassManager. , , :



. 3.6.2 . : stackoverflow , (, , PDF, 3.6.2 ).

Variables with static storage duration (3.7.1) or thread storage duration (3.7.2) shall be zero-initialized (8.5) before any other initialization takes place

, ():

 getPointer() { //  ,    ,  //  zero-value ,  //    ,   if (!Class::gPointer) { Class::gPointer = initializeValue(); } return Class::gPointer; } Class::gPointer = getPointer(); 

, . ClassManager CPPRuntime, CPPRuntime .

450 .

6. Conclusion

:
1. «» bitbucket. GitHub. .
2. GitHub — , CMake ( ).

, . . Thanks for attention!

,