Y a-t-il un moyen d'accéder aux arguments de la ligne de commande, sans utiliser l'argument à la main? J'ai besoin d'y accéder dans une autre fonction et je préférerais ne pas le transmettre.
J'ai besoin d'une solution qui fonctionne nécessairement sur Mac OS et Linux avec GCC.
6 Réponses :
vous pouvez. La plupart des plates-formes fournissent des variables globales __argc et __argv. Mais encore une fois, je soutiens le commentaire de Zneak.
P.s. Utilisez Boost :: Program_Options pour les analyser. S'il vous plaît ne faites pas cela d'autre manière en C ++.
Je ne pense pas que vous devriez le faire, car le runtime C préparera les arguments et le transmettre dans la principale via int argc, Char ** argv , ne tentez pas de manipuler le comportement en piratage comme il serait en grande partie peu défavorable ou probablement un comportement non défini !! Collez sur les règles et vous aurez la portabilité ... Pas d'autre moyen de le faire autre que de la casser ...
Comme la question dit, il n'a pas besoin d'être portable, il suffit de travailler avec GCC (je ne l'utilise que dans des fichiers source spécifiques à la plate-forme).
Après avoir pensé à cela, ce serait la meilleure solution.
Vous pouvez les copier dans des variables globales si vous le souhaitez.
Y a-t-il une raison quelconque pourquoi faire passer un pointeur sur l'espace déjà consommé est si mauvais? Vous ne recevrez aucune économie réelle d'éliminer l'argument à la fonction en question et vous pouvez définir un affichage intéressant de feux d'artifice. La plinthe autour de la pile d'appels principale () avec un piratage créatif finit généralement dans un comportement non défini ou de la dépendance sur le comportement spécifique du compilateur. Les deux sont mauvais pour la fonctionnalité et la portabilité respectivement.
Gardez à l'esprit que les arguments en question sont les pointeurs aux arguments, ils vont consommer de l'espace, peu importe ce que vous faites. La commodité d'un index d'entre eux est aussi bon marché que Tailleof (int), je ne vois aucune raison de ne pas l'utiliser.
On dirait que vous optimisez de manière assez agressive et prématurément, ou vous êtes coincé de devoir ajouter des fonctionnalités dans le code que vous ne voulez vraiment pas gâcher. Dans les deux cas, faire des choses de manière classique sauvera le temps et les problèmes.
Je n'essaie pas d'optimiser, j'essaie d'accéder aux arguments de ligne de commande en dehors de la principale.
in Linux, vous pouvez ouvrir Plus de solutions sont disponibles ici: http://blog.linuxgamepublishing.com/2009/10/12/argv-and-argc-and-just-how-a-get-them/
Ouais, c'est brut et peu déficit, mais si vous résolvez des problèmes pratiques, vous ne vous souciez pas. / proc / self / cmdline (en supposant que / proc avant principal () - par exemple dans un constructeur global - comme autrement, il vaut mieux les transmettre via Global Vars).
Je ne sais pas comment le faire sur Macos, mais je soupçonne que je vais décrire ici peut être porté à MacOS avec un peu de lecture croisée.
sur Linux, vous pouvez utiliser le soi-disant ". init_array "section du binaire ELF, pour enregistrer une fonction qui est appelée lors de l'introtallation du programme (avant la principale () est appelée). Cette fonction a la même signature que la fonction principale normale () principale, elle renvoie "Void". Ainsi, vous pouvez utiliser cette fonction pour mémoriser ou traiter argc, argv [] et EVP [].
Voici un code que vous pouvez utiliser: PPS: gardez à l'esprit Au cours de cette exécution de ce programme très précoce, de nombreux sous-systèmes ne sont pas encore complètement initialisés - j'ai essayé des routines d'E / S libc, elles semblent fonctionner, mais ne comptez pas sur elle - même des variables glovantes pourraient ne pas encore être construites, etc ... < / p>
Je crois fermement que tu devrais les passer. J'estime que compter sur un État global n'est jamais vraiment une bonne chose.
Les transmettre ne doivent pas nécessairement être horriblement compliqués - vous pouvez les traiter dans une structure interne args-and-options, et n'abandonnez qu'une seule chose autour, en évitant les boucles / vérification / vérification de l'ArgC + ARGV.
Un exemple de commentaire de JEFROMI peut être vu dans le fonctionnement de l'utilitaire gengeopt de GNU. Cette procédure est la voie à suivre et cet outil devrait être pris en compte.
En tant que contrepoint, supposons que vous écriviez une bibliothèque souhaitant prendre en charge les paramètres de ligne de commande optionnels. L'interface de la bibliothèque est plus propre si elle ne nécessite pas
argc etargv pour être envoyé explicitement. En tant que autre point de données, nous avons déjà un accès mondial aux variables d'environnement envoyées, qui ont une sensation similaire aux paramètres de ligne de commande. Par exemple, la commande shellopt = yes ./my_cmd se sent similaire à./ my_cmd -opt = oui .