как разделить код режима отладки и выпуска

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

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

Вы можете использовать что-то вроде boost :: log , установив уровень важности на тот, который вам нужен.

void init()
{
    logging::core::get()->set_filter
    (
        flt::attr< logging::trivial::severity_level >("Severity") >= logging::trivial::info
    );
}

int main(int, char*[])
{
    init();

    BOOST_LOG_TRIVIAL(trace) << "A trace severity message";
    BOOST_LOG_TRIVIAL(debug) << "A debug severity message";
    BOOST_LOG_TRIVIAL(info) << "An informational severity message";
    BOOST_LOG_TRIVIAL(warning) << "A warning severity message";
    BOOST_LOG_TRIVIAL(error) << "An error severity message";
    BOOST_LOG_TRIVIAL(fatal) << "A fatal severity message";
}

Я думаю, что у pantheios тоже есть нечто подобное.

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

например,

#ifdef _DEBUG
#define DEBUG_PRINT(x) printf(x);
#else
#define DEBUG_PRINT(x)
#endif

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

__LINE__ 
__FILE__

, в отладочную информацию.

Запишите один раз

#ifdef _DEBUG 
const bool is_debig = true;
#else 
const bool is_debig = false;
#endif 

, а затем

template<bool debug>
struct TemplateDebugHelper {
   void PrintDebugInfo(const char* );
   void CalcTime(...);
   void OutputInfoToFile(...);
   /// .....
};

// Empty inline specialization
template<>
struct TemplateDebugHelper<false> {
   void PrintDebugInfo(const char* ) {} // Empty body
   void CalcTime(...) {} // Empty body
   void OutputInfoToFile(...) {} // Empty body
   /// .....
};

typedef TemplateDebugHelper<is_debug> DebugHelper;

DebugHelper global_debug_helper;

int main() 
{
   global_debug_helper.PrintDebugInfo("Info"); // Works only for is_debug=true
}

Используйте такое определение для заголовков включения

#ifdef  TESTING
#define DEBUG_INFOS(_X_) CallYourDebugFunction(_X_ )
#else
#define DEBUG_INFOS(_X_) ((void)0)
#endif

, а затем используйте только это в своем коде

...
DEBUG_INFOS("infos what ever");
RestOfWork();
...

Вы также можете использовать и искать ASSERT и TRACE и используйте DebugView из sysinternals для чтения вывода в реальном времени из трассировки или отслеживания проблем с ASSERT. ASSERT и TRACE выполняют аналогичную работу, и вы можете почерпнуть из них идеи.

комментарии: Я использую объявление ТЕСТИРОВАНИЕ, потому что я вижу это в вопросе.

Я пишу на Си для встраиваемых систем. В своих программах я использую следующие макросы:

#define _L  log_stamp(__FILE__, __LINE__)

#define _LS(a)  log_string(a)

#define _LI(a)  log_long(a)

#define _LA(a,l)  log_array(a,l)

#define _LH(a)  log_hex(a)

#define _LC(a)  log_char(a)

#define ASSERT(con) log_assert(__FILE__, __LINE__, con)

Когда я делаю релизную версию, я просто отключаю директиву #define DEBUG и все макросы становятся пустыми. Обратите внимание, что в релизной версии это не потребляет ни циклов процессора, ни памяти. Макросы - это единственный способ сохранить в лог информацию: где было выполнено логирование (номер файла и строки).

Если мне нужна эта информация, я использую: _L;_LS("это номер сообщения журнала ");_LI(5);

иначе без директивы _L.