C++: Const exactitude et pointeur arguments
Je comprends qu'un pointeur const peut être déclaré un couple de façons:
const int * intPtr1; //Declares a pointer that cannot be changed.
int * const intPtr2; //Declares a pointer whose contents cannot be changed.
//EDIT: THE ABOVE CLAIMS ARE INCORRECT, PLEASE READ THE ANSWERS.
Mais ce sur les mêmes principes dans le contexte des arguments d'une fonction?
Je suppose que la suite est redondant:
void someFunc1(const int * arg);
void someFunc2(int * arg);
Depuis someFunc 1 et 2 de faire un passe-par-valeur pour le pointeur lui-même, il est impossible pour someFunc1 pour modifier la valeur du pointeur d'origine, dans un appel à la fonction. Pour illustrer:
int i = 5;
int * iPtr = &i;
someFunc1(iPtr); //The value of iPtr is copied in and thus cannot be changed by someFunc1.
Si elles sont vraies, alors il n'y a pas de point en plus de la déclaration d'une fonction avec un " const int * ptr type arg, correct?
Vous avez vos déclarations dans le mauvais sens. "const int *" est une variable pointeur vers un immuable int. int * const" est immuable pointeur vers une variable de type int.
Non, vous avez tout faux.
Modifié la question, de sorte que la gâchette googlers ne pourra pas disparaître mal informés. J'ai quitté l'erreur en sorte que les réponses ont encore ce contexte.
Non, vous avez tout faux.
Modifié la question, de sorte que la gâchette googlers ne pourra pas disparaître mal informés. J'ai quitté l'erreur en sorte que les réponses ont encore ce contexte.
OriginalL'auteur Ben | 2012-01-10
Vous devez vous connecter pour publier un commentaire.
Vous avez à l'envers:
Suivantes
const
est en effet inutile, et il n'y a pas de raison de le mettre dans une fonction déclaration:Cependant, vous pouvez le mettre dans la fonction mise en œuvre, pour la même raison que vous pouvez déclarer une variable locale (ou autre chose)
const
- la mise en œuvre peut être plus facile à suivre quand vous savez que certaines choses ne changent pas. Vous pouvez le faire que si oui ou non elle est déclarée à l'const
dans toute autre déclaration de la fonction.quelle est la différence entre
const int * intPtr1
etint const * intPtr1;
?Aucune différence du tout.
const
qualifie la chose avant, sauf si c'est au début, auquel cas il qualifie la première chose. Donc dans les deux cas, il qualifie l'int
, pas le pointeur.int * const
à qualifier le pointeur.Wow, c'est tellement évident, je me demande il y a une question à poser à ce sujet? (Je trouvais la question peut être résolu par votre commentaire.)
OriginalL'auteur Mike Seymour
Eh bien, il n'est pas fait pour l'appelant, mais pour le code à l'intérieur de la
someFunc1
. Alors que le code à l'intérieur desomeFunc1
l'habitude accidentellement le changer. commePermet de faire certains étude de cas:
1) Juste en faisant le relevé de la valeur const
2) vient de rendre le pointeur const
3) bonne façon de l'utiliser const si les variables impliquées peuvent être const:
Ceci doit effacer tous les doutes. Donc je l'ai déjà mentionné, il est destiné pour le code de fonction et non pas pour l'appelant et vous devez utiliser la plus restrictive des 3 cas que j'ai mentionnés ci-dessus.
EDIT:
const
. Cela permettra non seulement d'augmenter la lisibilité, mais aussi l'appelant sera au courant du contrat et n'a plus confiance en ce qui concerne l'immuabilité des arguments. (Ceci est nécessaire bcoz vous, en général, de partager vos fichiers d'en-tête si l'appelant peut ne pas avoir de vos mise en œuvre c/fichier cpp)void someFunc1(const int * arg);
. Notez que predeclaringsomeFunc1
commevoid someFunc1(int * arg);
permet toujours de le définir commevoid someFunc1(int * const arg) { ... }
si vous le souhaitez, leconst
-ness du paramètre de la variable elle-même n'affecte pas le fonctionnement réel de la signature.pls aller par le biais de la mise à jour du sna. Qui devrait sna votre préoccupation.
Désolé, aucun, mise à jour de votre réponse n'est toujours pas répondre à la question. (Voir Mike Seymour réponse, ci-dessus, pour la bonne réponse.)
"Cependant, vous pouvez le mettre dans la fonction de mise en œuvre, pour la même raison que vous pouvez déclarer une variable locale (ou autre chose) const" = "je l'ai déjà mentionné, il est destiné pour le code de fonction et non pas pour l'appelant "...nyways le point est clair c'est la ligne du bas...
Je suppose que j'ai juste une étrange préférence pour les réponses que réellement répondre à la question!
OriginalL'auteur havexz
Vous avez votre logique à l'envers. Vous devriez lire le type en arrière, donc
const int *
est un pointeur vers uneconst int
etint * const
est unconst
pointeur vers un int.Exemple:
D'élaborer et de montrer pourquoi vous voudriez que votre paramètre de la fonction d'être un
const int *
vous pourriez vouloir indiquer à l'appelant qu'ils doivent passer dans unint
parce que vous comme une fonction souhaitez modifier la valeur. Considérer ce code par exemple:OriginalL'auteur mattjgalloway
Oui, vous avez raison (en ignorant le fait que vous les avez à l'envers)- il n'y a pas de sens dans la prise de non-référence
const
paramètres. En outre, il n'y a pas de sens dans le retour de la non-référenceconst
valeurs.const
les valeurs de retour sont même nuisibles.Pourriez-vous élaborer sur ce point, s'il vous plaît? Je ne savais pas qu'ils avaient un quelconque effet!
Voir Quand un const type de retour d'interférer avec l'instanciation d'un modèle? C'est plutôt un problème mineur.
La sémantique de déplacement pour un.
T const&&
ne peut pas être déplacé de", même si tu sais que c'est temporaire, qui sera bientôt détruit.Cet article a été écrit il y a une décennie, donc, oui, bien avant la sémantique de déplacement ont été établis.
OriginalL'auteur Puppy
Vous avez de la mauvaise façon:
Généralement parlant, il est plus facile de raisonner sur constness lors de la rédaction de cette expression légèrement différente:
const int*
est du même type queint const *
. Dans cette notation, les règles sont de plus en plus,const
s'applique toujours pour le type précédent, donc:Lorsque le type est écrit avec l'un des principaux
const
, leconst
est traitée comme si elle a été écrite après le premier type, de sorteconst T*
devientT const *
.Est donc pas redondant, car
someFunc2
peut changer le contenu dearg
, tandis quesomeFunc1
peut pas.void someFunc3(int * const arg);
serait redondant (et ambiguë) siOriginalL'auteur Grizzly