Je ne sais pas quel conteneur choisir pour les exigences suivantes :
- Un Element possede plusieurs Attribute
- Un Attribut possede un Name et une Value
- L'ordre des Attribut dans Element est important
- 2 Attributes ayant le meme Name est interdit.
Premiere approche : std::map<Attribute::Name, Attribute>
Pour assurer l'unicité d'un attribut donnée, c'est nickel, mais il sont
forcement rangé dans l'ordre alphabetique.
Deuxieme approche : std::list<Attribute>
Pour l'ordre, c'est nickel, par contre, pour assurer l'unicité d'un
Attribute, il faut se taper a chaque ajout une recherche dans la list
afin de verifier qu'un Attribute ayant le même Name n'existe pas. BOF aussi.
D'ailleurs, je ne sais pas trop si vector<> et list<> ici ne sont pas
équivalent ?
Troisieme approche : Un joyeu combiné des 2 solutions précedentes :
- std::map<Attribute::Name, Attribute>
- std::list< std::map<Attribute::Name, Attribute>::const_iterator >
ou std::list< std::map<Attribute::Name*>
J'ai pas testé, mais je pense que cela fonctionne. Ca me parrait juste
un poil lourd pour ce que je veux faire, non ?
Quatrieme approche : std::map<Attribute::Name, Attribute, ????>
Rajouter un predicat qui n'est pas std::less<std::string> (par defaut),
mais un autre qui ne change pas l'ordre d'insertion dans la map. C'est
possible ca ?
Les fonctions succeptibles d'ête O(n) sont entre autre size(), swap()et max_size()
Aucunement. La norme est très formelle là-dessus : ces trois fonctions doivent avoir une complexité constante. (Dans le cas de swap(), il y a énormement de code qui en dépend.)
swap au moins deviens en O(n) lorsque get_allocator() est différent (ce qui est rare c'est vrai).
A par cela, un "should"/"shall" n'est pas un "must". En pratique X::swap() ne devrait être spécialisé pour un container ssi il fonctionne en o(1) - ce qui est le cas pour les container de la STL. Mais, pour autant que je sache, ce n'est pas garanti stricto-sensus par le standard.
AMA, de la même façon que list<>::size() est devenu O(n), une implémentation de vector<>::size() en O(n) serait à priori standard.
Enfin cela a pas beaucoup d'importance vu que ce serait vicieux et que la pratique fait que l'implémentation en temps constant est directe (sauf pour list<>).
Michael
Les fonctions succeptibles d'ête O(n) sont entre autre size(), swap()et
max_size()
Aucunement. La norme est très formelle là-dessus : ces trois
fonctions doivent avoir une complexité constante. (Dans le cas
de swap(), il y a énormement de code qui en dépend.)
swap au moins deviens en O(n) lorsque get_allocator() est différent (ce
qui est rare c'est vrai).
A par cela, un "should"/"shall" n'est pas un "must". En pratique
X::swap() ne devrait être spécialisé pour un container ssi il fonctionne
en o(1) - ce qui est le cas pour les container de la STL. Mais, pour
autant que je sache, ce n'est pas garanti stricto-sensus par le standard.
AMA, de la même façon que list<>::size() est devenu O(n), une
implémentation de vector<>::size() en O(n) serait à priori standard.
Enfin cela a pas beaucoup d'importance vu que ce serait vicieux et que
la pratique fait que l'implémentation en temps constant est directe
(sauf pour list<>).
Les fonctions succeptibles d'ête O(n) sont entre autre size(), swap()et max_size()
Aucunement. La norme est très formelle là-dessus : ces trois fonctions doivent avoir une complexité constante. (Dans le cas de swap(), il y a énormement de code qui en dépend.)
swap au moins deviens en O(n) lorsque get_allocator() est différent (ce qui est rare c'est vrai).
A par cela, un "should"/"shall" n'est pas un "must". En pratique X::swap() ne devrait être spécialisé pour un container ssi il fonctionne en o(1) - ce qui est le cas pour les container de la STL. Mais, pour autant que je sache, ce n'est pas garanti stricto-sensus par le standard.
AMA, de la même façon que list<>::size() est devenu O(n), une implémentation de vector<>::size() en O(n) serait à priori standard.
Enfin cela a pas beaucoup d'importance vu que ce serait vicieux et que la pratique fait que l'implémentation en temps constant est directe (sauf pour list<>).
