Предполагая, что ваш компилятор С++ поддерживает их, существует ли какая-либо особая причина не использовать __FILE__, __LINE__ и __FUNCTION__ для ведения журналов и отладки?
Я в первую очередь забочусь о том, чтобы давать пользователям вводящие в заблуждение данные, например, сообщать о некорректном номере или функции линии в результате оптимизации или в результате получить удар производительности.
В принципе, могу ли я доверять __FILE__, __LINE__ и __FUNCTION__, чтобы всегда поступать правильно?
__FUNCTION__ не является стандартным, __func__ существует в C99/С++ 11. Остальные (__LINE__ и __FILE__) просто хороши.
Он всегда будет сообщать правильный файл и строку (и функцию, если вы решите использовать __FUNCTION__/__func__). Оптимизация - это нефактор, так как это расширение макросов времени компиляции; он будет никогда влиять на производительность любым способом.
В редких случаях может оказаться полезным изменить строку, заданную __LINE__ на что-то другое. Я видел, что GNU configure делает это для некоторых тестов, чтобы сообщить соответствующие номера строк после того, как он вставил некоторые вуду между строками, которые не отображаются в исходных исходных файлах. Например:
#line 100
__LINE__ следующие строки с __LINE__ 100. Вы можете дополнительно добавить новое имя файла
#line 100 "file.c"
Это редко бывает полезно. Но если это необходимо, нет никаких альтернатив, о которых я знаю. На самом деле, вместо линии, макрос может использоваться также, что должно привести к любой из двух вышеуказанных форм. Используя библиотеку препроцессора boost, вы можете увеличить текущую строку на 50:
#line BOOST_PP_ADD(__LINE__, 50)
Я подумал, что полезно упомянуть об этом, так как вы спрашивали об использовании __LINE__ и __FILE__. Из C++ никогда не бывает достаточно сюрпризов :)
Редактировать: @Jonathan Leffler предоставляет несколько замечаний в комментариях:
Мессинг С#line очень полезен для предварительных процессоров, которые хотят сохранить ошибки, сообщаемые в коде пользователя C, в соответствии с исходным файлом пользователя. Yacc, Lex, и (больше у меня дома). Препроцессоры ESQL/C делают это.
FYI: g++ предлагает нестандартный макрос __PRETTY_FUNCTION__. До сих пор я не знал о C99 __func__ (спасибо Эван!). Я думаю, что по-прежнему предпочитаю __PRETTY_FUNCTION__, когда он доступен для определения дополнительного класса.
PS:
static string getScopedClassMethod( string thePrettyFunction )
{
size_t index = thePrettyFunction . find( "(" );
if ( index == string::npos )
return thePrettyFunction; /* Degenerate case */
thePrettyFunction . erase( index );
index = thePrettyFunction . rfind( " " );
if ( index == string::npos )
return thePrettyFunction; /* Degenerate case */
thePrettyFunction . erase( 0, index + 1 );
return thePrettyFunction; /* The scoped class name. */
}
Лично я не хочу использовать их ни для чего, кроме отладки сообщений. Я сделал это, но стараюсь не показывать такую информацию клиентам или конечным пользователям. Мои клиенты - не инженеры, а иногда не компьютерные. Я могу записать эту информацию на консоль, но, как я сказал, неохотно за исключением отладочных сборников или внутренних инструментов. Я полагаю, что это зависит от вашей клиентской базы.
Я использую их все время. Единственное, о чем я беспокоюсь, это отдать IP-адрес в файлах журналов. Если имена ваших функций действительно хороши, вы можете сделать коммерческую тайну легче раскрыть. Это похоже на отгрузку с отладочными символами, только сложнее найти вещи. В 99,999% случаев из этого ничего плохого не выйдет.