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

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





Ссылка на репозиторий библиотеки
То, что излагается в данной статье, верно для коммита e9c34bb.

Сборка библиотеки и сопроводительных материалов

О том, как создавалась система сборки для проекта, можно почитать во второй статье цикла (ссылка).

Рекомендуемый способ сборки самой библиотеки и сопроводительных материалов подразумевает использование CMake. Если у вас не установлен CMake, можете скачать его отсюда.

Для сборки через командную строку нужно выполнить следующие действия:

1. Создать где-нибудь, где вам удобно, папку, в рамках которой вы будете осуществлять сборку. Перейти в эту папку:
mkdir {your-build-folder}
cd {your-build-folder}
{your-build-folder} — папка, в которой вы будете выполнять сборку.

2. Вызывать команду для генерации конфигурации:
cmake -G "{generator-name}" {options} {cpprt-folder-path}
{generator-name} — имя генератора для вашего тучлейна.
{options} — перечень опций для указания того, что именно вы желаете собирать.


{cpprt-folder-path} — папка, которая является корнем клона репозитория cpprt.

После вызова в папке {your-build-folder} образуются конфигурационные файлы для вашего тулчейна (либо для вашей IDE). Дальше ничего настраивать не нужно. Достаточно просто запустить сборку нужных целей сборки (проектов для IDE).

Возможности библиотеки

С помощью API, предоставляемого библиотекой cpprt, класс может быть зарегистрирован. Если класс зарегистрирован, то для него открываются следующие возможности:
1. Создание объекта класса во время исполнения программы на основании имени класса в строковом представлении.
2. Доступ к информации о зарегистрированных наследниках и предках класса (в меру переданной при регистрации информации).
3. Возможность получать информацию об абстрактности классов.
4. Возможность получать строковое имя класса через методы его объектов.

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



Примеры использования API для взаимодействия с метаданными:

1.Создание объекта по строковому имени его класса:

ICPPRTManagedClass *theTestClassObject = cppRuntime().createObject(“TestClass”);

2. Распечатка информации об абстрактности класса по указателю на объект базового класса:

void printObjectClassInformation(ICPPRTManagedClass *inObject) {
	const CPPRTRuntime::ClassData &theClassData = *inObject->getClassDataRT();
	std::cout << “Class ” << theClassData.fullName() << “ is ”
			<< theClassData.isInterface() ? “abstract” : “concrete” << std::endl;
}

3. Распечатка имён всех классов-наследников класса TestClass. При этом выбираются и наследники наследников рекурсивно, фильтруются абстрактные классы и в получаемый перечень не добавляется метаинформация для самого класса TestClass:

std::vector<CPPRTClassData *> theChildData;
cppRuntime().observeChildren(TestClass::gClassData, theChildData,
		ObservingFlagWithoutInterface |
		ObservingFlagRecursive |
		ObservingFlagIgnoreBase);

for (size_t theIndex = 0, theSize = theChildData.size(); theIndex < theSize; ++theIndex) {
	std::cout << theChildData[theIndex]->fullName() << std::endl;
}

4. Распечатка имён всех классов, не имеющих предков:

std::vector<CPPRTClassData *> theBasesData;
cppRuntime().observeChildren(NULL, theBasesData);

for (size_t theIndex = 0, theSize = theBasesData.size(); theIndex < theSize; ++theIndex) {
	std::cout << theBasesData [theIndex]->fullName() << std::endl;
}

Регистрация классов

Теперь разберёмся с тем, что необходимо для регистрации классов:

1. Регистрируемый класс должен иметь в предках класс ICPPRTManagedClass; достаточно чтобы базовый класс пользовательской иерархии наследовал ICPPRTManagedClass. Пример:

// UserClasses.h

// Базовый класс иерархии объектов пользователя.
// Наследует ICPPRTManagedClass.
class UserBaseClass : public ICPPRTManagedClass {
. . . // <- Декларация класса, о ней дальше
};

// Так как UserBaseClass наследует ICPPRTManagedClass,
// UserInheritedClass не должен наследовать ICPPRTManagedClass.
class UserInheritedClass : public UserBaseClass { 
. . . // <- Декларация класса, о ней дальше
};

2. Регистрированный класс должен обладать методами и полями, которые используются библиотекой cpprt для работы. Чтобы не писать их вручную, лучше воспользоваться макросами для регистрации. Есть две группы макросов: для декларации необходимых полей и методов, и для реализации.

Декларация. CPPRT_DECLARATION – макрос для декларации. Принимает один аргумент – имя класса, который регистрируется (не строка с именем, а само имя). Код, в который раскрывается макрос, заканчивается спецификатором доступа protected. Это сделано для более простого включения макроса в существующий код, ведь если использовать макрос в начале декларации класса, то доступ для всех последующих декларируемых членов класса останется таким же, как без использования макроса (так как в С++ до объявления другого спецификатора доступа декларируемые члены класса имеют protected доступ). Пример:

// UserClasses.h

class UserBaseClass : public ICPPRTManagedClass {
	// Что с макросом, что без, все следующие
	// декларируемые члены класса имеют
	// спецификатором доступа protected.
	CPPRT_DECLARATION(UserBaseClass)

. . . // <- прочие декларации членов класса
};

class UserInheritedClass : public UserBaseClass {
	// В декларации для наследника не нужно
	// указывать базовый класс – только имя
	// данного класса
	CPPRT_DECLARATION(UserInheritedClass)

. . . // <- прочие декларации членов класса
};

