Discussion :

[nekcorp]

Bonjour,

Je souhaite savoir s'il est possible lorsque l'on se trouve dans une classe de récupérer le nom de cette classe ainsi que la méthode dans laquelle on se trouve.

Mon but est de de récupérer ces deux informations pour afficher un message d'erreur et que je sache rapidement où j'ai un soucis.

Actuellement je rentre en dur dans ma fonction qui renvoie le message, le nom de la classe et de la méthode ou je me trouve. Ce que je souhaite c'est savoir s'il existe nativement quelque chose qui permet de récupérer ces informations.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class myClass
{
     public:
         void afficher();
};
 
void myClass::afficher()
{
     // ici je souhaite récupérer le nom myClass et la méthode afficher
    errorMessage(className, methodName, msg);
 
    //Actuellement je rentre en dur le nom de la class et le nom de la method
    errorMessage("myClass", "afficher", msg);
}

Merci d'avance pour vos réponses.

[dalfab]

Bonjour,

Tu peux retrouver le nom de la fonction courante en utilisant __function__.
Quand à la classe courante, tu peux l'obtenir par son type_info en faisant typeid(*this).name().

[nekcorp]

Merci

par contre tu serais me dire pourquoi j'ai un chiffre 7 devant le nom de ma classe ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <iostream>
#include <typeinfo>
 
class myClass
{
    public:
        void afficher();
};
 
 
void myClass::afficher()
{
    std::cout << "Call afficher !" << std::endl;
 
    std::cout << typeid(*this).name() << std::endl;
 
    std::cout << __FUNCTION__ << std::endl;
}
 
int main()
{
    myClass theClass;
    theClass.afficher();
 
    return 0;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Call afficher !
7myClass
afficher

J'ai l'impression que c'est la taille du nom de la classe. J'ai modifié le nom de la classe et ça à l'air de se confirmer, le 7 est passé à 10 et le nom de ma classe fait 10 caractères

[koala01]

Salut,

Pourquoi n'utiliserais tu pas, tout simplement, les assertions

Il s'agit là d'une des rares techniques issues du C que vous me verrez plébisciter à chaque fois que j'en aurai l'occasion, il s'agit donc d'en profiter

L'idée générale est d'inclure le fichier <cassert> et d'utiliser la macro assert(condition_devant_etre_vraie) pour repérer les éventuelles préconditions qui ne seraient pas remplies.

Pour info, une précondition est -- en programmation "par contrat" -- une condition qui doit impérativement être (vérifiée et) validée au grand plus tard au moment où la fonction commence à s'exécuter. Ce sont, pour faire "aussi simple que possible", entre autres, toutes les conditions que les paramètres transmis à la fonction devront respecter pour que la fonction soit en mesure de fournir un résultat attendu et cohérent

Toujours dans le soucis de simplifier les choses, on peut dire qu'une précondition mettra en avant les problèmes liés à la programmation: c'est parce que l'utilisateur d'une fonction n'a -- a priori -- pas fait toutes les vérifications nécessaires sur les données qu'ils s'apprête à transmettre à la fonction que le problème survient, et c'est l'une des causes principales de bugs.

L'utilisation générale des assertions pourrait prendre une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void laFoncitonQuiNousInteresse(Type param){
    assert(laCondition_requise_pour_param);
    /* la suite du code */
}

Accessoirement, pour rendre le message affiché en cas de problème, on peut améliorer un peu les choses en utilisant une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void laFoncitonQuiNousInteresse(Type param){
    assert(laCondition_requise_pour_param && "un message explicite désignant le problème");
    /* la suite du code */
}

Ainsi, un code qui pourrait être aussi simple que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <cassert>
#include <iostream>
#include <cmath>
float squareRoot( float value){
    /* Pour rappel: on ne peut calculer la racine carrée que
     * pour les valeurs strictement positive
     */
    assert(value> 0.f && "invalid value dectected");
    return std::sqrt(value);
}
int main(){
        std::cout<<"this will work :"<<squareRoot(3.1415926)<<"\n";
        std::cout<<"and assertion wil fail here"<<squareRoot(.0f)<<"\n";
}

nous présentera à l'exécution un résultat proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
a.exe
this will work :1.77245
and assertion wil fail hereAssertion failed: value> 0.f && "null value dectected", file main.cpp, line 5

(==>voici la preuve <==)

Il y a de nombreux avantages à travailler de cette manière, parmi lesquels on peut citer:

Le fait que le programme plantera systématiquement (en mode debug) si la condition imposée par l'assertion n'est pas respectée. Il n'est en effet jamais bon de laisser tourner un programme si une précondtion n'est pas remplie, car autrement, on se retrouve dans une situation dans laquelle on ne peut plus faire confiance au résultat que l'on obtient, lorsque "le hasard" veut que l'on obtienne malgré tout un résultat pouvant "passer pour être correct"

