Грокаем C++ on Telegram: “Construct on first use idiom Давайте здесь по-по…”

Construct on first use idiom

Давайте здесь по-подробнее остановимся. Вещь важная. Предыдущий пост. #опытным

Название говорящее и говорит оно нам, что объект будет конструироваться при первом использовании, а не когда-то заранее. То есть это ленивые вычисления.

Суть в том, чтобы создавать объект только в тот момент, когда он нам понадобиться. Так мы можем четко контролировать момент его инициализации. Делается это с помощью статических локальных переменных.

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

Вернемся к примеру и посмотрим, как это выглядит. Было так:

// source.cpp
int quad(int n) {
  return n * n;
}

auto staticA = quad(5);

// main.cpp
#include <iostream>

extern int staticA;
auto staticB = staticA;

int main() {
  std::cout << "staticB: " << staticB << std::endl;
}

а теперь стало так:

// source.cpp
int quad(int n) {
  return n * n;
}

int& GetStaticA() {
  static int staticA = quad(5);
return staticA;

}

// main.cpp
#include <iostream>

int& GetStaticA();
static auto staticB = GetStaticA();
// just omit main

Переменная staticB зависит от значения staticA и это может вызвать проблемы, если инициализации staticB произойдет первой.

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

Теперь результат компиляции не зависит от порядка файлов, которые передаются на вход. Что так g++ main.cpp source.cpp, что так g++ source.cpp main.cpp, результат будет staticB: 25.

Если у класса есть статическое поле и создание класса зависит от этого статического поля, то попробуйте перенести это поле внутрь статической функции(пример из этого поста):

using Map = std::map<std::string, std::unique_ptr<InitializationTest>>;
class InitializationTest {
public:
  static Map& GetMap() {
    static Map map;
    return map;
  }
  static bool Create(std::string ID) {
    GetMap().insert({ID, std::move(std::unique_ptr<InitializationTest>{new InitializationTest})});
    return true;
  }
  
private:
  static Map map;
  Test() = default;
};

static bool creation_result = InitializationTest::Create("qwe");

int main() {}

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

Если у вас есть 2 статических объекта пользовательского типа и инициализация одного из них предполагает использование другого, то можно сделать так(пример нагло украден у подписчика Бобра из этого коммента)

// singleton.h
class Singleton {
public:
    static Singleton& instance() {
        static Singleton inst{};
        return inst;
    }
    int makeSomethingUsefull(){}
private:
    Singleton() = default;
};

//another_singleton.h
#include "singleton.h"

class AnotherSingleton {
public:
    static AnotherSingleton& instance() {;
        static AnotherSingleton inst{Singleton::instance().makeSomethingUsefull()};
        return inst;
    }
private:
    AnotherSingleton(int param) : data{param} {};
    int data;
};

В этом примере создание объекта класса AnotherSingleton зависит от объекта Singleton. Поэтому мы запрещаем плебесам создавать объекты класса Singleton, а создаем его один раз в статической функции геттера инстанса объекта и дальше везде используем только этот инстанс.

Заключение в комментах

Solve your problems. Stay cool.

#cppcore #goodpractice #design