Реализация. Основная часть метаинформации о классе передаётся в рамках макроса реализации. Эти макросы делятся на группы в зависимости от количества базовых классов.

CPPRT_CLASS_IMPLEMENTATION_BASE_{N}(C, B1, …, BN)
CPPRT_INTERFACE_IMPLEMENTATION_BASE_{N}( C, B1, …, BN)
N – количество базовых классов.
C – полное имя класса, для которого описывается реализация.
B1 … BN – полные имена базовых классов. Эти классы должны быть зарегистрированы в рамках cpprt.

Макрос с CLASS используется для регистрации классов, объекты которых можно создавать, а с INTERFACE – для регистрации абстрактных классов. Пример:

// UserClasses.cpp

CPPRT_CLASS_IMPLEMENTATION_BASE_0(UserBaseClass);
CPPRT_CLASS_IMPLEMENTATION_BASE_1(UserInheritedClass, UserBaseClass);

Собственно, всё. Описанных вещей достаточно для регистрации класса в рамках cpprt. Живой пример вы можете посмотреть в рамках репозитория (цель сборки simple_example, опция -DBUILD_EXAMPLES={OFF/ON} для генерации проекта через CMake).

Здесь тоже приведу пример для регистрации более сложной иерархии классов, иерархия наследования классов для какого-нибудь типичного шутера:

Прочие возможности

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

// Dog.h

class Dog : public Mammal, public ISerializable {
	CPPRT_DECLARATION(Dog)
. . .
};

// Dog.cpp

// ISerializable не указывается среди базовых классов для Dog
// во время регистрации. Это может быть служебный интерфейс,
// о котором нет смысла знать при оперировании с метаданными
// классов. В таком случае ISerializable вообще не имеет смысла
// регистрировать.
CPPRT_CLASS_IMPLEMENTATION_BASE_1(Dog, Mammal)

Console tool

Вместе с библиотекой, помимо примера, в поставке идёт инструмент консоль (console). Он предоставляет несколько команд для создания объектов по строковому имени их классов (объекты хранятся в тестовом массиве), а также для просмотра иерархий наследования для регистрированных классов. Короткое описание команд, поддерживаемых консолью:

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

print (-c) ({full-class-name})
Если данная команда вызывается без аргументов, то она распечатывает перечень всех созданных в данный момент объектов с указанием их классов.
Если передан флаг -c (необязательный флаг), но при этом не передано имя класса (необязательный параметр {full-class-name}), то данный вызов распечатает деревья зарегистрированных классов-наследников для всех зарегистрированных классов, не имеющих базовых классов (корневых классов).
Если помимо флага -c передан параметр {full-class-name}, задающий имя класса, то данная команда распечатает дерево зарегистрированных классов-наследников для класса с переданным именем.

create {class-name} {object-name}
Команда, создающая объект зарегистрированного класса {class-name} с именем {object-name} в тестовом массиве объектов.

delete {object-name}
Команда, удаляющая объект из тестового массива объектов по его имени.

exit
Команда для выхода из консоли. Завершает исполнение программы консоли.

Пожалуй, я рассказал всё про возможности использования библиотеки. Если хочется узнать как это все реализовано — о большей части приёмов и трюков, которые были использованы в библиотеке, я подробно рассказал в первой статье цикла (ссылка). Её прочтения достаточно для понимания принципов работы библиотеки.

Планы на будущее

1. Реализовать возможность обхода дерева наследования не только от предков к наследникам, но и наоборот.



Данная фича реализуема элементарно в рамках текущей реализации – нужно сделать internal-методы для обхода наследников шаблонными, с булевым аргументом ObserveChildren, в зависимости от значения true/false которого выбирать метаданные наследников/базовых классов для переданных метаданных.

2. Наладить нормальную инкапсуляцию данных для классов библиотеки. При текущем дизайне библиотеки наружу торчат много лишних типов и методов (например, у того же класса CPPRTRuntime) которые загромождают пользовательский интерфейс библиотеки.

3. Сделать итераторы для возможности обходить дерево метаинформации для классов. Это позволит экономить использование данных при рекурсивном обходе дерева наследников и даст пользователю самому выполнять обход дерева наследования классов без нарушения инкапсуляции.



В качестве альтернативы итератору можно использовать шаблон проектирования visitor (например, как это сделано в clang, вот большой пример использования). Этот подход вообще часто используется для обхода древовидных структур данных.

4. Сделать возможность добавления пользовательской информации к классам – чтобы можно было фильтровать классы по этим данным при запросе.



4. Сделать поддержку шаблонов. Вот это весьма нетривиальная задача. Нужно хорошо думать по поводу того, действительно ли нужно (скорее всего, нужно) и как вообще можно описать API для использования шаблонозависимых классов.

5. Подумать о возможности работы с метаданными классов в runtime. Например, регистрация класса в runtime, либо наоборот – удаление классов из списка регистрированных.



В принципе, подобный функционал доступен уже сейчас, но это, скорее, баг дизайна, чем фича… Вообще, вероятно, данная фича опасна и стоит хорошо подумать, нужна ли она вообще.

6. Место для ваших предложений. Предлагайте, что ещё может быть полезным. Обсудим.

Заключение статьи и заключение цикла

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

Ну и будет неплохо также, если кто-нибудь, заинтересовавшись, внесёт свой вклад в развитие библиотеки cpprt.



Спасибо что дочитали всё это! Надеюсь, мне удалось рассказать хоть что-нибудь полезное!

Автор заранее благодарит читателей за указания на ошибки в статье, конструктивные советы и пожелания.