__FILE__, __LINE__, dan __FUNCTION__ penggunaan dalam C ++

Dengan anggapan bahwa kompiler C ++ Anda mendukungnya, apakah ada alasan khusus untuk tidak menggunakannya __FILE__, __LINE__dan __FUNCTION__untuk tujuan logging dan debugging?

Saya terutama prihatin dengan memberikan data yang menyesatkan pengguna — misalnya, melaporkan nomor baris yang salah atau fungsi sebagai hasil dari optimasi — atau sebagai akibatnya mendapatkan hasil yang mengejutkan.

Pada dasarnya, dapatkah saya percaya __FILE__, __LINE__dan __FUNCTION__untuk selalu melakukan hal yang benar?

__FUNCTION__tidak standar, __func__ada di C99 / C ++ 11. Yang lain ( __LINE__dan __FILE__) baik-baik saja.

Itu akan selalu melaporkan file dan baris yang tepat (dan berfungsi jika Anda memilih untuk menggunakan __FUNCTION__/ __func__). Optimalisasi adalah non-faktor karena merupakan ekspansi makro waktu kompilasi; itu tidak akan pernah mempengaruhi kinerja dengan cara apa pun.

Dalam kasus yang jarang terjadi, akan berguna untuk mengubah garis yang diberikan oleh __LINE__kepada hal lain. Saya telah melihat konfigurasi GNU melakukan itu untuk beberapa tes untuk melaporkan nomor baris yang sesuai setelah itu memasukkan beberapa voodoo antara baris yang tidak muncul dalam file sumber asli. Sebagai contoh:

#line 100

Akan membuat baris berikut dimulai dengan __LINE__100. Anda dapat menambahkan nama file baru secara opsional

#line 100 "file.c"

Ini jarang berguna. Tetapi jika dibutuhkan, tidak ada alternatif yang saya tahu. Sebenarnya, alih-alih baris, makro dapat digunakan juga yang harus menghasilkan salah satu dari dua bentuk di atas. Menggunakan perpustakaan preprocessor boost, Anda dapat menambah baris saat ini dengan 50:

#line BOOST_PP_ADD(__LINE__, 50)

Saya pikir sangat berguna untuk menyebutkannya karena Anda bertanya tentang penggunaan __LINE__dan __FILE__. Satu tidak pernah mendapat cukup kejutan dari C ++ :)

Sunting: @Jonathan Leffler memberikan beberapa kasus penggunaan yang lebih baik dalam komentar:

Messing dengan #line sangat berguna untuk pra-prosesor yang ingin menjaga kesalahan yang dilaporkan dalam kode C pengguna sesuai dengan file sumber pengguna. Yacc, Lex, dan (lebih banyak di rumah bagi saya) ESQL / C preprocessor melakukan itu.

FYI: g ++ menawarkan makro __PRETTY_FUNCTION__ non-standar. Sampai sekarang saya tidak tahu tentang C99 __func__ (terima kasih Evan!). Saya pikir saya masih lebih suka __PRETTY_FUNCTION__ bila tersedia untuk pelingkupan kelas tambahan.

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. */
}

Secara pribadi, saya enggan menggunakan ini untuk apa pun selain pesan debugging. Saya telah melakukannya, tetapi saya berusaha untuk tidak menunjukkan informasi seperti itu kepada pelanggan atau pengguna akhir. Pelanggan saya bukan insinyur dan terkadang tidak paham komputer. Saya mungkin mencatat info ini ke konsol, tetapi, seperti yang saya katakan, dengan enggan kecuali untuk debug builds atau untuk alat internal. Saya kira itu tergantung pada basis pelanggan yang Anda miliki.

C ++ 20 std::source_location

C ++ akhirnya menambahkan opsi non-makro, dan itu kemungkinan akan mendominasi di beberapa titik di masa mendatang ketika C ++ 20 menyebar luas:

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

Dokumentasi mengatakan:

constexpr const char * function_name () const noexcept;

6 Pengembalian: Jika objek ini mewakili posisi di tubuh fungsi, mengembalikan NTBS yang ditentukan implementasi yang harus sesuai dengan nama fungsi. Jika tidak, kembalikan string kosong.

di mana NTBS berarti "Null Terminated Byte String".

Saya akan mencobanya ketika dukungan datang ke GCC, GCC 9.1.0 dengan g++-9 -std=c++2amasih tidak mendukungnya.

https://en.cppreference.com/w/cpp/utility/source_location klaim penggunaan akan seperti:

#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!");
}

Output yang mungkin:

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

__PRETTY_FUNCTION__vs __FUNCTION__vs __func__vsstd::source_location::function_name

Dijawab di: Apa perbedaan antara __PRETTY_FUNCTION__, __FUNCTION__, __func__?

Saya menggunakannya sepanjang waktu. Satu-satunya hal yang saya khawatirkan adalah memberikan IP dalam file log. Jika nama fungsi Anda benar-benar bagus, Anda mungkin membuat rahasia dagang lebih mudah terungkap. Ini seperti pengiriman dengan simbol debug, hanya lebih sulit untuk menemukan sesuatu. Dalam 99,999% kasus tidak ada hal buruk yang akan terjadi.