En C et C ++, la méthode principale contient le nom de fichier à la première position du tableau à argv [0]. En Java, cependant, le nom de fichier n'est pas inclus dans le tableau de chaînes args.
Y a-t-il une raison pratique à cela? Je comprends que cela rend l'itération via des arguments de ligne de commande basée sur 0 au lieu de 1, mais y a-t-il un avantage? Le nom de fichier a-t-il simplement été jugé inutile?
Réponses:
Dans certains cas, un programme peut être exécuté de différentes manières et présenter un comportement différent sur la façon dont il est appelé. Si vous appelez vimas vi, il s'exécute en mode de compatibilité. Parfois, c'est pour essayer de maintenir une version de plusieurs programmes connexes - par exemple mailqet newaliasessur de nombreux systèmes Unix sont un lien vers sendmailafin que ces programmes restent synchronisés)
Les programmes Java sont généralement appelés comme:
% java -jar foo.jar args % java Foo args
La première version est l'endroit où vous avez un fichier manifeste qui indique la classe principale, la deuxième version exécute la méthode principale dans la classe Footrouvée dans le chemin de classe.
Les informations présentées pour Java sont soit un chemin d'accès au pot, soit le nom de la classe invoquée.
L'emplacement du pot n'est pas suffisamment important pour être quelque chose à coder (et ne faisait en fait pas partie des spécifications d'origine). Un Jar peut être vraiment nommé, et comprend souvent des numéros de version. De plus, il n'y a aucune garantie que la classe a même été stockée dans un .jar (elle aurait pu être extraite).
L'appel d'une application Java avec -jarn'a qu'une seule façon de la saisir: la classe définie dans le manifeste. Aucun changement de nom ne peut être effectué.
L'autre option, de l'invoquer avec le nom de classe pointe directement vers l'unité d'exécution. De plus, il ne peut pas être nommé multiplier - vous ne pouvez pas avoir Bar.classle code car class Foocela ne fonctionne pas de cette façon.
Cela devrait montrer qu'il n'y a vraiment aucun intérêt à transmettre les informations de argv[0]dans le sens C à une application Java - ce sera java, sans signification et arbitraire, ou le nom de la classe qui est invoquée (que vous exécutez déjà du code de (vous pourriez faire quelque chose comme getClass().getEnclosingClass().getName()si vous étiez désespéré ...)).
Il y a un point ici, vous pouvez définir plusieurs méthodes Main dans les classes dans un .jar ou sur le chemin de classe. Et vous pourriez les faire se comporter différemment comme s'il y avait une série de déclarations if basées sur ce qui argv[0]était.
Dans le passé, j'avais un code semblable à celui java -cp Foo.jar com.me.foo.Testqui invoquait la Testméthode Main de la classe plutôt que celle définie dans celle définie dans le manifeste.
java com.me.Foocomme ligne de commande, la méthode com.me.Foo.main(String...)est invoquée. Il n'y a pas de chemin aux alentours. Et je sais que c'est Foo qui est invoqué - il n'y a aucune raison de coller cela dans argv. Ce serait une information purement redondante. Bien sûr, cela pourrait être dans la superclasse, mais j'ai l'opportunité triviale de l'intercepter avec les informations souhaitées sur ce qu'était l'invocation de la ligne de commande - pas besoin de le mettre dans argv.
en fait, il n'y a aucun avantage, cela dépend vraiment de la syntaxe du langage de programmation que vous utilisez s'il est basé sur 0 ou 1. la variable (que vous appelez nom de fichier) dépend également de la langue, elle peut être différente dans d'autres langues, il suffit de suivre la syntaxe correcte de la langue que vous utilisez.
foo.exe.