Hello,
J'ai un vecteur pour lequel j'aimerais trouver la position d'un élément donné (unicité garantie en amont). Cet indice sera utilisé pour récupérer un élément dans un autre vecteur.
L'algorithme find me donne un itérateur, mais ensuite ?
MErci.
Version imprimable
Hello,
J'ai un vecteur pour lequel j'aimerais trouver la position d'un élément donné (unicité garantie en amont). Cet indice sera utilisé pour récupérer un élément dans un autre vecteur.
L'algorithme find me donne un itérateur, mais ensuite ?
MErci.
ou mieuxCode:int pos = it_found - vector.begin();
Code:int pos = std::distance(vector.begin(),it_found);
S'il s'agit d'un vecteur, les éléments sont contaigus, du coup, tu peux faire une soustraction entre le pointeur donné et le pointeur de début. Il y a une fonction std pour ça mais je ne me souviens plus du nom.
Edit:
Camboui m'a devancé, c'est std::distance que je cherchais ^^
Merci !
En revanche, le type de retour de la fonction distance m'a l'air assez tordu, dans la documentation.
On peut sans soucis mettre ça dans un int ?
Code:
1
2
3 typedef std::iterator_traits<std::vector<A>::iterator >::difference_type type_distance_vect_A; type_distance_vect_A ma_distance; ma_distance = std::distance(vect.begin(),vect.end());
Justement.
Quelle est la relation entre ça et un int ?
Alors qu'avec un int, non...
std::iterator_traits<std::vector<A>::iterator >::difference_type est défini pour que justement tu n'aies pas à te poser la question. C'est un peu lourd à écrire, je le reconnais, c'est pour ça que tu peux utiliser une typedef pour simplifier.
Et si je veux rendre mon code portable 32/64 bits, comment je fais pour éviter de me trimbaler ça ? Parce que j'en besoin de cette valeur comme indice dans un autre vecteur.
Salut,
La seule façon de le faire sans soucis est d'utiliser le difference_type de la classe trait associée à ton itérateur. Tout le reste n'écartera pas le risque que dans une configuration donnée ou qu'avec une implémentation particulière de la STL ça ne marche pas.
En quoi trouves-tu gênant d'utiliser : std::iterator_traits<std::vector<A>::iterator >::difference_type.
D'autant que tu peux faire un typedef pour alléger l'écriture .
Ça me gêne, parce que l'info en question (la distance) m'est utile dans un contexte où est attendue un entier.
Il y a 12 ans je me fendais à faire du code compatible 16 et 32 bits. Avec le recul ça n'a servi à rien.
En 32 bits t'as aucun soucis, std::distance() renvoit l'équivalent d'un int sur 32 bits (en fait c'est un int).
Au fait en 64 bits, un int c'est combien de bits ?
Un long fait 32 bits avec un compilateur 64bits pour Windows 64 bits ??? 8O
Tu le faisais probablement mal, alors.Citation:
Il y a 12 ans je me fendais à faire du code compatible 16 et 32 bits. Avec le recul ça n'a servi à rien.
Parce que moi j'arrive parfaitement à faire du code indépendant de l'architecture... Même indépendant de la taille en bits de char.
Sous x86-64, bien souvent, tu as :
int : 32 bits
long : 64 bits
Modele appele LLP64.
Arrivé 10 ans apres que tout le monde se soit decide pour le modele LP64. Oui. Parce que faciliter le portage sur 64 bits des applications Windows 32 bits a ete considere comme plus important que de faciliter le portage sur Windows 64 bits des applications 64 bits deja existantes.
Il me semble que rien dans la norme n'impose de taille pour les types si ce n'est :
sizeof(char)=1
et
sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)
, non?
Tu as aussi
CHAR_BITS >= 8
sizeof(short)*CHAR_BITS >= 16
sizeof(long)*CHAR_BITS >= 32
sizeof(long long)*CHAR_BITS >= 64
C'est importe de C qui a des intervalles minimums. Voir
http://www.bourguet.org/v2/clang/libc90/limits_8h.html
Euh... de quoi parles-tu ? :roll:
Je disais donc que ça n'a servi à rien puisque je n'ai plus jamais mis en production des programme 16 bits. Mes programmes marchaient très bien en 16 bits mais personne n'en voulait :aie:
Tous les clients voulaient du Win32s sous Windows 3.11, c'était à la mode.
Pourtant les programmes "modestes" utilisant peu de resources marchaient mieux en 16 bits: exe plus petit, exécution plus rapide...
Il me semble qu'on vit la même chose avec le passage en 64 bits: plus lent, plus lourd et sans doute inutile si le prg n'utilise pas plus de 2GB de mémoire. Mais ça risque d'être bientôt à la mode...