Лучший макрос LOG() с использованием метапрограммирования шаблонов

Типичное логическое решение LOG() на основе макросов может выглядеть примерно так:

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

Проблема заключается в том, что это приводит к тому, что компилятор включает в себя несколько вызовов ostream :: operator <<. Это увеличивает сгенерированный код и, следовательно, размер функции, который, как я подозреваю, может повредить производительность кэша команд и препятствовать компилятору оптимизировать код.

Здесь "простая" альтернатива, которая заменяет встроенный код вызовом функции вариационного шаблона:

********* РЕШЕНИЕ № 2: ФУНКЦИЯ ВАРИАДИЧЕСКОГО ШАБЛОНА *********

Компилятор автоматически генерирует новые экземпляры функции шаблона по мере необходимости в зависимости от количества, вида и порядка аргументов сообщения.

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

********* РЕШЕНИЕ № 3: ШАБЛОНЫ ЭКСПРЕССИИ *********

В предложении @DyP я создал альтернативное решение, которое использует шаблоны выражений:

Решение шаблонов выражений позволяет программисту использовать знакомые удобные и безопасные по типу потоки операторы:

Тем не менее, когда Part<A, B> создается инлайн, никаких операторов << << не выполняется, что дает нам преимущество обоих миров: удобные и безопасные по типу потоки операторы + меньшее количество инструкций. ICC13 с -O3 создает следующий код сборки для вышеперечисленного:

Всего 19 инструкций, включая один вызов функции. Кажется, что каждый добавленный дополнительный аргумент добавляет 3 инструкции. Компилятор создает другую функцию создания событий(), зависящую от количества, вида и порядка частей сообщения, что объясняет странное имя функции.

********* РЕШЕНИЕ № 4: ШАБЛОНЫ ЭКСПРЕССИИ CATO *********

Вот отличное решение Cato с настройкой поддержки потоковых манипуляторов (например, endl):

Как указывает Като, преимущество над последним решением заключается в том, что оно приводит к меньшему количеству экземпляров функций, поскольку специализация const char * обрабатывает все строковые литералы. Это также приводит к созданию меньших инструкций на сайте вызова:

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

Ответы

Ответ 1

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

struct None { };

template <typename First,typename Second>
struct Pair {
  First first;
  Second second;
};

template <typename List>
struct LogData {
  List list;
};

template <typename Begin,typename Value>
LogData<Pair<Begin,const Value &>>
  operator<<(LogData<Begin> begin,const Value &value)
{
  return {{begin.list,value}};
}

template <typename Begin,size_t n>
LogData<Pair<Begin,const char *>>
  operator<<(LogData<Begin> begin,const char (&value)[n])
{
  return {{begin.list,value}};
}

inline void printList(std::ostream &os,None)
{
}


template <typename Begin,typename Last>
void printList(std::ostream &os,const Pair<Begin,Last> &data)
{
  printList(os,data.first);
  os << data.second;
}

template <typename List>
void log(const char *file,int line,const LogData<List> &data)
{
  std::cout << file << " (" << line << "): ";
  printList(std::cout,data.list);
  std::cout << "\n";
}

#define LOG(x) (log(__FILE__,__LINE__,LogData<None>() << x))

С G++ 4.7.2 с оптимизацией -O2 это создает очень компактную последовательность команд, эквивалентную заполнению структуры параметрами с использованием char * для строковых литералов.

Ответ 2

Я прошел точно то же самое. И я закончил с тем же решением, которое вы описали, что просто требует, чтобы клиентский API использовал запятую вместо оператора вставки. Это делает вещи довольно простыми и работает достаточно хорошо. Настоятельно рекомендуется.