Bonjour,
voila je suis en train de réaliser une lib en C++ qui va afficher des logs. Et cette lib a besoin de connaitre le nom du programme pour créer un fichier de la forme <nom du programme>.log. Le probleme c'est que je ne peux pas récupérer le nom du programme via le argv[0]. Connaissez vous une autre méthode ?
Merci d'avance
Cela dépend de la plate-forme sur laquelle tu tournes. Je ne pense pas qu'il existe une méthode portable en dehors de argv.
j'ai vu qu'on pouvait récupérer les variables d'environnement, alors j'ai fait ca sur linux et ca marche, J'imagine que sur windows ca marche sur le meme principe non ?
Pourquoi pas ?Envoyé par cosmoff
Oui. Mais comme l'a précisé pm42, les solutions envisageables sont spécifiques à la plateforme, et tu n'avais pas précisé pour laquelle tu développais.
Sous Windows, tu peux par exemple utiliser GetCommandLineW() pour obtenir un pointeur vers la chaîne de la ligne de commande du processus courant, puis CommandLineToArgvW() pour créer une liste de pointeurs vers les différents arguments qu'elle contient.
Parce que argv n'est qu'un argument de la fonction main() des programmes qui utiliseront la bibliothèque, laquelle ne peut donc pas le connaître a priori.
La chaîne de la ligne de commande doit donc être récupérée d'une autre manière, soit en s'imposant de coder les programmes de sorte qu'ils la passent à la bibliothèque dans leur main() (trop lourd), soit en la demandant au système.
...
Comme ici il s'agit plutôt de récupérer le nom du programme que les arguments qu'on lui passe, il faudrait aller voir du côté des fonctions du type GetModuleFileName.
En général, on stocke les infos récupérées comme ça dans une globale si d'autres codes en ont besoin. L'ensemble du code a bien accès à stdout/stderr sans qu'on leur passe explicitement et c'est exactement comme cela que c'est fait.
Si je n'ai pas été assez clair :
- soit on passe explicitement l'info depuis le programme, auquel cas on s'impose d'écrire du code spécifique pour la stocker depuis le main() et du code spécifique pour la récupérer là où on l'utilise
- soit on utilise l'info qui existe implicitement, mais on doit demander au système de nous l'indiquer (il existe des astuces pour en calculer directement d'adresse, mais cela reste du bricolage sans aucune garantie de pérennité).
Ok, mais la bibliothèque va être appelée par un programme qui, lui, connaîtra les arguments de la ligne de commande et pourra donc les communiquer le cas échéant.
A mon avis, cette histoire de bibliothèque permettant de produire "en automatique" de la log est une fausse bonne idée.
Autant stocker un identifiant dans le code source, permettant d'identifier le programme lors des appels des fonctions de la log.
On ne comprend pas bien ce que vous voulez faire avec le gestionnaire de log.
Si de toutes façons vous avez besoin d'une compilation du programme pour y faire appel, c'est de toutes façon non automatique, donc rajouter un identifiant en dur n'est qu'une opération supplémentaire à effectuer.
De plus, le nom du programme seul n'identifiera jamais le programme qui s’exécute en mémoire.
Si vous lancez deux fois le programme, la log va mélanger les données des deux programmes, à moins d'identifier le processus qui correspond à ce programme (donc son premier lancement).
C'est une usine à gaz quand même...
Ca en vaut la peine ?
Bonjour, et Merci.
Oui, c'est d'ailleurs ce qu'on fait dès qu'on a des arguments en ligne de commande ou un fichier de configuration : on lit, on analyse et on met les paramètres dans des globales ou on les passe aux librairies qu'on utilise.
Je ne vois pas trop pourquoi on complique les choses ici. Et je préfère même ne pas répondre à certains messages tellement on est loin, loin...
La finalité d'une bibliothèque, c'est de simplifier le travail du développeur des programmes qui y font appel.
Rendre nécessaire la communication à la bibliothèque des arguments de la ligne de commande au niveau du main() (et uniquement à cet endroit) quand on peut assez simplement s'en passer, c'est compliquer inutilement ce travail.
Dernière modification par PA5CAL ; 17/03/2019 à 12h55.
