Занимательный C++: Счетчик времени компиляции

Предлагается разработать безопасную альтернативу встроенного макроса __COUNTER__. Первое вхождение макроса заменяется на 0, второе на 1, и так далее. Значение __COUNTER__ подставляется на этапе препроцессирования, следовательно его можно использовать в контексте constant expression.

К сожалению, макрос __COUNTER__ опасно использовать в заголовочных файлах — при другом порядке включения заголовочных файлов подставленные значения счетчика поменяются. Это может привести к ситуации, когда например в foo.cpp значение константы AWESOME равно 42, в то время как в bar.cpp AWESOME≡33. Это нарушение принципа one definition rule, что есть страшный криминал во вселенной C++.

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

По мотивам этого вопроса ^[1] на Stack Overflow.

Мотивирующий пример

STRUCT(Point3D)
  FIELD(x, float)
  FIELD(y, float)
  FIELD(z, float)
END_STRUCT

#define FIELD(name, type) 
  type name; // определение поля 
  template<> 
  void serialize<__COUNTER__/2>(Archive &ar) { 
    ar.write(name); 
    serialize<(__COUNTER__-1)/2+1>(ar); 
  }

float x; // определение поля x
template<>
void serialize<0>(Archive &ar) {
  ar.write(x);
  serialize<1>(ar);
}

float y; // определение поля y
template<>
void serialize<1>(Archive &ar) {
  ar.write(x);
  serialize<2>(ar);
}

Однобитный счетчик времени компиляции

Для начала, покажем реализацию однобитного счетчика.

// (1)
template<size_t n>
struct cn {
    char data[n+1];
};

// (2)
template<size_t n> 
cn<n> magic(cn<n>);

// (3) текущее значение счетчика
sizeof(magic(cn<0>())) - 1; // 0

// (4) «инкремент»
cn<1> magic(cn<0>);

// (5) текущее значение счетчика
sizeof(magic(cn<0>())) - 1; // 1

1. Определяем шаблонную структуру cn<n>. Отметим, что sizeof(cn<n>) ≡ n+1.
2. Определяем шаблонную функцию magic.
3. Оператор sizeof, примененный к выражению, выдает размер типа, который имеет данное выражения. Так как выражение не вычисляется, определения тела функции magic не требуется.
   Единственная определенная на данный момент функция magic — шаблон из п. 2. Поэтому тип возвращаемого значения и всего выражения — cn<0>.
4. Определим перегруженную функцию magic. Отметим, что неоднозначности при вызове magic не возникает, потому что перегруженные функции имеют приоритет перед шаблонными функциями.
5. Теперь при вызове magic(cn<0>()) будет использован другой вариант функции; тип выражения внутри sizeof — cn<1>().

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

Определим макросы для чтения и «инкрементации» однобитного счетчика.

#define counter_read(id) 
  (sizeof(magic(cn<0>())) - 1)

#define counter_inc(id) 
  cn<1> magic(cn<0>)

N-битный счетчик времени компиляции

N-битный счетчик строится на тех же принципах, что и однобитный. Вместо одного вызова magic внутри sizeof у нас будет цепочка вложенных вызовов a(b(c(d(e( … ))))).

Вот он, наш базовый строительный блок. Это функция от одного аргумента типа T₀. В зависимости от доступных деклараций в области видимости, тип возвращаемого значения или T₀ или T₁. Это устройство напоминает стрелку на железной дороге. В начальном состоянии, «стрелка» направлена влево. «Стрелку» можно переключить единственный раз.

Используя несколько базовых блоков, мы можем собрать разветвленную сеть:

При поиске подходящего варианта функции, компилятор C++ учитывает только типы параметров а тип возврашаемого значения игнорирует. Если в выражении есть вложенные вызовы функций, компилятор «движется» изнутри наружу. Например в следующем выражении: M₁(M₂(M₄( T₀() ))), компилятор сначала разрешает («резолвит») вызов функции M₄(T₀). Затем, в зависимости от типа возвращаемого значения функции M₄, он разрешает вызов M₂(T₀) или M₂(T₄), и так далее.

Продолжая железнодорожную аналогию, можно сказать, что компилятор движется по железнодорожной сети сверху вниз, «сворачивая» на стрелках вправо или влево. Выражение из N вложенных вызовов функций порождает сеть с 2^N выходами. Переключая стрелки в правильном порядке, можно последовательно получить все 2^N возможных типов T_i на выходе сети.

Можно показать, что если текущий тип на выходе сети T_i, то следующей нужно переключить стрелку M[(i+1)&~i, (i+1)&i].

Окончательный вариант кода доступен по ссылке ^[4].

Вместо заключения

Счетчик времени компиляции целиком основан на механизме перегруженных функций. Эту технику я подсмотрел ^[1] на Stack Overflow. Как правило, нетривиальные ^[5] вычисления времени компиляции в C++ реализуются на шаблонах, именно поэтому представленное решение особенно интересно, так как вместо шаблонов эксплуатирует иные механизмы.

Насколько такие решения практичны?

ИМХО если единственный C++ файл компилируется более 5 минут, причем справиться с ним может только самая последняя версия компилятора — это точно непрактично ^[6]. Многие «креативные» варианты использования языковых возможностей в C++ представляют исключительно академический интерес. Как правило, те же задачи можно лучше решить иными способами, например путем привлечения внешнего кодогенератора. Хотя, надо сказать, автор несколько предвзят в данном вопросе, категорически не признавая spirit ^[7], и испытывая некоторую слабость по отношению к bison ^[8].

Кажется, счетчик времени компиляции так же не особо практичен, как хорошо видно на следующем графике. По оси x отложена абсолютная величина приращения счетчика в тестовой программе (тестовая программа состоит из строк counter_inc(int)), по оси y — время компиляции в секундах. Для сравнения, там же отложено время компиляции nginx-1.5.2.

Автор: mejedi

Источник ^[9]