Используете ли вы static не inline, и для чего?

Question

[ImagineTables]

С тех пор, как static-поля стало можно делать инлайновыми, пользуетесь ли вы для чего-то не инлайновыми static-полями?

Я нашёл один полезный кейс — ресурсы. Объявляю в хедере Resource.h дерево структур, типа:

struct Resources
{
    struct Type1
    {
        static Text Resource1; // Text это тип, могут быть другие типы
    }
};

А инициализацию:

Resources::Type1::Resource1 = ...;

делаю в каждой из локализаций: Resource.en.cpp, Resource.ru.cpp и т.д. Локализации переключаются макросами. Забыл локализовать используемый ресурс или неправильно подключил локализацию — лови ошибку линкера (в этом смысл). Удобно ли ресурсы хранить в формате C++, это отдельный вопрос.

Есть ли другие сценарии? Просто думаю, насколько оправдано в гайдлайн включить пункт о неиспользовании неинлайновых static-полей для всего, кроме ресурсов.

Comments

[res2001]

Нужда в static полях классов регулярно появляется, как правило их необходимость диктует сама логика работы класса (т.е. то для чего он создается).
Как наиболее общий вариант использования - класс синглтон - можно единственный указатель на класс объявить статиком в самом классе, возвращать его используя то же статический метод GetInstance(), при первом вызове класс создается, дальше возвращается уже готовый указатель.

Answer 1

[Пума Тайланд]

Похожий трюк масштабируется шире ресурсов: объявил static-поле в хедере без определения — если нужный .cpp не подключён к сборке, линковщик даст undefined reference. Так можно enforce'ить обязательную линковку конкретной единицы трансляции: регистрация плагина, feature-флаг, конфиг под сборку — забыл модуль, поймаешь на линковке, а не в рантайме.

Плюс: меняется только инициализатор — правишь .cpp, а не хедер, остальные TU не пересобираются каскадом. До C++17, пока не было инлайн-переменных, это вообще был единственный вариант.