Капелька рефлексии для С++. Часть первая: ретроспектива разработки20.04.2016 08:18

Создавать объекты по строковым именам их классов и получать информацию о наследниках классов во время исполнения программы. С++ либо не поддерживает, либо слабо поддерживает подобный функционал «из коробки».

В этом цикле статей будет я подробно рассказываю о том, как создавал свою микро-библиотеку, реализующую подобное поведение и как готовил её к публикации.

Моя совесть не будет чиста, если я не признаюсь в одной хитрой мысли, которая подтолкнула меня написать данный цикл статей. Так как это касается, скорее, маркетинга, я использую прятки под кат. Предупреждаю: там достаточно много текста.

Данный цикл статей состоит из трёх частей:

Первая часть, ретроспективная. В ней подробно излагается история разработки микро-библиотеки.
Зачем читать: Данная часть предназначена для людей, которым интересно, какие шишки можно набить в процессе написания кода для регистрации информации о классах до старта функции main (). Серьёзным программистам С++ эта часть может показаться наивной и не интересной.

Вторая часть, публикационная. Рассказывает о подготовке репозитория библиотеки к публикации: выбор лицензии, организация структуры репозитория, изучение CMake, и т.д.
Зачем читать: Данная часть может быть полезна людям, у которых пылится на диске своя библиотека и которые хотят узнать, как можно представить эту библиотеку людям.

Третья часть, документационная. Здесь даётся взгляд на библиотеку с позиции пользователя: основные use cases использования, механизм регистрации классов, API для создания объектов по строковым именам классов, API для доступа к информации о наследованных классах через указание родительского класса во время исполнения программы. Эта часть содержит примеры кода, а также планы на будущее.
Зачем читать: Данная часть может быть полезна людям, желающим получить предоставляемый cpprt функционал в своём проекта, а также, снова, для желающих внести свою лепту в развитие библиотеки и, возможно даже, в развитие «основной библиотеки».

За сим я заканчиваю о цикле, и перехожу к сути конкретно данной статьи.

0. Вступление

Структура данной статьи:

Раздел №0. Данный раздел. Здесь рассказывается об аналогах библиотеки cpprt и даются некоторые мысли по поводу того, почему cpprt имеет право на существовании при наличии серьёзных аналогов.
Раздел №1. Зачем вообще понадобилась рефлексия в С++.
Раздел №2. Про поиск решения для возникшей задачи.
Раздел №3. Про первую реализацию механизма регистрации классов.
Раздел №4. Про то, какие проблемы имелись в первом решении о том, как я их исправлял.
Раздел №5. Добавление возможности регистрировать информацию о наследовании.
Раздел №6. Заключение.

И теперь, наконец, начинаем разговор.

На момент публикации данного цикла статей моя библиотека позволяет очень немного:
1. Создавать объекты по строковому имени их классов.
2. Получать информацию о наследниках классов в runtime.

Уже при работе над статьёй знакомый подкинул ссылку вот на этот обзор существующих библиотек. В нём упомянуты действительно мощные проекты. Они позволяют оснащать классы С++ толстенным слоем метаинформации и связанного с этим функционала: создавать объекты по строковым именам классов, получать перечень полей и методов классов во время исполнения программы, вызывать эти методы… Короче, позволяют купаться в целых океанах метаинформации. Мои достижения казались ничтожными в тени конкурентов. Однако, чуть успокоившись, я подумал: возможно, определённый смысл рассказать о проделанной мною работе есть.

Во-первых, в данных статьях много внимания уделяется ретроспективе: с какими трудностями я сталкивался в процессе работы, как я их решал. Это может быть полезно в качестве учебного материала.

С другой стороны, данный цикл рассказывает о том, как я готовил библиотеку к публикации: исследовал лицензии, разбирался с CMake, с миром открытого ПО и с тем, как принято оформлять свои проекты в этом мире. Это тоже может кому-нибудь пригодиться.

Ну и, наконец, да, пусть моя микро-библиотека действительно очень ограничена в возможностях по сравнению с существующими зубрам рефлексии С++. Но, возможно, в этом заключается её преимущество. Чем меньше библиотека — тем легче пользователю осознать особенности её работы и тем легче её интеграция в проект. Нужна навороченная рефлексия — используйте мощную библиотеку. Нужен набор из нескольких простых возможностей — можно попробовать cpprt.

1. Зачем мне понадобился подобный функционал

