problème avec la STL sous solaris

Version imprimable

bonjour,

le cmpilateur CC sous solaris n'aime pas les insert avec indication de position sur las map:

le code suivant compile très bien sous VS2005, gcc linux (redhat) mais pas sous solaris avec comme compilo CC 5.5 .

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
 
 
#include <iostream>
#include <vector>
#include <map>
#include <string>
 
using namespace std;
 
 
int main(int argc, char* argv[])
{
 
  map<string ,int> m;
  map<string ,int>::iterator it;
 
 
 
  m.insert ( pair<string,int>("sofiane",100) );
  m.insert ( pair<string,int>("balabla",200) );
 
  it=m.end();
 
  m.insert (it, pair<string,int>("last",300));  //la ligne qui cause le problème
 
 
  for ( it=m.begin() ; it != m.end(); it++ )
      cout << (*it).first << " => " << (*it).second << endl;
 
     cout << endl;
 
  return 0;
 
}

voila ce que raconte le compilateur :

Code:

1
2
3
4
5
 
sofiane: CC -o exampl exampl.cpp
"exampl.cpp", line 27: Error: Could not find a match for std::map<std::string,int>::insert(__rwstd::__rb_tree<std::string, std::pair<const std::string, int>, __rwstd::__select1st<std::pair<const std::string, int>, std::string>, std::less<std::string>, std::allocator<std::pair<const std::string, int>>>::iterator, std::pair<std::string, int>).
1 Error(s) detected.
sofiane:

Merci d'avance

01/12/2009, 11h39
koala01

Salut,

La raison est peut être simple: tu ne devrais normalement pas choisir la position à laquelle s'effectue l'insertion dans une map, vu que la première partie de la pair (pair::first) correspond à... la clé utilisée pour trier la map...

En effet, le principe de fonctionnement d'une std::map est de créer un arbre binaire de recherche sur base de la valeur de pair::first...

Si c'est pour insérer l'élément en fin de map quoi qu'il arrive, autant utiliser une... liste chainée de pair (std::list< std::pair<std::string, int> > dans ton cas):D

Autre chose...

J'ai pris l'habitude de préférer passer par make_pair pour la création d'une paire à insérer dans une map, mais peut être n'est-ce qu'une habitude idiote :D
01/12/2009, 11h44
screetch

le insert avec position n'est pas standard mais a été ajouté par la plupart des compilateurs. Mais ca reste pas standards.
Pour koala : le premier iterateur est considéré comme un "hint", une indication de l'endroit ou l'insertion pourrait se faire
sur la plupart des implémentations, le hint n'est considéré que si l'itérateur indique la position exacte ou l'insertion devrait se faire, sinon lar recherche de l'endroit a insérer repart du début.
01/12/2009, 12h00
koala01

Citation:

Envoyé par screetch

le insert avec position n'est pas standard mais a été ajouté par la plupart des compilateurs. Mais ca reste pas standards.

C'est peut être pour cela que je ne l'ai jamais utilisé :P

Citation:

Pour koala : le premier iterateur est considéré comme un "hint", une indication de l'endroit ou l'insertion pourrait se faire
sur la plupart des implémentations, le hint n'est considéré que si l'itérateur indique la position exacte ou l'insertion devrait se faire, sinon lar recherche de l'endroit a insérer repart du début.

Je me demande dans quelle mesure cela ne fera pas perdre beaucoup plus de temps que ce que cela peut en faire gagner dans la plupart des cas...

Car, restons réalistes: à moins qu'il ne s'agisse de désérialiser un flux créé à partir d'une std::map et donc, pour lequel les éléments arrivent, effectivement, dans l'ordre "idéal" pour l'insertion, cela oblige à effectuer un test supplémentaire dont le résultat sera le plus souvent... de reprendre au début... du moins, chaque fois que l'information à insérée sera fournie par l'utilisateur :P
01/12/2009, 12h00
sofiane80

l'indication de la position lors d'une inserstion , si je ne me trempe pas , ne sert qu'à reduire la complexitée de l'algorithme d'insertion. le resultat d'une insertion dans une map reste le meme que ce soit en indique la position ou pas.

est ce vrai ??
01/12/2009, 12h04
sofiane80

OK j'ai eu ma reponse

Merci.
01/12/2009, 12h11
screetch

koala : ca peut fonctionner dans certains cas et c'est pour ca que ca a ete ajouté. mais dans le cas standard, ca ne sert pas souvent, c'est pour ca que ca ne doit pas faire partie du standard :)
01/12/2009, 12h12
Arzar

Citation:

Envoyé par koala01

Je me demande dans quelle mesure cela ne fera pas perdre beaucoup plus de temps que ce que cela peut en faire gagner dans la plupart des cas...

Pourquoi l'utiliser dans la plupart des cas ? Comme l'a dit screech la version avec hint n'est utile que si l'on sait à l'avance où l'on doit insérer la paire. Par exemple, il arrive frequement que l'on sache que la paire doit être insérée tout à la fin ou tout au début et dans ce cas l'insertion est en O(1).
01/12/2009, 12h15
koala01

Citation:

Envoyé par Arzar

Pourquoi l'utiliser dans la plupart des cas ? Comme l'a dit screech la version avec hint n'est utile que si l'on sait à l'avance où l'on doit insérer la paire. Par exemple, il arrive frequement que l'on sache que la paire doit être insérée tout à la fin ou tout au début et dans ce cas l'insertion est en O(1).

C'est vrai que j'ai mal choisi ce terme...

Je vous présente donc mes excuses pour m'être laisser emporter :D
01/12/2009, 12h20
JolyLoic
Citation:

Envoyé par screetch

le insert avec position n'est pas standard
Citation:
Envoyé par La norme, 23.3.1/2

Code:

1 2 3 class map { ... iterator insert(iterator position, const value_type& x);
01/12/2009, 13h16
Luc Hermitte

L'implémentation par défaut de la SL qui accompagne le compilo de Sun est celle de Roguewave qui date de 96 ou 95 je ne sais plus.
Bref, nous sommes loin du standard (98).

Pour t'en rapprocher, migre à l'implémentation de la STLport v4 (rajoute un -lib=stlport je crois). Par contre attention, cela veut dire qu'il faut absolument tout recompiler, y compris les COTS C++ que vous utilisez, et qu'il faut abandonner Tools++ de RW.
01/12/2009, 14h17
Jean-Marc.Bourguet

Citation:

Envoyé par Luc Hermitte

L'implémentation par défaut de la SL qui accompagne le compilo de Sun est celle de Roguewave qui date de 96 ou 95 je ne sais plus.
Bref, nous sommes loin du standard (98).

En prime elle est configuree pour ne supporter que ce que SunCC 5.0 supportait quand il est sorti (pas de templates membres si j'ai bonne memoire). Sun accorde une tres grande importance a la compatibilite binaire. Ce qui est inestimable quand on en a besoin, mais genant quand les choses evoluent et qu'on ne peut pas en profiter.
01/12/2009, 14h26
Luc Hermitte

Oui...
C'est le genre de migrations auxquelles on réfléchit à deux fois. D'autant plus que Solaris, c'est en environnement professionnel, le genre d'environnement où l'on reste sur des vieux compilos aussi longtemps que l'on n'a pas un besoin absolu de passer à mieux.