Компилятор С++ оптимизирует переданные аргументы

Если вам нужно иметь возможность выборочно включать и отключать предупреждения во время выполнения, компилятор не сможет оптимизировать вызов.

Что вам нужно, так это переименовать вашу функцию в WARN2 и добавить макрос, например:

#define WARN(s) do {if (WARNINGS_ENABLED) WARN2(s);} while (false)

Это предотвратит оценку s во время выполнения, если у вас не включены предупреждения.

Использование do-while — это уловка, которая позволяет использовать его в любом месте кода (голый оператор, оператор в блоке if, заключенном в фигурные скобки, оператор в блоке if без фигурных скобок, операторы while в фигурных скобках и без фигурных скобок и т. д.).

Вы можете проверить, что делает GCC/G++, используя параметр -S. Это выведет код до того, как он будет фактически собран — см. gcc(1).

GCC и G++ в этом случае ведут себя более или менее одинаково. Поэтому я сначала перевел код на C, чтобы провести дополнительные тесты:

char WARNINGS_ENABLED = 0;

inline void WARN(const char* message) {
    if (!WARNINGS_ENABLED) {
        return;
    }
    puts(message);
}

int main() {
    WARN("foo");
    return 0;
}

запустите gcc -O3 -S file.c и просмотрите выходной файл 'file.s'
. Вы увидите, что GCC не удалил что угодно!

Это не то, о чем вы просили, но чтобы дать компилятору возможность оптимизировать этот код, вам нужно сделать WARNINGS_ENABLED константой. В качестве альтернативы можно сделать его статическим и не изменять значение в этом файле. Но: создание статического имеет побочный эффект, заключающийся в том, что символ не экспортируется.

static const char WARNINGS_ENABLED = 0;

inline void WARN(const char* message) {
  if (!WARNINGS_ENABLED) {
      return;
  }
  puts(message);
}

int main() {
    WARN("foo");
    return 0;
}

Затем GCC полностью очищает код.

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

Я не эксперт по повышению, но я предполагаю, что есть способ построить лямбду, которая будет оцениваться для генерации строки только в том случае, если WARNINGS_ENABLED истинно. Что-то вроде...

inline void warnFunc(some_boost_lambda &message_generator) {
  if (WARNINGS_ENABLED) {
    cerr << message_generator() << endl;
  }
}

#define WARN(msg) warnFunc(...insert boost magic here to turn msg into a lambda...)

Нет, компилятор не должен не оптимизировать код в любом случае, если глобальный WARNING_ENABLED не объявлен константным.

Кстати, если WARN является встроенной функцией, вы все равно будете платить за построение сообщения (что очень неэффективно в вашем примере с lexical_cast и operator+ для строк), даже если оно отключено.

Вот некоторые эффективные (минимальные (близкие к нулю с предсказанием ветвления ЦП) накладные расходы при отключенной среде выполнения) макросы ведения журналов, поддерживающие ведение журналов в стиле функций и потоков.

Разве вы не можете просто определить все это с помощью препроцессора?

void inline void LogWarning(const string &message) 
{
  //Warning
}

#ifdef WARNINGS_ENABLED
#define WARN(a) LogWarning(a)
#else
#define WARN(a)
#endif

Именно так работает макрос ASSERT(). Весь код в скобках в WARN даже не проходит через препроцессор в компилятор. Это означает, что вы можете делать другие вещи, такие как

#ifdef WARNINGS_ENABLED
// Extra setup for warning
#endif
//....
WARN(uses setup variables)

И он будет компилироваться в обоих направлениях.

Что касается того, чтобы заставить оптимизатор понять, что в скобках нет побочных эффектов, вы можете поместить туда некоторые довольно сложные операторы (например, высокоуровневые манипуляции со строками), которые трудно доказать в любом случае.