Utilisation de __FILE__, __LINE__ et __FUNCTION__ en C ++

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

Je suis principalement préoccupé par le fait de fournir à l'utilisateur des données trompeuses (par exemple, le fait de signaler le numéro de ligne ou la fonction incorrect à la suite d'une optimisation) ou de réduire les performances.

En fait, je peux faire confiance __FILE__, __LINE__et __FUNCTION__à toujours faire la bonne chose?

__FUNCTION__n'est pas standard, __func__existe en C99 / C ++ 11. Les autres ( __LINE__et __FILE__) sont très bien.

Il signalera toujours le bon fichier et la bonne ligne (et la fonction si vous choisissez d'utiliser __FUNCTION__/ __func__). L'optimisation est un non-facteur car il s'agit d'une expansion de macro au moment de la compilation; il n'affecter les performances en aucune façon.

Dans de rares cas, il peut être utile de changer la ligne donnée par __LINE__autre chose. J'ai vu que GNU configure le fait pour certains tests pour signaler les numéros de ligne appropriés après avoir inséré du vaudou entre des lignes qui n'apparaissent pas dans les fichiers source d'origine. Par exemple:

#line 100

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

#line 100 "file.c"

Ce n'est que rarement utile. Mais si c'est nécessaire, je ne connais aucune alternative. En fait, au lieu de la ligne, une macro peut également être utilisée, ce qui doit entraîner l'une des deux formes ci-dessus. À l'aide de la bibliothèque de préprocesseurs boost, vous pouvez incrémenter la ligne actuelle de 50:

#line BOOST_PP_ADD(__LINE__, 50)

J'ai pensé qu'il était utile de le mentionner puisque vous avez posé des questions sur l'utilisation de __LINE__et __FILE__. On n'a jamais assez de surprises en C ++ :)

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

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

Pour info: g ++ propose la macro non standard __PRETTY_FUNCTION__. Jusqu'à présent, je ne connaissais pas C99 __func__ (merci Evan!). Je pense que je préfère toujours __PRETTY_FUNCTION__ lorsqu'il est disponible pour la portée de la 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. */
}

Personnellement, je suis réticent à les utiliser pour autre chose que pour le débogage des messages. 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 ne maîtrisent parfois pas l'informatique. Je pourrais enregistrer ces informations sur la console, mais, comme je l'ai dit, à contrecœur, sauf pour les versions de débogage ou pour les outils internes. Je suppose que cela dépend de la clientèle que vous avez, cependant.

C ++ 20 std::source_location

C ++ a finalement ajouté une option non-macro, et elle dominera probablement à un moment donné dans le futur lorsque C ++ 20 se généralisera:

• 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 * nom_fonction () const noexcept;

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

où NTBS signifie "Chaîne d'octets terminée par une valeur nulle".

Je vais essayer quand le support arrivera à GCC, GCC 9.1.0 avec g++-9 -std=c++2ane le supporte toujours pas.

https://en.cppreference.com/w/cpp/utility/source_location l' utilisation des revendications sera comme:

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

Sortie possible:

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

__PRETTY_FUNCTION__vs __FUNCTION__vs __func__vsstd::source_location::function_name

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

Je les utilise tout le temps. La seule chose qui m'inquiète est de donner l'adresse IP dans les fichiers journaux. Si vos noms de fonctions sont vraiment bons, vous pouvez rendre un secret commercial plus facile à découvrir. C'est un peu comme l'expédition avec des symboles de débogage, mais plus difficile à trouver. Dans 99,999% des cas, rien de mauvais n'en sortira.