𝐑𝐨𝐨𝐭𝐓𝐨𝐨𝐥 𝐁𝐥𝐨𝐠

Экстравагантное использование препроцессора для избежания виртуализации

Когда я говорил про гибкость С++, я в буквальном смысле имел ввиду - С++ очень гибкий. И недавное, чисто обдумывая препроцессинг, мой мозг заметил одну интересную вещь....

Представим задачу с реверсивной зависимостью:

// RenderInterface.h

class IRender 
{
  virtual void SetupScreen();
  
  virtual void ClearScreen();
  virtual void UpdateScreen();
};

И потом где-то, где-то далеко, мы реализуем:

// OpenGLRender.h

class ROpenGLRender : IRender
{
  virtual void SetupScreen() override;
  
  virtual void ClearScreen() override;
  virtual void UpdateScreen() override;
};

^ В целом неплохо, да? Но что меня, как Ардуинщика, смущает - виртуальные функции...
Во первых: само их существование - убивает меня, как человека, умеющего чувствовать железо
И второе (самое очевидное): - если другой разработчик банально забудет реализовать функцию из интерфейса?

И, относительно недавно заметил одну интересную вещь: Если мы сделаем файл с обьявлением функций, а затем просто будем подключат его и реализовывать все функции? Покажу на практике:

// RenderDeclaration.h

void SetupScreen();

void ClearScreen();
void UpdateScreen();

^ Мы просто объявили функции в безымянном, для компилятора, файле (Напомню - компилятор работает только с .cpp файлами)

А вот затем, в целевом файле, делаем такой фокус:

// OpenGLRender.h

class ROpenGLRender
{
  #include "RenderDeclaration.h"
};

Иии, самое интересное, реализацию делаем напрямую в .cpp:

// OpenGLRender.cpp

void ROpenGLRender::SetupScreen() { ... }

void ROpenGLRender::ClearScreen() { ... }
void ROpenGLRender::UpdateScreen() { ... }

По сути, что мы сделали? При проходе препроцессингом, строка #include "RenderDeclaration.h" раскроется с содержимым внутри RenderDeclaration.h, то есть:

// OpenGLRender.h

class ROpenGLRender
{
  // #include "RenderDeclaration.h"
  void SetupScreen();
  
  void ClearScreen();
  void UpdateScreen();
};

^ А затем уже линковщик подловит все обьявления функций с их реализациями в OpenGLRender.cpp и все будет хорошо

Но хорошо, вы скажите, это не гибко и вообще очень плохо. Но я вас спрошу: "Какая, черт побери, гибкость в фундаменте архитектуры, которая ну никак не меняется?!"

По сути, виртуализация - это очень тяжелая штука. Каждая виртуальная функция уже КАК МИНИМУМ занимает от 4 до 8 байт! (4 байта на 32 битной машине. 8 байт на 64 битной машине. Но не суть)

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

"А если человек хочет реализовать свой вариант графики?" - тогда он просто создаст новый класс, подключит файл с функциями, IDE ему сразу предложит/подскажет какие функции надо реализовать - реализуете и работаете. Все! А чтобы применить графику, достаточно (к примеру):

// Config.h

#define RENDER_CLASS ROpenGLRender

А затем, уже где-то под капотом движка:

// Engine.cpp
#include "Config.h"

void Engine::SetupRender()
{
  RENDER_CLASS RenderClass;
  
  RenderClass.SetupScreen();
  RenderClass.ClearScreen();
  RenderClass.UpdateScreen();
  
  /* Other... */
}

И, если кто не понял, при проходе препроцессингом RENDER_CLASS заменится на ROpenGLRender и мы получим строку ROpenGLRender RenderClass;

И да, если я создам класс RVulkanRender, реализую функции, обновлю конфиг как #define RENDER_CLASS RVulkanRender, то получу тот же гибкий функционал при минимальных затратах. Никаких виртуальных функций, виртуальных таблиц и прочего

А в завершении могу добавить: При обновлении движка, создателю достаточно добавить новое обьявление в RenderDeclaration.h, а затем пользователь (работающий на движке) просто дополнит свой класс RVulkanRender новой функцией и все будет как раньше - без всякого "ой, я случайно забыл переопределить функцию"

What you don't use, you don't pay for. Think Cold.

❤4👍2🔥1👀1

195 viewsedited 12:44