Использование __FILE__, __LINE__ и __FUNCTION__ в C ++

Предположив , что ваш компилятор C ++ поддерживает их, есть ли конкретная причина не в использовании __FILE__, __LINE__и __FUNCTION__для регистрации и целей отладки?

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

В принципе, я могу доверять __FILE__, __LINE__и __FUNCTION__чтобы всегда делать правильные вещи?

__FUNCTION__не является стандартным, __func__существует в C99 / C ++ 11. Остальные ( __LINE__и __FILE__) просто в порядке.

Он всегда сообщит правильный файл и строку (и функцию, если вы решите использовать __FUNCTION__/ __func__). Оптимизация не является фактором, так как это расширение макроса во время компиляции; это никак не повлияет на производительность.

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

#line 100

Следующие строки будут начинаться с __LINE__100. При желании вы можете добавить новое имя файла

#line 100 "file.c"

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

#line BOOST_PP_ADD(__LINE__, 50)

Я думал, что это полезно упомянуть, так как вы спросили об использовании __LINE__и __FILE__. Никто никогда не получает достаточно сюрпризов из C ++ :)

Редактировать: @Джонатан Леффлер приводит еще несколько хороших примеров использования в комментариях:

Работа с #line очень полезна для препроцессоров, которые хотят, чтобы ошибки сообщались в коде C пользователя в соответствии с его исходным файлом. Yacc, Lex и (больше дома для меня) препроцессоры ESQL / C делают это.

К вашему сведению: 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. */
}

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

C ++ 20 std::source_location

В C ++ наконец-то добавлена ​​опция не-макросов, и она, вероятно, будет доминировать в будущем, когда C ++ 20 станет широко распространенным:

• https://en.cppreference.com/w/cpp/utility/source_location
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1208r5.pdf

Документация гласит:

constexpr const char * function_name () const noexcept;

6 Returns: Если этот объект представляет позицию в теле функции, возвращает NTBS, определенный реализацией, который должен соответствовать имени функции. В противном случае возвращает пустую строку.

где NTBS означает «строка байтов, завершенная нулем».

Я попробую, когда поддержка придет в GCC, GCC 9.1.0 g++-9 -std=c++2aвсе еще не поддерживает его.

https://en.cppreference.com/w/cpp/utility/source_location утверждает, что использование будет следующим:

#include <iostream>
#include <string_view>
#include <source_location>

void log(std::string_view message,
         const std::source_location& location std::source_location::current()
) {
    std::cout << "info:"
              << location.file_name() << ":"
              << location.line() << ":"
              << location.function_name() << " "
              << message << '\n';
}

int main() {
    log("Hello world!");
}

Возможный вывод:

info:main.cpp:16:main Hello world!

__PRETTY_FUNCTION__против __FUNCTION__против __func__противstd::source_location::function_name

Ответили по адресу: В чем разница между __PRETTY_FUNCTION__, __FUNCTION__, __func__?

Я использую их все время. Единственное, о чем я беспокоюсь, это выдача IP в лог-файлах. Если ваши имена функций действительно хороши, возможно, вам будет проще раскрыть коммерческую тайну. Это похоже на доставку с отладочными символами, только труднее найти вещи. В 99,999% случаев ничего плохого из этого не выйдет.