Можно ли обратиться к статическому полю шаблона класса без инстанцирования шаблона?

Question

[floppa322]

Есть ли в С++ синтаксическая конструкция, чтобы извне доступиться до публичной статической константы у шаблона класса?

Пример:

template <typename T, int32_t maxSize>
class CircularBuffer
{
private:

 /* Some code */

public:
static const int32_t  MEMBER_TO_BE_ACCESSIBLE_OUTSIDE = 0;
};

Потому, что писать что-то вроде

CircularBuffer<int, 0>::MEMBER_TO_BE_ACCESSIBLE_OUTSIDE

, добавляя "фиктивные" шаблонные параметры как-то слишком костыльно.

Comments

[Евгений Шатунов]

floppa322 , шаблон класса - это, прежде всего, шаблон типа. Это еще не тип и работать с шаблоном как с типом невозможно. Шаблон всегда требуется инстанцировать, результатом инстанцирования шаблона типа всегда будет тип, у которого уже можно получить доступ к полям и функциям.

добавляя "фиктивные" шаблонные параметры как-то слишком костыльно

После инстанцирования шаблона с параметрами, статическое поле MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет принадлежать только пространству инстанцированного типа. Иными словами, для каждой уникальной комбинации аргументов шаблона MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет иметь свой уникальный адрес размещения.

Расскажи что ты хочешь сделать. Для чего тебе потребовалось описанное в вопросе поведение?

[floppa322]

Евгений Шатунов,

floppa322 , шаблон класса - это, прежде всего, шаблон типа. Это еще не тип и работать с шаблоном как с типом невозможно. Шаблон всегда требуется инстанцировать, результатом инстанцирования шаблона типа всегда будет тип, у которого уже можно получить доступ к полям и функциям.

добавляя "фиктивные" шаблонные параметры как-то слишком костыльно

После инстанцирования шаблона с параметрами, статическое поле MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет принадлежать только пространству инстанцированного типа. Иными словами, для каждой уникальной комбинации аргументов шаблона MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет иметь свой уникальный адрес размещения.

Это-то я понимаю, просто думал, что вдруг есть какой-то хитрый сахар, чтобы провернуть то, что описано в вопросе )

Вообще, на практике не так часто требуется константа константа одного класса в другом, но тем не менее мне такие случаи встречались

Например:
1.Класс A использует regex и, чтобы написать тест на него и не ctrl + c / ctrl + v regex можно просто доступиться до публичного regex'а класса A в тесте
2. Или ещё более экзотический пример (тут уже не абстрактный, а конкретный пример): World (класс, агрегирующий всю игровую логику) работает на частоте Hz1, а класс Connection(класс, который шлёп пакеты клиентам с некоторой частотой) работает на частоте Hz2, которая вычисляет на основе Hz1. Можно было бы вынести Hz1 в файл вроде SharedConstants, но в данном случае код будет чище, если Hz1 оставить в лкассе World, так как всё-таки Hz1 больше относится к World, чем к SharedConstants

[floppa322]

Евгений Шатунов, ну и даже с приватными статическими константами хотелоь бы, чтобы на каждый тип шаблона копии переменных не создавались, то есть тут уже речь не идёт о красоте синтаксиса
Поэтому похоже для таких случаев нужно сделать файлик вроде SharedConstants.h

[Евгений Шатунов]

floppa322, хочу обратить твое внимание.

Класс A использует regex и, чтобы написать тест на него и не ctrl + c / ctrl + v regex можно просто доступиться до публичного regex'а класса A в тесте

"Класс A использует ..." - это уже описание решения. Решение всегда решает задачу и может быть каким угодно если удовлетворяет условиям задачи. Оно может быть неэффективным или вести к долгосрочным последствиям.
Описывать желательно саму задачу, для решения которой "Класс A использует ...".

Для чего тебе потребовалось описанное в вопросе поведение?

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

Это все относится и ко второму твоему пункту. Там тоже описано решение задачи. Сама задача - это параметры конфигурирования. Тебе нужны какие-то настройки для управления поведением той или иной сущности.
Для ее решения многие люди действительно заводят отдельный модуль с кучей констант, а потом путаются в них все время. Решение держать конфигурацию внутри типа - не самое удачное. Лучше, минимально, вынести конфиг в отдельную структуру, в которой хоть теми же самыми статическими полями все и определить именно и только для одной сущности. Суть в том, что сущность зависит от конфига, но конфиг не является неотъемлемой частью сущности. Сущностей одного типа может быть много и у каждой может быть свой конфиг. Т.е. тебе лучше сделать WorldSettings и ConnectionSettings, в которых и разместить настройки для World и Connection.
В бизнесе этот вопрос решается через довольно сложную подсистему конфигурации, которая позволяет управлять настройками игры из самых разных мест.

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

В этом случае вариант от Sergio является самым лучшим и чистым решением.

[floppa322]

Евгений Шатунов, хорошо, учту насчёт формулировки вопроса и конфигов для классов )