Utilisation de __FILE__, __LINE__ et __FUNCTION__ en C++.

Question

En supposant que votre compilateur C++ les supporte, y a-t-il une raison particulière pas à utiliser __FILE__ , __LINE__ y __FUNCTION__ à des fins de journalisation et de débogage ?

Je suis surtout préoccupé par le fait de donner à l'utilisateur des données trompeuses - par exemple, signaler le mauvais numéro de ligne ou la mauvaise fonction à la suite de l'optimisation - ou de subir une baisse de performance en conséquence.

En gros, est-ce que je peux faire confiance __FILE__ , __LINE__ y __FUNCTION__ a toujours faire ce qu'il faut ?

Answer 1

__FUNCTION__ n'est pas standard, __func__ existe en C99 / C++11. Les autres ( __LINE__ y __FILE__ ) sont parfaits.

Il signalera toujours le bon fichier et la bonne ligne (et la bonne fonction si vous choisissez d'utiliser la fonction __FUNCTION__ / __func__ ). L'optimisation n'est pas un facteur, car il s'agit d'une expansion de macro au moment de la compilation. jamais affecter les performances de quelque manière que ce soit.

Answer 2

Dans de rares cas, il peut être utile de modifier la ligne qui est donnée par __LINE__ à quelque chose d'autre. J'ai vu GNU configure faire cela pour certains tests afin de rapporter les numéros de ligne appropriés après avoir inséré quelques voodoo entre des lignes qui n'apparaissent pas dans les fichiers sources originaux. Par exemple :

#line 100

Les lignes suivantes commenceront par __LINE__ 100. Vous pouvez éventuellement ajouter un nouveau nom de fichier

#line 100 "file.c"

Il n'est que rarement utile. Mais si c'est nécessaire, il n'y a pas d'alternative à ma connaissance. En fait, au lieu de la ligne, on peut aussi utiliser une macro qui doit aboutir à l'une des deux formes ci-dessus. En utilisant la bibliothèque du préprocesseur boost, vous pouvez incrémenter la ligne courante de 50 :

#line BOOST_PP_ADD(__LINE__, 50)

J'ai pensé qu'il était utile de le mentionner puisque vous avez demandé l'utilisation de __LINE__ y __FILE__ . On n'a jamais assez de surprises avec le C++ :)

Edit : @Jonathan Leffler fournit quelques autres bons cas d'utilisation dans les commentaires :

L'utilisation de #line est très utile pour les pré-processeurs qui veulent garder les erreurs signalées dans le code C de l'utilisateur en ligne avec le fichier source de l'utilisateur. C'est ce que font les préprocesseurs Yacc, Lex et (plus chez moi) ESQL/C.

Answer 3

Pour info : g++ propose la macro non standard __PRETTY_FUNCTION__. Jusqu'à maintenant, je ne connaissais pas la __func__ de C99 (merci Evan !). Je pense que je préfère encore __PRETTY_FUNCTION__ lorsqu'elle est disponible pour le scoping de classe supplémentaire.

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

Answer 4

C++20 std::source_location

Le C++ a finalement ajouté une option non macro, et il est probable qu'elle dominera à un moment donné dans le futur lorsque le C++20 sera généralisé :

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

La documentation dit :

constexpr const char* function_name() const noexcept ;

6 Retour : Si cet objet représente une position dans le corps d'une fonction, renvoie un NTBS défini par l'implémentation qui devrait correspondre au nom de la fonction. Sinon, renvoie une chaîne vide.

où NTBS signifie "Null Terminated Byte String".

La fonctionnalité est présente sur GCC 11.2 Ubuntu 21.10 avec -std=c++20 . Il ne l'était pas sur GCC 9.1.0 avec g++-9 -std=c++2a .

https://en.cppreference.com/w/cpp/utility/source_location montre que l'usage est :

main.cpp

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

Compilez et exécutez :

g++ -std=c++20 -Wall -Wextra -pedantic -o main.out main.cpp
./main.out

Sortie :

info:main.cpp:17:int main() Hello world!

__PRETTY_FUNCTION__ vs __FUNCTION__ vs __func__ vs std::source_location::function_name

Répondu à : Quelle est la différence entre __PRETTY_FUNCTION__, __FUNCTION__, __func__ ?

Answer 5

Personnellement, je suis réticent à l'idée de les utiliser pour autre chose que des messages de débogage. Je l'ai fait, mais j'essaie de ne pas montrer ce genre d'informations aux clients ou aux utilisateurs finaux. Mes clients ne sont pas des ingénieurs et n'ont parfois pas de connaissances en informatique. Il m'arrive de consigner ces informations dans la console, mais, comme je l'ai dit, à contrecœur, sauf pour les constructions de débogage ou pour les outils internes. Je suppose que cela dépend de la clientèle que vous avez, cependant.