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 a ussi.
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 ?
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 a ussi.
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 ?
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 a ussi.
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 ?
Bonjour
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.
[...]
Des idées ?
Bonjour
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.
[...]
Des idées ?
Bonjour
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.
[...]
Des idées ?
jeremie fouche a écrit :> BonjourJe 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.
jeremie fouche a écrit :> Bonjour
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.
jeremie fouche a écrit :> BonjourJe 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.
On Jun 10, 5:26 pm, jeremie fouche wrote: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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
On Jun 10, 5:26 pm, jeremie fouche <jfou...@voila.fr> wrote:
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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
On Jun 10, 5:26 pm, jeremie fouche wrote: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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
On Jun 10, 5:26 pm, jeremie fouche wrote: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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
C'est le cas. Je vais donc poursuivre dans cette direction.
std::vector< std::pair<std::string, Attribute> >
ou le first est le nom de l'attribut.
J'ai un peu l'impression de refaire une std::map avec clef/valeur. Mais
j'ai bien compris la différence.
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je s uis
un addepte de std::map ou std::list.
Faut il que je reserve de l'espace pour ce conteneur ?
Est il aussi souple que std::list ?
Pourquoi std::vector plutot que std::list ?
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
Je pense que std::find n'est pas ce que je recherche, il me faut un
std::find_if, car c'est uniquement sur le nom de l'attribut que je veux
l'unicité.
En somme, il faut que je me fasse une fonction qui permette l'ajout de
l'attribut :
typedef std::vector< std::pair<std::string, Attribute> > TAttributes;
TAttributes m_attributes;
class PredFindAttribByName
{
private:
std::string m_sName;
public:
PredFindAttribByName(const std::string& sName)
: m_sName(sName) { }
bool operator()(const TAttributes::value_type& val)
{
return val.first == m_sName;
}
};
bool add(const Attribute& rcAttribute)
{
bool bAdded = false;
TAttributes::const_iterator iterFound;
iterFound = std::find_if( m_attributes.begin()
, m_attributes.end()
, PredFindAttribByName(rcAttribute.GetName())
);
if (iterFound == m_attributes.end())
{
TAttributes::value_type val = std::make_pair( rcAttribute.GetName()
, rcAttribute
);
m_attributes.push_back(val);
bAdded = true;
}
return bAdded;
}
Tu voyais quelquechose comme ca ?
Il y a mieux, peut etre ?
On Jun 10, 5:26 pm, jeremie fouche <jfou...@voila.fr> wrote:
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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
C'est le cas. Je vais donc poursuivre dans cette direction.
std::vector< std::pair<std::string, Attribute> >
ou le first est le nom de l'attribut.
J'ai un peu l'impression de refaire une std::map avec clef/valeur. Mais
j'ai bien compris la différence.
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je s uis
un addepte de std::map ou std::list.
Faut il que je reserve de l'espace pour ce conteneur ?
Est il aussi souple que std::list ?
Pourquoi std::vector plutot que std::list ?
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
Je pense que std::find n'est pas ce que je recherche, il me faut un
std::find_if, car c'est uniquement sur le nom de l'attribut que je veux
l'unicité.
En somme, il faut que je me fasse une fonction qui permette l'ajout de
l'attribut :
typedef std::vector< std::pair<std::string, Attribute> > TAttributes;
TAttributes m_attributes;
class PredFindAttribByName
{
private:
std::string m_sName;
public:
PredFindAttribByName(const std::string& sName)
: m_sName(sName) { }
bool operator()(const TAttributes::value_type& val)
{
return val.first == m_sName;
}
};
bool add(const Attribute& rcAttribute)
{
bool bAdded = false;
TAttributes::const_iterator iterFound;
iterFound = std::find_if( m_attributes.begin()
, m_attributes.end()
, PredFindAttribByName(rcAttribute.GetName())
);
if (iterFound == m_attributes.end())
{
TAttributes::value_type val = std::make_pair( rcAttribute.GetName()
, rcAttribute
);
m_attributes.push_back(val);
bAdded = true;
}
return bAdded;
}
Tu voyais quelquechose comme ca ?
Il y a mieux, peut etre ?
On Jun 10, 5:26 pm, jeremie fouche wrote: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.
La première question est : combien de paires
attributes-valeurs ? Jusqu'à quelque dizaines, j'utiliserais un
std::vector< AttributeValuePair >, sans plus de soucis.
C'est le cas. Je vais donc poursuivre dans cette direction.
std::vector< std::pair<std::string, Attribute> >
ou le first est le nom de l'attribut.
J'ai un peu l'impression de refaire une std::map avec clef/valeur. Mais
j'ai bien compris la différence.
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je s uis
un addepte de std::map ou std::list.
Faut il que je reserve de l'espace pour ce conteneur ?
Est il aussi souple que std::list ?
Pourquoi std::vector plutot que std::list ?
Mais comme j'ai dit au départ, std::find sur un std::vector est
largement suffisant pour plusieurs dizaines d'attributes.
Je pense que std::find n'est pas ce que je recherche, il me faut un
std::find_if, car c'est uniquement sur le nom de l'attribut que je veux
l'unicité.
En somme, il faut que je me fasse une fonction qui permette l'ajout de
l'attribut :
typedef std::vector< std::pair<std::string, Attribute> > TAttributes;
TAttributes m_attributes;
class PredFindAttribByName
{
private:
std::string m_sName;
public:
PredFindAttribByName(const std::string& sName)
: m_sName(sName) { }
bool operator()(const TAttributes::value_type& val)
{
return val.first == m_sName;
}
};
bool add(const Attribute& rcAttribute)
{
bool bAdded = false;
TAttributes::const_iterator iterFound;
iterFound = std::find_if( m_attributes.begin()
, m_attributes.end()
, PredFindAttribByName(rcAttribute.GetName())
);
if (iterFound == m_attributes.end())
{
TAttributes::value_type val = std::make_pair( rcAttribute.GetName()
, rcAttribute
);
m_attributes.push_back(val);
bAdded = true;
}
return bAdded;
}
Tu voyais quelquechose comme ca ?
Il y a mieux, peut etre ?
On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche :Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent p our
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche <jfou...@voila.fr>:
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent p our
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche :Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent p our
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
Je t'invite à allez voire boost:any qui permet une implementation
simple de ta classe Attribute
Je t'invite à allez voire boost:any qui permet une implementation
simple de ta classe Attribute
Je t'invite à allez voire boost:any qui permet une implementation
simple de ta classe Attribute
Un désavantage marginal est la méthode size() en O(n). Ca m'est arrivé
que cela soit contraignant pour des grandes listes dans la phase de test
et de validation.
Un désavantage marginal est la méthode size() en O(n). Ca m'est arrivé
que cela soit contraignant pour des grandes listes dans la phase de test
et de validation.
Un désavantage marginal est la méthode size() en O(n). Ca m'est arrivé
que cela soit contraignant pour des grandes listes dans la phase de test
et de validation.
On Jun 11, 9:20 pm, Fabien LE LEZ wrote:On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche :Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent pour
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
Ou des éléments dont la copie est très chère.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
Ou que tu as besoins de garder des itérateurs, ou des pointeurs
ou des références à des éléments, tout en insérant ou en
enlevant d'autres éléments. Elle a la désavantage, vis-à-vis des
autres collections, que ses itérateurs ne sont que
bi-directionnels, et non aléatoire. Elle a l'avantage, en
révanche, qu'ils restent valides tant que l'élément reste dans
la collection.
Quand tu as vraiment beaucoup d'éléments (des centaines de
milliers, voire plus), ou que tu fais des insertions et des
suppressions en pagaille, elle a aussi le désavantage de
fragmenter la mémoire et d'avoir une très mauvaise localisation.deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
D'après ce que j'ai compris, il y a eu une erreur dans les
premières versions qui faisaient qu'elle était affreusement
lente. Dans la pratique, je m'en sers assez souvent, chaque fois
que j'ai besoin d'une queue, en fait. (Pour des piles et des
tableaux, je me sers de std::vector.)
On Jun 11, 9:20 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche <jfou...@voila.fr>:
Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent pour
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
Ou des éléments dont la copie est très chère.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
Ou que tu as besoins de garder des itérateurs, ou des pointeurs
ou des références à des éléments, tout en insérant ou en
enlevant d'autres éléments. Elle a la désavantage, vis-à-vis des
autres collections, que ses itérateurs ne sont que
bi-directionnels, et non aléatoire. Elle a l'avantage, en
révanche, qu'ils restent valides tant que l'élément reste dans
la collection.
Quand tu as vraiment beaucoup d'éléments (des centaines de
milliers, voire plus), ou que tu fais des insertions et des
suppressions en pagaille, elle a aussi le désavantage de
fragmenter la mémoire et d'avoir une très mauvaise localisation.
deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
D'après ce que j'ai compris, il y a eu une erreur dans les
premières versions qui faisaient qu'elle était affreusement
lente. Dans la pratique, je m'en sers assez souvent, chaque fois
que j'ai besoin d'une queue, en fait. (Pour des piles et des
tableaux, je me sers de std::vector.)
On Jun 11, 9:20 pm, Fabien LE LEZ wrote:On Mon, 11 Jun 2007 19:56:08 +0200, jeremie fouche :Pour info, je ne crois pas avoir déjà utilisé std::vector, car je suis
un addepte de std::map ou std::list. Faut il que je reserve de l'espace
pour ce conteneur ? Est il aussi souple que std::list ? Pourquoi
std::vector plutot que std::list ?
Disons que vector<> est le conteneur "par défaut". Si j'ai besoin d'un
tableau quelque part dans un programme, j'utilise vector<>, sauf si
j'ai de bonnes raisons de penser qu'il ne convient pas.
Dans l'ensemble, vector<>, deque<> et list<> sont interchangeables.
vector<> est très rapide pour l'accès aléatoire, mais très lent pour
l'insertion ailleurs qu'à la fin. Il faut toutefois relativiser "très
lent" -- il faut un sacré paquet d'éléments pour que ça se voit.
Ou des éléments dont la copie est très chère.
list<>, c'est le contraire : il ne fait pas d'accès aléatoire, mais
permet une insertion rapide d'un élément n'importe où.
Ou que tu as besoins de garder des itérateurs, ou des pointeurs
ou des références à des éléments, tout en insérant ou en
enlevant d'autres éléments. Elle a la désavantage, vis-à-vis des
autres collections, que ses itérateurs ne sont que
bi-directionnels, et non aléatoire. Elle a l'avantage, en
révanche, qu'ils restent valides tant que l'élément reste dans
la collection.
Quand tu as vraiment beaucoup d'éléments (des centaines de
milliers, voire plus), ou que tu fais des insertions et des
suppressions en pagaille, elle a aussi le désavantage de
fragmenter la mémoire et d'avoir une très mauvaise localisation.deque<> est un peu au milieu. Il ménage la chèvre et le chou, et est à
préférer si tu as besoin d'insérer (ou supprimer) des éléments au
début et à la fin. Bizarrement, alors qu'il semble fournir le meilleur
des deux mondes, il est assez peu utilisé.
D'après ce que j'ai compris, il y a eu une erreur dans les
premières versions qui faisaient qu'elle était affreusement
lente. Dans la pratique, je m'en sers assez souvent, chaque fois
que j'ai besoin d'une queue, en fait. (Pour des piles et des
tableaux, je me sers de std::vector.)