Quatre ans ont passé, Google m'a donné cette réponse. Avec le standard C++11 (alias C++0x ), il existe en fait une nouvelle façon agréable de le faire (au prix d'une rupture de la rétrocompatibilité) : la nouvelle fonction auto
mot-clé. Il vous évite d'avoir à spécifier explicitement le type de l'itérateur à utiliser (en répétant à nouveau le type de vecteur), alors qu'il est évident (pour le compilateur), quel type utiliser. Avec v
étant votre vector
vous pouvez faire quelque chose comme ça :
for ( auto i = v.begin(); i != v.end(); i++ ) {
std::cout << *i << std::endl;
}
C++11 va encore plus loin et vous donne une syntaxe spéciale pour itérer sur des collections comme les vecteurs. Elle supprime la nécessité d'écrire des choses qui sont toujours les mêmes :
for ( auto &i : v ) {
std::cout << i << std::endl;
}
Pour le voir dans un programme fonctionnel, construisez un fichier auto.cpp
:
#include <vector>
#include <iostream>
int main(void) {
std::vector<int> v = std::vector<int>();
v.push_back(17);
v.push_back(12);
v.push_back(23);
v.push_back(42);
for ( auto &i : v ) {
std::cout << i << std::endl;
}
return 0;
}
Au moment où j'écris ces lignes, quand vous compilez ceci avec g++ vous devez normalement le configurer pour qu'il fonctionne avec la nouvelle norme en fournissant un drapeau supplémentaire :
g++ -std=c++0x -o auto auto.cpp
Vous pouvez maintenant exécuter l'exemple :
$ ./auto
17
12
23
42
Veuillez noter que les instructions sur la compilation et l'exécution sont spécifiques à gnu c++ compilateur sur Linux le programme doit être indépendant de la plate-forme (et du compilateur).
11 votes
La réponse non signée est correcte car polygon.size() est de type non signé. Unsigned signifie toujours positif ou 0. C'est tout ce que cela signifie. Donc, si l'utilisation de la variable est toujours seulement pour les comptes, alors unsigned est le bon choix.
0 votes
Pour résoudre le problème de l'avertissement sur les signatures/non signatures, il suffit de remplacer
int
paruint
(unsigned int
) eni
déclaration.3 votes
@AdamBruss
.size()
n'est pas de typeunsigned
alias.unsigned int
. Il est de typestd::size_t
.1 votes
@underscore_d size_t est un alias pour unsigned.
5 votes
@AdamBruss Non.
std::size_t
est un typedef défini par l'implémentation. Voir la norme.std::size_t
pourrait être équivalent àunsigned
dans votre implémentation actuelle, mais ce n'est pas pertinent. Prétendre que cela l'est peut résulter en un code non portable et un comportement non défini.0 votes
@underscore_d Dans quelle version de C++ unsigned n'est-il pas équivalent à size_t ?
1 votes
@underscore_d J'ai eu tort de dire que unsigned est équivalent à size_t. size_t est de 8 octets sous un build 64bit comme vous l'avez souligné. C'est également vrai dans microsoft visual c++. Mais si size_t différait réellement entre deux compilateurs, comme vous le déduisez, vous auriez un code non portable simplement en utilisant size_t.
0 votes
@AdamBruss ...touché ! Battu en utilisant ma propre logique, ce qui rend ma diatribe dans mon dernier commentaire hypocrite :-) Oui, le comportement défini par l'implémentation semble garanti avec des typedefs comme celui-ci, qu'on les utilise ou qu'on les ignore. Je dirais qu'il est sans doute préférable de les utiliser lorsqu'ils sont disponibles, même si l'avantage est purement théorique - mais comparez cela à d'autres fils de discussion où les gens soutiennent que
std::size_t
est largement inutile et toutes les boucles normales devraient être effectuées avecint
! Je suppose que ces sujets ne sont pas vraiment pratiques, puisque peu de gens utiliseront un jour des tableaux aussi grands.0 votes
@underscore_d Je suppose que size_t est un mal nécessaire pour permettre une seule fonction size() par exemple au lieu d'une qui renvoie un unsigned de 4 octets et une qui renvoie un unsigned de 8 octets. Je suis d'accord sur la question des grands conteneurs.
1 votes
@underscore_d Il n'est pas de type
size_t
il est de typedecltype(polygon)::size_type
.