С++ известен своей эффективностью. Код, написанным на нём, выходит хорошо оптимизированным прежде всего возможно благодаря возможности тонкой настройки использования ресурсов компьютера. С++ — действительно позволяет писать очень хорошо оптимизированный код. Но за это нужно платить.

На алтарь эффективности, помимо всего прочего, кладётся возможность использования некоторых метаданных во время исполнения программы. Да, есть RTTI с его typeid и dynamic_cast. Есть Boost.TypeTraits. Но RTTI часто отключают для экономии ресурсов (ссылка по поводу), а Boost.TypeTraits, будучи библиотекой, построенной на шаблонах, не особо дружит с логикой времени исполнения программы и порождает много служебных специализаций своих шаблонов.

При этом иногда без возможности создания класса по его строковому имени не обойтись. Мне, например, такая возможность понадобилась в рамках механизма сериализации: для сохранения и загрузки объектов, хранящихся по указателям на родительский класс. Звучит, возможно, не очень понятно. Объясню подробнее.

Пусть у нас есть система для сохранения состояния объектов классов. Пусть использование её выглядит как-нибудь так:

// В рамках реализуемой схемы интерфейс 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 */ }
};

Тестовый код, который сохраняет/загружает данные:

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

При сохранении объекта, хранящегося по указателю на родительский класс, сериализатор вызовет метод save (…) наследника за счёт полиморфизма. Но при загрузке десериализатор должен как-нибудь узнать, какой именно класс был у объекта в момент сохранения, чтобы иметь возможность создать его.

Отсюда следует, что на этапе сохранения нужно иметь некий идентификатор класса объекта, по которому на этапе загрузки мы сможем узнать, объект какого класса нужно создать и, воспользовавшись этим идентификатором, через некое API создать объект нужного класса.

Эта же мысль в виде кода:

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;
        }
};

Вывод: код методов для сохранения объектов должен быть расширен с использованием какого-нибудь API. Время прототипировать!

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;
};

Накидав таким образом общий вид нужного API, я взялся за поиск решения, которое предоставляло бы подобный функционал.

2. Поиск решения

Для начала я погуглил, чтобы узнать, что по поводу нужного поведения думают люди. Хотелось чего-то легковесного, без тысячи зависимостей, без использования вспомогательных систем вроде Qt MOC (ещё статья на тему) и, помимо всего прочего, простого в использовании. Найти готовое решение в виде библиотеки, удовлетворяющей заданным критериям, не удалось.

Я начал думать, как реализовать подобный функционал самостоятельно.

Решения, в общем и целом, крутились вокруг описания фабричных функций и/или классов, которые регистрировались и использовались дальше через некий механизм, который выбирал нужную фабрику в зависимости от переданного имени класса. В рамках данной статьи я решил выделить вот этот ответ на stackoverflow (авторства Johannes Schaub, спасибо ему за идею), так как в нём воплотились основные подходы, найденные в сети.

Первая идея, предложенная Johannes Schaub, подразумевала использование шаблонной фабричной функции и сохранение её специализаций в словаре. Идея сама по себе мне не очень понравилась — механизм выглядел как-то незавершённо, без красивой объектной обёртки. Тем не менее, некоторые отголоски подобной реализации можно обнаружить в получившейся финальной реализации cpprt (использование фабричных классов).

Вторая идея от Johannes Schaub: включение механизма регистрации фабрик в конструкторы классов, которые [конструкторы] вызывались при создании статических объектов этих классов. Эта идея мне понравилась, особенно с учётом предложенных макросов: макросы позволяли скрывать детали механизма регистрации, за счёт чего этот механизм можно было бы менять от версии к версии библиотеки без побочных эффектов для пользователей кода.

Привожу здесь решение Johannes Schaub с минимальными изменениями и со своими комментариями:

// in base.hpp:

// Шаблонная фабричная функция. Создаёт объект произвольного типа.
// Здесь упоминается некий класс Base, который Johannes, как я понимаю,
// рассматривает в качестве базового для всех регистрируемых классов.
// В принципе, из фабричной функции можно было бы возвращать указатель 
// на void, обобщив, таким образом, решение.
// Но если выделить некий базовый регистрируемый класс Base, то можно
// сделать механизм регистрации типов более удобным
|| (о чём будет рассказано дальше).
template< typename T > Base * createT() { return new T; }

// Базовый класс для "регистраторов" фабричных функций
struct BaseFactory {

