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

__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__. От С++ никогда не бывает достаточно сюрпризов :)

Редактировать: @Jonathan Leffler предлагает еще несколько хороших вариантов использования в комментариях:

Игра с #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. */
}

С++ 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* имя_функции() const noexcept;

6 Возвращает: Если этот объект представляет позицию в теле функции, возвращает определяемую реализацией 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% случаев ничего страшного из этого не выйдет.