J'ai toujours pensé qu'un prototype de fonction doit contenir les paramètres de la fonction et de leurs noms. Cependant, je viens d'essayer cela: et cela a fonctionné! J'ai même essayé de compiler avec une extrême prudence: p> et cela a toujours fonctionné. Donc, ma question est que si vous n'avez pas besoin de noms de paramètres dans des prototypes de fonction, pourquoi est-il si commun de le faire? Y a-t-il un but à cela? At-il quelque chose à voir avec la signature de la fonction? P> p>
6 Réponses :
Les noms de paramètres sont complètement facultatifs et n'ont aucun effet sur la compilation. Ils peuvent être placés là-bas pour une meilleure lisibilité du code. P>
Vous n'avez pas besoin de noms de paramètres dans les déclarations. Ils sont purement de la documentation.
Vous n'avez même pas besoin de noms dans les définitions: p> compile tout simplement bien en C ++ (mais pas en C). Ceci est parfois utile pour par exemple. héritage, surcharge, pointeurs de fonction. p> p>
Si vous faites une telle fonction, sans spécifier le nom du paramètre, comment l'accédez-vous? Si vous ne pouvez pas y accéder, alors pourquoi le faire à la première place?
Vous avez besoin que les noms dans la définition de la définition utilisent ce paramètre.
Vous ne pouvez pas y accéder. Vous pouvez le mettre dans au moins deux situations: (1) pour la compatibilité en avant, au cas où vous voudriez commencer à l'utiliser plus tard sans avoir à mettre à jour tous les sites d'appel; (2) Lorsque vous remplacez une méthode virtuelle, mais vous ne voulez pas inspecter l'argument.
@MisterSIR: Vous ne pouvez pas accéder au paramètre s'il n'a pas de nom. Vous n'utilisez cela que si le paramètre est nécessaire pour être conforme à une interface, mais n'est pas réellement utilisé. Personnellement, j'aime ce style mieux que d'utiliser des noms tels que inutilisé1 code> etc.
Omettre le nom d'un paramètre non utilisé dans la définition a souvent pour effet de supprimer tous les avertissements «paramètres non utilisés» du compilateur.
@MisterSIR: Il existe des situations lorsque vous avez un paramètre que vous n'utilisez pas réellement. Il est utilisé uniquement pour la résolution de la surcharge uniquement. Port Exemple, voir STD :: Fonction avancée. Si vous nommez le paramètre, vous obtiendrez un avertissement
@MisterSir à certaines occasions Vous ne voulez pas y accéder, notamment notre vieil ami Itérateur :: opérateur ++ (int) où l'INT n'est là que là pour indiquer qu'il s'agit d'un opérateur post-incrément.
Vous n'avez pas besoin d'inclure des noms de paramètres dans les prototypes de fonction. Vous avez seulement besoin de la signature complète, qui inclut les types de paramètres et (dans le cas des spécialisations de modèles de fonction) Valeurs de retour.
Cependant, il est toujours courant d'inclure des noms de paramètres afin d'écrire un code auto-documentant. C'est-à-dire une fonction avec cette déclaration: p> est plus facile à comprendre en regardant uniquement le prototype, peut-être que celui-ci: p> De nombreux IDes modernes apparaîtront également les noms de paramètres lorsque vous tapez lorsque vous écrivez le code qui appelle cette fonction. Ils peuvent ne pas être en mesure de contempler ces informations si vous n'incluez pas les noms de paramètres du prototype. P> p>
J'ai toujours pensé qu'une signature de fonction n'inclut pas son type de retour (à moins que ce soit une spécialisation de modèle)
@Mister: Généralement, c'est vrai. Mais int Le cas de spécialisations des modèles de fonction, le type de retour fait partie de la signature.
Non, ce ne sont pas nécessaires et sont principalement ignorés par le compilateur. Vous pouvez même leur donner des noms différents dans différentes déclarations; Ce qui suit est entièrement légal: (le compilateur vérifie que chaque nom n'est utilisé qu'une seule fois dans la même liste d'arguments: la raison de les mettre dans est la documentation: p> int foo (interb bar, bar); code> est rejeté.) p>
Il a beaucoup à voir avec la signature de la fonction.
L'un des avantages de l'utilisation .h des fichiers est que lorsque quelqu'un vient et veut avoir une idée de ce que fait votre programme / API, ils peuvent regarder votre fichier d'en-tête et avoir une idée de quelles opérations sont effectuées , leurs entrées et leurs sorties, comment tout se passe ensemble, etc. p>
si vous deviez rencontrer une méthode comme p> Ceci serait beaucoup moins Teller qu'une méthode avec une signature de dire: p> avec la seconde, vous avez au moins une idée des opérations qui sont effectuées et ce qui se passe. C'est l'idée derrière l'écriture de code auto documentation. P> Si votre intéressé, vous pouvez vérifier le code complet par Steve McConnell. P> P>
Les noms de paramètres ne font pas partie de la signature.
Il y a des scénarios différents. J'ai trouvé cela très utile pour traiter avec héritage code> et
Fonctions virtuelles code>. Si vous utilisez une fonction
virtuelle code> qui génère un avertissement non utilisé en classe, vous pouvez omettre les noms de variables. P>
Je pense que la lisibilité serait bien meilleure si le nom du paramètre est inclus dans le prototype.
Comment cela ajoute-t-il exactement à la lisibilité?
Dans votre cas, vous avez deux paramètres
int code>, sans les noms, comment savoir s'il faut transmettre si
x code> premier ou
y code>?
Dans les fonctions qui ont des noms de paramètres obscur (comme x x et y), comment est-il une différence pour les écrire dans le prototype?
L'ordre des paramètres de votre
ajoutez code> ne sont pas importants et la plupart des gens savent déjà qu'une fonction nommée "Ajouter" ajouterait ses paramètres ensemble sans appliquer la signification aux valeurs, de sorte que les noms ne sont donc pas vraiment important dans cet exemple. Mais envisagez une fonction comme
strtstr code>. La commande est importante. Quel paramètre vient en premier? Ne serait-il pas plus facile de se rappeler si les paramètres avaient des noms distinctifs, tels que
aiguille code> et
HAYSTACK code>, et si votre éditeur vous montrerait ces noms pendant que vous avez écrit votre code pendant que vous avez écrit votre code pendant que vous avez écrit votre code. ou quand il a signalé des erreurs? C'est i> lisibilité.
X et Y pourraient être assez bons pour une fonction simple, telle que Ajouter (x, y), mais ils ne sont pas un bon nom de variable pour une fonction non triviale. Par exemple, le prototype déclare un paramètre comme INT et le nomme sous forme de mémoire tampon, vous savez quoi passer à elle. S'il n'y a pas de nom, il est un peu difficile de transmettre le bon paramètre à la fonction, en particulier la mise en œuvre de l'appelant.
Est-ce valide même pour C ou Just C ++?
En C uniquement pour les déclarations, les définitions de fonctions nécessitent des paramètres nommés.