Qu'est-ce qui est considéré comme optimal pour faire référence au nom d'un programme? J'ai vu: ainsi que: Je sais que la deuxième approche me donnera Mais y a-t-il autre chose, qui rend une approche supérieure à l'autre? ./ myProg plutôt que myProg lorsque le programme n'est pas appelé à partir de $ chemin et que la première approche garantira une consistance concernant le nom du programme.
7 Réponses :
Le premier est supérieur au plus tard lorsque vous n'avez pas argv à portée de main.
Est-ce que cela fait une si grande différence? Je ne pense pas argc et argv coûte trop cher
ah. Je vois ce que tu veux dire maintenant. ouais, fait un sens parfait
Je reçois votre point, mais dans votre exemple, vous créez essentiellement une variable globale. Si vous avez besoin du nom de programme, passez-le (ARGV) comme paramètre pour saluer () et votre problème est résolu.
Eh bien Oui, fonctionne pour quelques méthodes, si le nom est nécessaire à plusieurs endroits et la plupart des fonctions ont déjà une grande liste de paramètres, en utilisant une autre est ridicule lorsque la constante globale est disponible. Dans les deux cas, je pense que Jonhcatfish est une meilleure alternative.
@Support: Si le nom est nécessaire à plusieurs endroits, éventuellement ce que vous devriez passer (ou faire de la tâche globale si nécessaire) est une sorte d'objet LOGGER, plutôt que du nom du programme.
Je comprends. Je n'ai jamais eu à faire ça, mais je comprends. Je déteste vraiment des listes d'arguments très longues, car je finis toujours par faute à bout et envoyez le mauvais ordre.
dépend si argv est dans la portée ou non ...
La deuxième approche est supérieure lorsque vous avez plusieurs liens. Dans * Nix Systems, le comportement dépend parfois de la manière dont vous appelez un programme. Donc, codage dur, le nom du programme serait clairement un problème - cela ne pourrait jamais vérifier cela.
Qu'est-ce que cela signifie "comportement dépend de la manière dont vous appelez un programme"? Je ne peux pas vraiment avoir du sens.
@Guest: Par exemple, gcc et g ++ peut être le même exécutable, qui vérifie le nom utilisé et modifie les options de liaison en conséquence. Je ne me souviens pas si c'est réellement ou non.
Exemple: Par défaut, Grep imprime les lignes correspondantes. De plus, trois programmes variants Egrep, FGREP et RGREP sont disponibles. Egrep est la même chose que Grep -e. FGREP est la même chose que Grep -f. Rgrep est la même chose que Grep -R.
ah. jamais entendu parler de ce concept avant, a du sens, bien que
Certains programmes examinent ARGV [0] pour déterminer comment ils devraient se comporter. Par exemple, ButubyBox implémente une foule d'utilitaires UNIX, et elle est normalement installée en tant que / bin / buccade, avec de nombreux liaisons symboliques pointant sur celui-ci: / bin / ls, par exemple, indiquerait / bin / butée, et lorsque vous exécutez " LS 'Il gère Busybox qui détermine ensuite qu'il doit se comporter comme LS.
Un autre exemple est VI et View , qui est la version en lecture seule de VI , mais quel est le même code et exactement exécutable. L'appelant Voir Ouvre juste le fichier en lecture seule.
J'ai essayé de tirer le meilleur parti des deux mondes:
extern char const * program_name;
Pas mal. Side la question La question est meilleure en répondant à "à la fois" mais pas mal.
La deuxième approche pourrait vous donner également des chaînes telles que La première approche "corrige" le nom du programme à ce que le programmeur souhaitait, quelle que soit l'utilisateur renommé le fichier exécutable ou symbolisé (ou même hardlinked) / usr / bin / myProg si vous l'avez exécuté de cette façon; BasEname doit donner le nom de l'exécutable (que vous pourriez penser comme le nom de votre programme) ... À moins que ce ne soit ligondelé ... (dans ce cas, vous avez le nom du lien ... qui pourrait être utilisé faire des choix de genre dans le comportement du programme).
Oui, j'ai utilisé des produits où il semble que vous avez plusieurs exécutables, mais en réalité, il n'en est qu'un avec de multiples liens. Cela peut sembler fou, mais c'est un bon moyen de conserver plusieurs outils de synchronisation à travers plusieurs révisions.
J'utilise habituellement De même, si vous découvrez à l'avenir que vous souhaitez compiler votre programme sous différents noms avec différentes options, pour donner différentes versions, souhaitez-vous envelopper un L'exception peut être que si les instructions d'utilisation sont un extrait d'un manuel ou d'une autre documentation, vous souhaitez éventuellement avoir du mal au nom du programme. Mais alors vous n'utiliseriez probablement pas le implémentations n'a pas besoin de fournir Au fait: P> argv [0] code> ou basseName (argv [0]) code> si possible. Depuis le POV de l'utilisateur, je pense que s'ils renomment ou sur le hardlink un exécutable (ou quelqu'un d'autre le fait pour eux), ils veulent ensuite des messages à partir de celui-ci de comparaître sous le nom qu'ils utilisent, non sous un autre nom, il a été compilé comme étant, qu'ils peuvent ou non connaître. #Ifndef code> autour de ce #define code> et assurez-vous qu'il est défini via la ligne de commande compiler: -dprogram_name = myProg_demo code> ou voulez-vous juste le faire et ça marche? #define code> non plus. P> argv [0] code>, donc pour le meilleur portable Les pratiques gèrent ce cas aussi. Encore une fois, si votre système ne le fournit pas, l'utilisateur n'allait probablement pas voir des messages sur une sorte de terminal, non plus. P> #define PROGRAM_NAME "myprog"
puts("this is " PROGRAM_NAME);
basename n'est pas portable. C'est seulement requis par Posix (à Libgen.h). De plus, gardez à l'esprit que cela peut modifier la chaîne que vous le donnez et que le pointeur retourné peut être un décalage à partir du pointeur d'origine ou d'une chaîne allouée statiquement allouée (alors n'essayez pas de libérer ce qu'il vous donne, et don 't essayer de libérer ce que vous a donné it immédiatement après). Je l'éviterais à moins que vous soyez à 100% sûr de comprendre la gestion de la mémoire impliquée et que vous vous souciez de la portabilité.
Par conséquent, "si possible". Mais vous avez raison que basename (argv [0]) est lui-même une expression légèrement douteuse, il suppose que vous ne prévoyez pas d'utiliser à nouveau les arguments.
Cela ne répond pas exactement à votre question pour la programmation des meilleures pratiques, mais je pense que vous devriez également garder à l'esprit quel est le meilleur pour l'utilisateur.
Personnellement, je préfère les programmes se référant à eux-mêmes à l'aide de La seule situation où je préférerais qu'un nom de programme codé est lorsque j'utilise des applications GUI. Je ne voudrais pas voir "~ / foo / bar.pl" comme titre de fenêtre. argv [0] , c'est-à-dire que la commande que j'appelle, et non un nom aléatoire auquel le codeur est corrigé dans le programme. Quelques exemples où un nom codé est gênant ou du moins pas utile:
$ PATH
Si vous voulez une constante, utilisez une constante (c'est-à-dire au niveau global,
const char * consons programme_name = "myProg"; ). Cela garantira que la chaîne est uniquement stockée une fois en mémoire.