84 votes

Est-il sûr de renommer argc et argv dans la fonction principale ?

De nombreux programmes utilisent des noms standard pour un certain nombre d'arguments et de tableaux de chaînes. Le prototype de la fonction main se présente comme suit int main(int argc, char *argv[]); . Mais est-ce que je vais casser quelque chose si je choisis des noms personnalisés pour ces variables ?

Par exemple int main(int n_of_args, char *args[]);

Dans le contexte du compilateur, tout va bien. Ces variables sont locales pour la fonction principale, elles peuvent donc avoir n'importe quel nom. Et le code simple se construit et s'exécute parfaitement. Mais ces noms peuvent être utilisés par le préprocesseur. Est-il donc prudent de renommer ces arguments ?

PS Personnellement, je trouve ces noms mauvais, car ils se ressemblent beaucoup et ne diffèrent que par une lettre. Mais TOUT le monde les utilise pour une raison ou une autre.

22 votes

Oui, en toute sécurité.

0 votes

Oui, c'est tout à fait sûr ! !!

55 votes

Comme toutes les réponses l'indiquent, oui, c'est sûr. Mais s'il vous plaît, ne le faites pas. Tout le monde sait ce que argc y argv sont. n_of_args y args pourrait être plus clair pour quelqu'un qui ne connaît pas le C ou le C++ - mais ce n'est pas votre public.

123voto

dbush Points 8590

Oui, c'est sûr, à condition d'utiliser des noms de variables valides. Il s'agit de variables locales, dont le champ d'application ne dépasse pas la zone main fonction.

De la section 5.1.2.2.1 de la C standard :

La fonction appelée au démarrage du programme est nommée main . L'implémentation ne déclare aucun prototype pour cette fonction. Elle doit être être définie avec un type de retour de int et sans paramètres :

int main(void) { /*  ... */ }

ou avec deux paramètres (appelés ici argc y argv , t peuvent être utilisés, car ils sont locaux à la fonction dans laquelle ils sont déclarés. déclarées ):

int main(int argc, char *argv[]) { /* ...   */ }

ou équivalent ; ou d'une autre manière définie par la mise en œuvre

Ceci étant dit, l'utilisation d'un produit autre que le argc y argv pourrait perturber les personnes qui lisent votre code et qui sont habituées aux noms conventionnels de ces paramètres. Il est donc préférable de privilégier la clarté.

39voto

Kundor Points 101

Les noms argc y argv étaient en fait imposées par la norme C++ avant C++11. Elle stipulait :

Toutes les implémentations doivent autoriser les deux définitions suivantes de main :

int main ()

et

int main ( int argc , char * argv [])

et a poursuivi en discutant des exigences en matière de argc y argv .

Ainsi, techniquement, tout programme utilisant des noms différents n'était pas conforme à la norme et le compilateur était autorisé à le rejeter. Aucun compilateur ne l'a fait, bien entendu. Voir ce fil de discussion sur comp.std.c++ ou la section 3.6.1 du ce projet de norme C++03 .

Il s'agit très certainement d'un simple oubli, qui a été modifié dans le C++11, qui dit à la place

Toutes les implémentations doivent permettre à la fois

  • une fonction de () renvoyant int et
  • en fonction de ( int , pointeur sur pointeur sur char ) en retournant int

en tant que type de main (8.3.5). Sous cette dernière forme, pour les besoins de d'exposition, le premier paramètre de la fonction est appelé argc a est appelé argv ,

29voto

πάντα ῥεῖ Points 15683

Bien sûr, vous pouvez renommer ces paramètres en toute sécurité comme vous le souhaitez

int main(int wrzlbrnft, char* _42[]) {
}

Les noms sont inscrits dans le sable. Ils n'ont aucune influence sur le code finalement compilé.


La seule chose qui importe est que les types de paramètres de la déclaration et de la définition correspondent réellement.

La signature du main() est intrinsèquement déclarée comme

int main(int, char*[]);

si vous devez les utiliser dans une implémentation, vous devrez les nommer. Les noms utilisés n'ont en fait aucune importance, comme nous l'avons déjà mentionné.

5 votes

Seuls certains identificateurs sont "écrits dans le sable" comme vous le dites. les noms de fonctions ne le sont certainement pas.

1 votes

@SteveCox "Les noms de fonction ne le sont certainement pas. En fin de compte, c'est le cas. Juste des nombres de grains de sable :-P ...

3 votes

Ok, mais sérieusement, après la compilation, le code objet contient toujours des noms de fonctions, sinon la liaison ne fonctionnerait pas.

14voto

coredump Points 1988

Oui. C'est sûr, ça a l'air bizarre, mais ça ne casse rien.

7voto

Steve Summit Points 16971

Oui, il est prudent d'utiliser des noms différents.

Personnellement, je ne le recommanderais pas, étant donné que la méthode traditionnelle d'évaluation de l'impact sur l'environnement n'a pas été utilisée. argc y argv sont si largement connus et familiers à tous les autres programmeurs C qui pourraient un jour travailler avec votre code. À long terme, l'utilisation de vos propres noms, spéciaux et différents, causera bien plus de confusion et/ou de frustration parmi vos lecteurs qu'elle ne vous sauvera jamais parce que vous préférez vos noms.

"Quand on est à Rome, on fait comme les Romains.

0 votes

Pourtant, il existe quelques scénarios assez évidents qui nécessitent l'utilisation de noms différents, l'un d'entre eux étant l'initialisation de GLUT, glutInit(&argc, argv) où les arguments doivent être déclarés et initialisés différemment, afin de ne pas laisser GLUT manger les arguments de la ligne de commande, à moins que nous ne le voulions. Lien SO

0 votes

@user3078414 Exemple intéressant, mais je ne vois pas en quoi il indique le nom des variables. Selon les exemples de l'autre question, nous pourrions tout aussi bien écrire int dummyargc = 1; char *dummyargv[1] = {(char*)"Something"}; glutInit(&dummyargc, dummyargv); .

0 votes

Merci, @steve-summit. Il se trouve que certaines documentations d'API sont mal orientées, c'est pourquoi ce fil de discussion est très utile car il met en évidence les points suivants argc argv comme le fait votre réponse contributive. J'ai simplement mis mon commentaire en exemple pour montrer qu'il est préférable d'utiliser deux noms différents. Voici le Lien SO

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X