        // Словарь, с помощью которого мы сможем получать указатель
        // на специализацию фабричной функции по строковому имени
        // класса. Такой словарь можно создать за счёт того, что все
        // специализации функции createT имеют одинаковую сигнатуру
        // (возвращают одинаковый тип и отличаются только реализацией).
        typedef std::map< std::string, Base*(*)() > map_type;

        // Метод для создания объектов по строковым именам их
        // классов... Думаю, тут всё и так ясно.
        static Base *createInstance(std::string const& s) {
                map_type::iterator it = getMap()->find(s);
                return (it == getMap()->end()) ? NULL : it->second();
        }

protected:
        // Этот метод, а также следующий указатель-статическая
        // переменная map реализуют вместе шаблон синглтон. В этом
        // синглтоне хранится глобальный словарь, связывающий
        // фабричные функции со строковыми именами.
        static map_type * getMap() {
                // Комментарий Johannes Schaub:
                // never delete'ed. (exist until program termination)
                // because we can't guarantee correct destruction order 
                if(!map) { map = new map_type; } 
                return map; 
        }

private:
        static map_type * map;
};

// Класс, в конструкторе связывающий специализацию фабричной
// функции со строковым именем. Фактически, вызов конструктора
// данного класса – это всё, что нужно, чтобы для класса T можно было
// выполнять конструирование объектов по строковому имени класса.
template< typename T >
struct DerivedRegister : BaseFactory { 
        DerivedRegister(std::string const& s) { 
                getMap()->insert(std::make_pair(s, &createT< T >));
        }
};

// in derivedb.hpp

// Тестовый класс, который регистрируется через механизм,
// созданный Johannes Schaub. Насколько я понимаю, Johannes Schaub
// забыл унаследовать его от Base. Я исправил это:
class DerivedB : public Base {
        ...;
private:

        // Здесь мы имеем предекларацию статической переменной reg.
        static DerivedRegister< DerivedB > reg;
};

// in derivedb.cpp:

// Здесь (в файле, где расположена реализация класса DerivedB)
// описывается сама статическая переменная, в конструкторе которой
// выполняется связывание фабричного метода со строковым именем.
// Во время статической инициализации будет вызван конструктор
// специализации DerivedRegister< DerivedB > и пройдёт связывание
// фабричной функции с именем DerivedB
DerivedRegister< DerivedB > DerivedB::reg("DerivedB");

Johannes Schaub предложил также макросы для упрощения регистрации типов. Они позволяют закрыть особенности реализации системы регистрации и делают код лаконичнее:

#define REGISTER_DEC_TYPE(NAME) \
        static DerivedRegister reg