Le message affiché dans la console va directement t'indiquer non seulement quelle condition n'est pas remplie, mais également le fichier et -- cerise sur le gâteau -- la ligne à laquelle cette condition se trouve dans ton code.

L'utilisateur de ta fonction (comprend: celui qui décide de faire appel à la fonction en lui donnant une valeur qu'il n'a pas "suffisamment vérifiée") n'aura pas d'autre choix que de corriger le problème, car il ne pourra pas aller plus loin

Tu peux, au besoin (et si tu n'applique pas TDD) placer un breakpoint sur ton assertion, de manière à retrouver plus facilement l'origine de la donnée invalide.

La macro peut être désactivée en définissant le symbole NDEBUG une fois que tu es sur que tous les appels à la fonction garantissent que les valeurs correctes sont transmises. Lorsque ton code passe "en production", elle sera simplement transformée en "no op": il n'y aura aucune instruction de test "résiduelle" dans le code binaire exécutable qui sera envoyé en production

Cela fonctionne pour tous les types de fonctions: que ce soit des fonctions libres, des fonctions membres d'une classe, des fonctions virtuelles, ou même des fonctions template

Accessoirement, depuis C++11, tu peux également utiliser static_assert, qui fonctionne sensiblement sur le même principe, mais qui vérifie les conditions imposées aux constantes de compilation au moment de la compilation.

Après, bien sur, il y a tous les cas où l'information "invalide" que l'on manipule vient "d'ailleurs" (comprends: d'un serveur qui ne répond pas, d'un utilisateur du programme qui introduit une information incorrecte, ou que sais-je)

Ce sont des cas que l'on ne peut pas se permettre d'ignorer, tout en espérant qu'ils ne se présenteront jamais (et en sachant qu'il finiront forcément par arriver, du fait de la loi de Murphy ' )

Dans ces cas là, l'idéal est d'avoir recours au système d'exception: si une condition "extérieure" n'est pas remplie, le mieux est encore de lancer une exception et, dans l'idéal, de faire en sorte que cette exception soit spécifique au problème rencontré.

Cette manière de travailler nous permettra de "remonter la pile d'appels" jusqu'au moment où nous serons effectivement en mesure de traiter le problème (à l'aide d'un bloc try ... catch) et d'y apporter (potentiellement) une solution.

Quoi qu'il en soit, il faut te dire que cela ne sert à rien d'afficher un message d'erreur si tu n'est pas en mesure de résoudre le problème indiqué. Il peut, bien sur, être intéressant d'inscrire le problème dans un log, mais, s'il n'est pas résolu, cela ne te permettra pas d'obtenir un résultat cohérent et -- surtout -- fiable

Les assertions et les exceptions par contre te permettent de permettre de mettre en place une procédure susceptible de t'aider à apporter une solution.

[Astraya]

Merci

par contre tu serais me dire pourquoi j'ai un chiffre 7 devant le nom de ma classe ?

Typeid n'offre aucune garantie quand a la valeur retourné, elle dépends entièrement de ce que fait le compilateur avec les noms de symbole.
Pendant la compilation c'est noms sont "manglé" et doivent être "démanglé" ! Le mangling est le résultat d'une étape de compilation nécessaire au compilateur pour identifier ta fonction/classe de façon unique en lui ajoutant des informations.
Pour démanglé, tu as le header 'cxxabi.h' de mémoire et pour windows c'est avec l'API Win32.

[Bktero]

Depuis C++ 20, on peut utiliser https://en.cppreference.com/w/cpp/ut...ource_location

[nekcorp]

Merci pour vos réponses, je vais réussir à me débrouiller maintenant.

[Suryavarman]

Si tu veux j'ai eu aussi ce soucis. Voici mon bout de code:
https://framagit.org/Suryavarman/ma/...de/API/Error.h

J'en suis asse content.

La partie importante qui t'intéresses doit être ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
#if defined(__cpp_lib_source_location)
    #include <source_location>
#endif
 
#if defined(__cpp_lib_source_location)
    #define M_FUNCTION_NAME \
        std::source_location::current().function_name()
#elif MA_COMPILER == MA_COMPILER_GNUC
    #define M_FUNCTION_NAME \
        __PRETTY_FUNCTION__
#elif MA_COMPILER == MA_COMPILER_CLANG
    #define M_FUNCTION_NAME \
        __PRETTY_FUNCTION__
#elif MA_COMPILER == MA_COMPILER_MSVC
    #define M_FUNCTION_NAME \
        __FUNCSIG__
#else
    #error("La définition automatique du nom de la fonction courante n'est pas gérée pour le compilateur courant.")
#endif