Comme beaucoup d'autres personnes ont répondu, à partir d'un point de vue API, les suivantes sont toutes équivalentes, et sont les mêmes pour les surcharge-résolution:
void foo( int );
void foo( const int );
Mais une meilleure question est de savoir si ou non de cette offre aucun sens sémantique à un consommateur de cette API, ou si elle prévoit l'application de la loi de bons comportements à partir d'un développeur de l'application.
Sans bien défini développeur de codage des lignes directrices qui définissent expressément cette, const scalaire arguments n'ont pas facilement évident de sens sémantique.
À partir d'un consommateur:
const int ne change pas votre entrée. Il peut encore être un littéral, ou il peut être à partir d'une autre variable (les deux const ou de non-const)
À partir d'un développeur:
const int impose une restriction sur une copie locale d'une variable (dans ce cas, un argument de fonction). Cela signifie simplement modifier l'argument, vous prenez une autre copie de la variable et de le modifier à la place.
Lorsque vous appelez une fonction qui accepte un argument par valeur, une copie de cet argument sur la pile de la fonction appelée. Cela donne à la fonction de copie locale de l'argument pour l'ensemble de son champ d'application, qui peuvent ensuite être modifiés, utilisés pour les calculs, etc -- sans affecter l'entrée d'origine est passé dans l'appel. Effectivement, cela fournit une variable locale argument de son entrée.
En marquant l'argument de la" const, cela signifie simplement que cette copie ne peut pas être modifié, mais ce n'est pas d'interdire le développeur de le copier et de faire des modifications à cette copie. Étant donné que c'était une copie depuis le début, il ne fait pas valoir tout ce que beaucoup de l'intérieur de la mise en œuvre et au final ne fait pas beaucoup de différence du point de vue du consommateur.
Ceci est en contraste avec le passage par référence, dans lequel un renvoi à l' int& est sémantiquement différent de const int&. Le premier est capable de muter son entrée; ce dernier est seulement capable d'observer l'entrée (à condition que la mise en œuvre n'a pas d' const_cast le const-ness loin -, mais permet d'ignorer cette possibilité); ainsi, const-ness sur des références implicites, de sens sémantique.
Il ne fournit pas beaucoup d'avantage dans l'API publique; et (omi) introduit des restrictions inutiles à la mise en œuvre. Comme un arbitraire, exemple artificiel -- une fonction simple comme:
void do_n_times( int n )
{
while( n-- > 0 ) {
// do something n times
}
}
devrait maintenant être écrite à l'aide d'une copie superflue:
void do_n_times( const int n )
{
auto n_copy = n;
while( n_copy-- > 0 ) {
// do something n times
}
}
Indépendamment de si const scalaires sont utilisés dans l'API publique, une clé, c'est d'être cohérent avec la conception. Si l'API au hasard des commutateurs entre l'utilisation d' const scalaire arguments à l'aide de non-const scalaires, alors il peut causer de la confusion quant à savoir s'il est destiné à être implicite du sens à la consommation.
TL;DR: const types scalaires dans une API publique de ne pas transmettre de sens sémantique sauf s'il est explicitement défini par vos propres lignes directrices relatives à votre domaine.
