Можно ли объявить переменную-член класса с помощью метапрограммирования?

Question

[floppa322]

Пример кода:

template <typename T, bool someCondition>
class Example
{

//    #ifdef SOME_CONDITION
//    int x;  
//    #endif

    // ↓ ↓ ↓  Ниже представлен псевдокод-эквивалент закомментированому коду выше: ↓ ↓ ↓ 
    if constexpr (someCondition)
    {
        int x;  
    }
    
  /* Some code... */

};

Есть ли эквивалент тому участку кода, который закомментирован (с использованием макроса), но с помощью метапрограммирования?

Comments

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

floppa322 , условная компиляция при объявлении полей класса - это, безусловно, весьма увлекательное и незабываемое приключение.
Сперва ты просто объявляешь поле под условным макросом. Потом к тебе приходит понимание что и весь код использования этого поля тоже надо обернуть в тот же самый условный макрос. А потом появляются побочные эффекты от включения и отключения условного кода. Потом при переключении условия начинает выясняться что тут и там код перестает транслироваться потому что устарел. Кое-как ты справляешься с тяготами стыковки кода между препроцессором и плюсами, как к тебе приходит блестящая мысль переписать это все на метакод!
И дальше все по новой, только уже жестче, потому что это не препроцессор.

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

[floppa322]

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

ну, если someCondition false, то члена в классе не должно быть
соответственно во всех методах, где этот член используется можно будет проверку if constexpr (someCondition)

Answer 1

[cunion]

template <bool X>
struct test
{};

template <>
struct test<true>
{
	int a;
};

Comments

[floppa322]

Благодарю за ответ
Только хотелось бы без специализации, чтобы код не дублировать

[cunion]

floppa322,

struct basic_functional
{
	void foo();
	void boo();
	void doo();
};

template <bool X = false>
struct additional_functional
	: basic_functional
{};

template <>
struct additional_functional<true>
	: basic_functional
{
	void hoo();
};

Answer 2

[res2001]

Условия можно проверять с помощью enable_if.
Переменную, видимо, придется запихнуть во вложенную шаблонную структуру, где и использовать enable_if.
Я сам не силен в метапрограммировании, но можете начать по этой ссылке копать, там и примеров много.

Answer 3

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

Соберем немного конкретики из комментариев.

Отсюда:

Только хотелось бы без специализации, чтобы код не дублировать

Единственным дублированием кода тут будет только заголовок частичной специализации шаблона. В силах писателя определить общий между специализациями код и вынести его в родительский для всех специализаций класс.
А с подобным дублированием справляется шаблон std::enable_if[?]. Часто его используют для выбора поведения шаблона исходя из черт аргумента шаблона.

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

Отсюда:

соответственно во всех методах, где этот член используется можно будет проверку if constexpr (someCondition)

Я подобные блоки кода называю замусореванием. Это как будто шел человек, захотел есть, пошел к палатке, купил еду, поел, а обертку и все остальное кинул прямо перед палаткой. Намусорил и ушел.
Вот и писатель кода нередко в пылу решения задачи заходит в код, что-то дописывает, решает свои житейские проблемы и в результате код становится замусоренным. В коде больше не видно поведения, в коде появляются всякие сервисные штуки для этого кода. Код становится тяжело читать. А шаблонный код всегда и вдвойне тяжелее читать.

За чистотой кода нужно следить. Подобные вещи, как вот такие блоки if constexpr, нужно убирать в функции. А где эти функции лучше расположить? Верно - прямо там, где для их работы определены данные. Поэтому на самом деле if constexpr не нужен. Нужно определить набор функций с поведением там где оно возможно. А где нет - определить заглушки чтобы клиентский, относительно вариативного поведения, код не нуждался в проверках и мог просто обращаться к вариативному поведению так, как будто оно не вариативно и есть всегда.
Опять же, тут хорошо подходит пример с DebugName[?], в котором такие заглушки реализованы.

Comments

[floppa322]

Спасибо за развёрнтый ответ )