Map dans une map (error C2678: '==' binaire) [Résolu]
Polack77
Membre Dernière intervention
15 avril 2018
- - Dernière réponse :
cptpingu
Modérateur Dernière intervention
5 mai 2019
- 13 déc. 2017 à 17:06
- Messages postés
- 1100
- Date d'inscription
- mercredi 22 mars 2006
- Statut
- Messages postés
- 3835
- Date d'inscription
- dimanche 12 décembre 2004
- Statut
A voir également:
- C2678
- Error c2678 - Meilleures réponses
- C++ c2678 - Meilleures réponses
- Error C2678: '!=' binaire : aucun opérateur trouvé qui accepte un opérande de pa ✓ - Forum - C++ & C++ .NET
4 réponses
- Messages postés
- 1100
- Date d'inscription
- mercredi 22 mars 2006
- Statut
-_- arf oups j'étais visiblement fatigué hier....
C'est simplement un problème de syntaxe :/
Il ne faut pas utiliser la fonction find de cette façon mais dans l'objet map (la fonction find avec cette syntaxe est faite pour les vector et non pour les map :*) )
La correction de mon exemple :
En espérant que mon problème permette à quelqu'un de trouver une réponse son problème (en admettant que je ne sois pas le seul à faire ce genre d'erreur de syntaxe)
C'est simplement un problème de syntaxe :/
Il ne faut pas utiliser la fonction find de cette façon mais dans l'objet map (la fonction find avec cette syntaxe est faite pour les vector et non pour les map :*) )
La correction de mon exemple :
map<CString,map<CString,CString>> test; map<CString,map<CString,CString>>::iterator ittest; CString cleTest = "toto"; ittest = test.find(cleTest);
En espérant que mon problème permette à quelqu'un de trouver une réponse son problème (en admettant que je ne sois pas le seul à faire ce genre d'erreur de syntaxe)
- Messages postés
- 3835
- Date d'inscription
- dimanche 12 décembre 2004
- Statut
Bonjour.
Félicitations pour avoir trouver seul, et surtout merci de prendre le temps de répondre. Ça servira sans doute à d'autres :).
Attention, les "using namespace", c'est un peu dégueux, voir: http://0217021.free.fr/portfolio/axel.berardino/articles/bon-usage-using-namespace/
Pour alléger un peu l'écriture, si tu es en C++11 ou supérieur, tu peux écrire:
Félicitations pour avoir trouver seul, et surtout merci de prendre le temps de répondre. Ça servira sans doute à d'autres :).
Attention, les "using namespace", c'est un peu dégueux, voir: http://0217021.free.fr/portfolio/axel.berardino/articles/bon-usage-using-namespace/
Pour alléger un peu l'écriture, si tu es en C++11 ou supérieur, tu peux écrire:
std::map<CString, std::map<CString,CString> > test; CString cleTest = "toto"; auto ittest = test.find(cleTest);
- Messages postés
- 1100
- Date d'inscription
- mercredi 22 mars 2006
- Statut
Bah de rien ^^ (c'est normal de mon point de vue),
Oui je suis bien d'accord pour dire que les "using namespace" ce n'est pas propre (voir dangereux). Mais dans ce cas précis je travaille sur un projet existant.
Néanmoins, je m’autorise ça pour le "std" (et uniquement le std).
Par contre les types "auto" je trouve ça presque pire (car on ne voit pas explicitement le type qui sera utilisé en final, ce qui peut être source d'erreur).
PS :
Pour les débutants, un namespace dans le code, c'est un peu comme un dossier dans un disque.
On ne peut pas avoir deux fichiers identiques (même nom et extension) dans le même dossier. Bah c'est pareil avec les fonctions et les namespaces (on ne peut pas avoir deux fonctions avec la même signature dans le même namespace).
Dans l'un comme dans l'autre on peut déclarer des raccourcis :
- Via la variable système PATH dans le cas d'un dossier (c'est pour ça que quelque-soit le dossier actif dans une console si on tape "explorer" un explorateur de fichier s'ouvre)
- Via "using namespace" pour le code.
Résultat ça peut être dangereux, car si on a deux exécutables du même nom dans deux dossiers présents dans PATH, et qu'on appel cet exe. On ne sais pas vraiment quel exe on va exécuter en final. C'est pareil avec le code (bon même si des warnings/erreurs du compilo sont sensé nous prévenir). Donc moins il y a de "using namespace" mieux c'est (même si cela reste bien pratique il ne faut SURTOUT pas en abusé).
Ce "PS" concerne principalement Windows (même s'il existe des équivalents sur Linux ;) )
Oui je suis bien d'accord pour dire que les "using namespace" ce n'est pas propre (voir dangereux). Mais dans ce cas précis je travaille sur un projet existant.
Néanmoins, je m’autorise ça pour le "std" (et uniquement le std).
Par contre les types "auto" je trouve ça presque pire (car on ne voit pas explicitement le type qui sera utilisé en final, ce qui peut être source d'erreur).
PS :
Pour les débutants, un namespace dans le code, c'est un peu comme un dossier dans un disque.
On ne peut pas avoir deux fichiers identiques (même nom et extension) dans le même dossier. Bah c'est pareil avec les fonctions et les namespaces (on ne peut pas avoir deux fonctions avec la même signature dans le même namespace).
Dans l'un comme dans l'autre on peut déclarer des raccourcis :
- Via la variable système PATH dans le cas d'un dossier (c'est pour ça que quelque-soit le dossier actif dans une console si on tape "explorer" un explorateur de fichier s'ouvre)
- Via "using namespace" pour le code.
Résultat ça peut être dangereux, car si on a deux exécutables du même nom dans deux dossiers présents dans PATH, et qu'on appel cet exe. On ne sais pas vraiment quel exe on va exécuter en final. C'est pareil avec le code (bon même si des warnings/erreurs du compilo sont sensé nous prévenir). Donc moins il y a de "using namespace" mieux c'est (même si cela reste bien pratique il ne faut SURTOUT pas en abusé).
Ce "PS" concerne principalement Windows (même s'il existe des équivalents sur Linux ;) )
- Messages postés
- 3835
- Date d'inscription
- dimanche 12 décembre 2004
- Statut
Ça reste super dangereux. Le souci ce n'est pas vraiment le conflit, qui est une gêne mineure. C'est surtout le masquage silencieux qui peut faire mal.
Cf le lien, il y a un exemple de masquage avec la std, notamment la fonction "count". Et comme tu ne sais pas ce qui peut être ajouté dans la STL, ton code peut casser silencieusement après une maj du compilo, bonheur :p.
Quand on ne veut pas tout écrire, on utilise des "using" simple ou des "using" alias. Une suite de "using" c'est un cran au dessus niveau propreté qu'une pollution globale via un using namespace.
Le "auto" a été ajouté pour une raison :). Ce n'est en rien pire, bien au contraire. Le typage n'est pas absent, il est juste déduit. Donc il n'est pas possible de se tromper (le compilo retournera les mêmes erreurs que si on écrivait le vrai type). C'est notamment très très utilisé pour les itérateurs, qui ont des types "painful" à écrire, sans valeur ajoutée. Le but de auto n'est pas d’être mis à toutes les sauces (et ne remplace pas des pod ou des objets simples), mais de remplacer les expressions compliquées ou celle impossible à déduire (en template avancé, il faut parfois adjoindre un template à un autre, juste pour déduire un type, l’apparition des auto a été un gros soulagement en terme de lisibilité et de complexité).
Cf le lien, il y a un exemple de masquage avec la std, notamment la fonction "count". Et comme tu ne sais pas ce qui peut être ajouté dans la STL, ton code peut casser silencieusement après une maj du compilo, bonheur :p.
Quand on ne veut pas tout écrire, on utilise des "using" simple ou des "using" alias. Une suite de "using" c'est un cran au dessus niveau propreté qu'une pollution globale via un using namespace.
Le "auto" a été ajouté pour une raison :). Ce n'est en rien pire, bien au contraire. Le typage n'est pas absent, il est juste déduit. Donc il n'est pas possible de se tromper (le compilo retournera les mêmes erreurs que si on écrivait le vrai type). C'est notamment très très utilisé pour les itérateurs, qui ont des types "painful" à écrire, sans valeur ajoutée. Le but de auto n'est pas d’être mis à toutes les sauces (et ne remplace pas des pod ou des objets simples), mais de remplacer les expressions compliquées ou celle impossible à déduire (en template avancé, il faut parfois adjoindre un template à un autre, juste pour déduire un type, l’apparition des auto a été un gros soulagement en terme de lisibilité et de complexité).
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.