#define REGISTER_DEF_TYPE(NAME) \
        DerivedRegister NAME::reg(#NAME)

Я взял решение Johannes Schaub за основу, чуть изменив его по своему вкусу.

3. Первая реализация

В решении Johannes Schaub имелся шаблонный класс DerivedRegister, объекты специализаций которого создавались как статические поля в рамках регистрируемых классов (static DerivedRegister reg). Первым делом я решил перенести фабричные функции в класс DerivedRegister в качестве фабричных методов. За счёт этого, помимо упрощения кода, появлялась возможность расширять метаинформацию о регистрируемых классах простым добавлением полей в класс DerivedRegister.

Также я перенёс информацию о строковом имени классов в свой аналог DerivedRegister, начав таким образом использовать его, как хранилище метаинформации (пока в качестве метаинформации выступало только строковое имя класса).

Вышла, фактически, реализация шаблона проектирования абстрактная фабрика с кое-какими наворотами для возможности выполнения кода регистрации метаданных до старта функции main ():

// Обобщённый менеджер классов (аналог DerivedRegister из решения
// Johannes Schaub). Содержит в себе типичную для любого класса
// метаинформацию. Требует от наследников реализовывать фабричный
// метод createAbstractObject()
//
class IClassManager {
private:
        const char *_name;

public:
        IClassManager(const char *inClassName) : _name(inClassName) { }

        //-– Workflow
        const const char *name() const { return _name; }
        virtual IManagedClass *createAbstractObject() = 0;
};

//-----------------------------------------------------------------
// Реализация менеджера классов. Реализует фабричный
// метод и берёт на себя задачу регистрации самого себя
// в системе регистрации метаинформации о классах.
// Регистрация выполняется в рамках конструктора.
template
class ClassManager : public IClassManager {
public:
        // Регистрация фабрики выполняется, как и в коде
        // Johannes Schaub, вот тут, в конструкторе:
        ClassManager(const char *inClassName) : IClassManager(inClassName) {
                globalRuntime.registerClass(this);
        }

        T_Type *createObject() { return new T_Type(); }
        virtual IManagedClass *createAbstractObject() { return createObject(); }
};

Переменная globalRuntime — это глобальный объект, который выделен для управления всей метаинформационной машинерией. Фактически, просто объектная обёртка вокруг вектора, хранящего объекты специализаций ClassManager.

Рассмотрим код класса, объект которого — это globalRuntime. Думаю, суть его работы будет ясна без комментариев:

class CPPRuntime {
private:
        std::vector< IClassManager * > _registries;

        IClassManager *managerByName(const char *inName);

public:
        CPPRuntime() : _registries() { }

        void registerClass(IClassManager *inClass);
        IManagedClass *createObject(const char *inClassName);
};

//-----------------------------------------------------------------------------
extern CPPRuntime globalRuntime;

IClassManager *CPPRuntime::managerByName(const char *inName) {
        for (size_t theIndex = 0, theSize = _registries.size();
                        theIndex < theSize; ++theIndex)
        {
                if (0 == strcmp(_registries[theIndex]->name(), inName)) {
                        return _registries[theIndex];
                }
        }
        return NULL;
}

//-– Registering
void CPPRuntime::registerClass(IClassManager *inClass) {
        _registries.push_back(inClass);
}

//-– Public API
IManagedClass *CPPRuntime::createObject(const char *inClassName) {
        IClassManager *theRegistry = managerByName(inClassName);
        //TODO: Through an exception if no class found
        return theRegistry->createAbstractObject();
}

//-----------------------------------------------------------------------------
CPPRuntime globalRuntime;

Оставалось описать базовый класс IManagedClass (аналог класса Base из решения Johannes Schaub) и создать макросы для упрощения механизма регистрации классов.

В связи с описанием базового класса IManagedClass, следует вспомнить API, ради которого всё затевалось:

1. API для загрузки данных. Возможность создавать объект по идентификатору:
objectFabric ().create (inObjectID)
Это готово, метод globalRuntime.createObject («ClassName»).

2. API для сохранения данных. Возможность получать идентификатор класса объекта:
object→classID ()
Решение, предложенное Johannes Schaub, не включало в себя подобное API. Его придётся реализовывать самостоятельно.

Я набросал use case для наследования IManagedClass на примере одного класса. Думаю, тут тоже все будет более или менее ясно без лишних комментариев:

//---------------------------------------------------------------------------------------------------
// Базовый класс, с которым взаимодействует разрабатываемая система.
// Задаёт принципы получения метаинформации для объектов всех
// регистрируемых классов.
class IClassManager {
public:
        virtual IClassManager *getRegistry() = 0;
};

//---------------------------------------------------------------------------------------------------
// Класс пользователя, наследующий базовый класс. Пользователь должен
// наследовать базовые классы своих иерархий от базового класса чтобы
// иметь возможность привязывать в ним метаданные и получить доступ
// к метаданным во время исполнения программы.
class TestClass : public IClassManager {
public:
        // Служебный код для регистрации класса. Его стоит закрыть за макросом.
        static ClassManager< TestClass > gClassManager; 
        virtual IClassManager *getRegistry() { return &gClassManager; }
public:
};

// Вызов конструктора объекта gClassManager должен зарегистрировать
// фабрику для создания экземпляров класса TestClass по строковому
// имени этого класса. Данный код тоже стоило бы закрыть за макросом.
ClassManager< TestClass > TestClass::gClassManager("TestClass");

Я запустил код с использованием этого класса, а именно, отдебажил вызов globalRuntime.createObject («TestClass»). Объект благополучно создался.

Оставалось описать макросы, которые сняли бы с пользователя необходимость вручную делать копи-пасту кода для регистрации классов:

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

// Что приятно, это решение будет работать в том числе для классов, вложенных в namespace.
#define CPPRT_IMPLEMENTATION(M_ClassName) ClassManager< M_ClassName > M_ClassName::gClassManager(#M_ClassName);

Макрос был готов. Принцип его использования не отличался от принципов использования макроса, предложенного Johannes Schaub:

//--– TestClass.h ---
class TestClass : public IClassManager {
        // Этот макрос лучше всего прописывать в начале декларации
        // класса – чтобы гарантированно не поменять спецификатор
        // доступа, задаваемый в начале декларации классов как protected
        CPPRT_DECLARATION(TestClass)
. . .
};

//--– TestClass.cpp ---
CPPRT_IMPLEMENTATION(TestClass)

Готово! Дрожа от нетерпения, я обвязал описанными макросами иерархию своих классов, реализовал методы сериализации/десериализации с использованием свежесозданного API, запустил код…

Ура! Объекты корректно сохранялись и загружались, сохраняя свой тип! Я хорошенько всё оттестировал, сохраняя объекты разных классов. Работало! Совершенно не ожидал, что сходу всё так просто заведётся…

4. Первые проблемы и борьба с ними

… и я был совершенно прав. На самом деле, в написанном коде была одна опасная ошибка. В какой-то момент –, а именно, когда я добавил очередной зарегистрированный класс — всё поломалось. Некоторые классы перестали регистрироваться, причём признак, по которому отваливалась регистрация классов, я уловить не мог. Рандом какой-то. Я потратил полчаса времени, переходя с дебага на логирование и обратно. Конструктор ClassManager для каждого класса вызывался. Регистрации, соответственно, проходили… Но когда дело доходило до создания объекта некоего класса globalRuntime.createObject («SomeHellClass»), то оказывалось, что в массиве зарегистрированных менеджеров классов отсутствует ClassManager для класса SomeHellClass.

Минут тридать мне казалось, что кто-то из нас двоих сошёл с ума: либо я, либо С++. И, как всегда, выяснилось, что с ума сошёл всё-таки я. Всё стало на свои места, когда я попробовал добавлять/удалять исходники для передачи их на компиляцию. Каждый раз при этом менялся набор классов, регистрация которых «отваливалась». То есть дело было в порядке компиляции исподников.

Люди, которые внимательно читали код, думаю, уже поняли в чём причина ошибки.

Обратите внимание на то, как был определён globalRuntime:

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

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

Это глобальный объект. Не вложенный в функцию и создаваемый, таким образом, в момент первого вызова функции, а просто глобальный объект.

При этом вспомним реализацию конструктора шаблонного класса ClassManager, в котором объекты специализации ClassManager регистрируют самих себя в рамках объекта globalRuntime:

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

И вспомним ещё, как создаются объекты специализаций ClassManager (они описываются через макросы):

#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 (например, объект SomeHellClass: gClassManager) тоже являются глобальными переменными!… Должны являться глобальными переменными: ведь важно, чтобы для каждого такого объекта выполнялся конструктор до запуска main (), иначе не будет выполняться регистрация таких объектов.

А теперь вспомним: в каком порядке вызываются конструкторы глобальных и статических переменных в С++?… Да, верно. В произвольном порядке (stackoverflow, цитата из Стандарта там тоже имеется). Что же из этого следует?

А из этого следует возможность того, что конструктор объекта globalRuntime может вызываться после того, как вызвались конструкторы каких-либо специализаций ClassManager. Ситуация очень нехорошая: в конструкторах объектов специализаций ClassManager (объекты с именами gClassManager) может происходить обращение к методам объекта, который ещё не было создан (globalRuntime). Такое поведение могло привести к какому-нибудь свалу, но не приводило — что ещё хуже в данном случае. Типичный undefined behavior.

Не делайте так. Никогда.

Фикс проблемы был очевиден: для корректного доступа к объекту нужно было реализовать одну из вариаций синглтона Мейерса (более подробная статья о синглтонах, там можете найти и про этот синглтон):

extern CPPRuntime globalRuntime;

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

CPPRuntime globalRuntime;

//--– CPPRuntime.cpp ---
CPPRuntime &globalRuntime() {
        // Да, знаю, такой подход не дружит с многопоточностью, но
        // это пока не критично и легко исправляется – ведь у нас не
        // header only код. Пулреквестните, если желаете thread safe...
        static CPPRuntime sCPPRuntime;
        return sCPPRuntime;
}

Доступ через функцию обеспечивает гарантированное создание объекта класса CPPRuntime в любой момент времени, из любого места в коде.

После фикса оставалось только внести изменение в конструктор специализаций ClassManager, в котором осуществлялся доступ к объекту класса CPPRuntime:

ClassManager(const char *inClassName)
        : IClassManager(inClassName)
{
        // Теперь обращаемся к объекту CPPRuntime безопасным путём,
        // через функцию globalRuntime()
        globalRuntime().registerClass(this);
}

Я хорошенько погонял код по разным иерархиям объектов, изменяя перечень исходников, отправляемых на компиляцию — чтобы точно проверить, что теперь-то уж всё хорошо.

Вс

© Habrahabr.ru