Pouvez vous me dire la demarche pour
installer la STL (de SGI) en lieu et place
de la stl install=E9 avec visual.
car cette derniere n'est vraiment pas tres stable....
"Michaël Cortex" wrote in message news:<0UD5b.113798$...
Benoît Sibaud wrote:
Je ne saisis pas bien la question... les 3 implémentations ont les mêmes prototypes de fonctions (mais pas dans le même ordre dans ce que tu donnes). Où vois-tu la différence ?
La valeur de retour est un itérateur ou void suivant les cas.
ah... exact. Je n'avais pas vu :S Je vais voir dans le Stroustup...
p. 487 : les 2 erase avec les iterateurs retournent void, celle avec const key_type retourne size_type.
Dinkumware s'est donnée une liberté (volontairement ?) bien bizarre...
Bizarre, je ne sais pas. Il me paraît bien utile, et un peu bizarre que les fonctions renvoient void dans la norme. Pourquoi est-ce qu'on renvoie les itérateurs dans les séquences, et non dans les collections associatives. Il y a au moins une manque d'orthogonalité.
En fait, je crois que Dinkumware a fait la décision avant que la norme a été fixée. Et ne l'a pas changé par la suite de peur de casser du code existant. D'autant plus que pratiquement, la seule fois qu'une application vera la différence, c'est si elle prend l'adresse de la fonction membre.
Quel iterator on obtient après un erase () ? (end() ?),
Tu veux dire, en supposant que la fonction existait ?
ou même après un erase (begin(), begin()+1) ?
Dans tous les cas, l'itérateur renvoyé par erase() doit désigner le premier élément suivant le dernier élément effacer, ou end() s'il n'y a pas de tel élément. L'idiome consacré est :
Collection::iterator i = c.begin() ; while ( i != c.end() ) { if ( condition( *i ) ) { i = c.erase( i ) ; } else { ++ i ; } }
J'avoue ne pas comprendre pourquoi cette idiome doit marcher avec des séquences, et non avec des collections associatives.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michaël Cortex" <cort@meloo.com> wrote in message
news:<0UD5b.113798$2k4.1234281@news.chello.at>...
Benoît Sibaud wrote:
Je ne saisis pas bien la question... les 3 implémentations ont les
mêmes prototypes de fonctions (mais pas dans le même ordre dans ce
que tu donnes). Où vois-tu la différence ?
La valeur de retour est un itérateur ou void suivant les cas.
ah... exact. Je n'avais pas vu :S Je vais voir dans le Stroustup...
p. 487 :
les 2 erase avec les iterateurs retournent void, celle avec const
key_type retourne size_type.
Dinkumware s'est donnée une liberté (volontairement ?) bien
bizarre...
Bizarre, je ne sais pas. Il me paraît bien utile, et un peu bizarre que
les fonctions renvoient void dans la norme. Pourquoi est-ce qu'on
renvoie les itérateurs dans les séquences, et non dans les collections
associatives. Il y a au moins une manque d'orthogonalité.
En fait, je crois que Dinkumware a fait la décision avant que la norme a
été fixée. Et ne l'a pas changé par la suite de peur de casser du code
existant. D'autant plus que pratiquement, la seule fois qu'une
application vera la différence, c'est si elle prend l'adresse de la
fonction membre.
Quel iterator on obtient après un erase () ? (end() ?),
Tu veux dire, en supposant que la fonction existait ?
ou même après un erase (begin(), begin()+1) ?
Dans tous les cas, l'itérateur renvoyé par erase() doit désigner le
premier élément suivant le dernier élément effacer, ou end() s'il n'y a
pas de tel élément. L'idiome consacré est :
Collection::iterator i = c.begin() ;
while ( i != c.end() ) {
if ( condition( *i ) ) {
i = c.erase( i ) ;
} else {
++ i ;
}
}
J'avoue ne pas comprendre pourquoi cette idiome doit marcher avec des
séquences, et non avec des collections associatives.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michaël Cortex" wrote in message news:<0UD5b.113798$...
Benoît Sibaud wrote:
Je ne saisis pas bien la question... les 3 implémentations ont les mêmes prototypes de fonctions (mais pas dans le même ordre dans ce que tu donnes). Où vois-tu la différence ?
La valeur de retour est un itérateur ou void suivant les cas.
ah... exact. Je n'avais pas vu :S Je vais voir dans le Stroustup...
p. 487 : les 2 erase avec les iterateurs retournent void, celle avec const key_type retourne size_type.
Dinkumware s'est donnée une liberté (volontairement ?) bien bizarre...
Bizarre, je ne sais pas. Il me paraît bien utile, et un peu bizarre que les fonctions renvoient void dans la norme. Pourquoi est-ce qu'on renvoie les itérateurs dans les séquences, et non dans les collections associatives. Il y a au moins une manque d'orthogonalité.
En fait, je crois que Dinkumware a fait la décision avant que la norme a été fixée. Et ne l'a pas changé par la suite de peur de casser du code existant. D'autant plus que pratiquement, la seule fois qu'une application vera la différence, c'est si elle prend l'adresse de la fonction membre.
Quel iterator on obtient après un erase () ? (end() ?),
Tu veux dire, en supposant que la fonction existait ?
ou même après un erase (begin(), begin()+1) ?
Dans tous les cas, l'itérateur renvoyé par erase() doit désigner le premier élément suivant le dernier élément effacer, ou end() s'il n'y a pas de tel élément. L'idiome consacré est :
Collection::iterator i = c.begin() ; while ( i != c.end() ) { if ( condition( *i ) ) { i = c.erase( i ) ; } else { ++ i ; } }
J'avoue ne pas comprendre pourquoi cette idiome doit marcher avec des séquences, et non avec des collections associatives.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
Alain Migeon writes:
| In article , | says... | > Alain Migeon writes: | > | > | Sinon, petite question. Pourquoi une fonction erase retournerait-elle un | > | iterator? | > | > parce qu'elle peut. ;-) | | Elle pourrait aussi imprimer : "Adieu, monde cruel...". ;-))
ça elle peut pas toujours :-)
| Mais, plus sérieusement, quelle est la valeur retournée?
Je ne sais pas mais , je présume que c'est comme dans le cas des suites (i.e. list, vector, ..).
| Une copie de l'iterator effacé?
Non.
| L'élément suivant dans la liste dans le cas de <vector>?
s'il existe, sinon end().
-- Gaby
Alain Migeon <agm@dk.rovsing> writes:
| In article <m3llt4q1s9.fsf@uniton.integrable-solutions.net>,
| gdr@integrable-solutions.net says...
| > Alain Migeon <agm@dk.rovsing> writes:
| >
| > | Sinon, petite question. Pourquoi une fonction erase retournerait-elle un
| > | iterator?
| >
| > parce qu'elle peut. ;-)
|
| Elle pourrait aussi imprimer : "Adieu, monde cruel...". ;-))
ça elle peut pas toujours :-)
| Mais, plus sérieusement, quelle est la valeur retournée?
Je ne sais pas mais , je présume que c'est comme dans le cas des
suites (i.e. list, vector, ..).
| Une copie de l'iterator effacé?
Non.
| L'élément suivant dans la liste dans le cas de <vector>?
| In article , | says... | > Alain Migeon writes: | > | > | Sinon, petite question. Pourquoi une fonction erase retournerait-elle un | > | iterator? | > | > parce qu'elle peut. ;-) | | Elle pourrait aussi imprimer : "Adieu, monde cruel...". ;-))
ça elle peut pas toujours :-)
| Mais, plus sérieusement, quelle est la valeur retournée?
Je ne sais pas mais , je présume que c'est comme dans le cas des suites (i.e. list, vector, ..).
| Une copie de l'iterator effacé?
Non.
| L'élément suivant dans la liste dans le cas de <vector>?
s'il existe, sinon end().
-- Gaby
Benoît Sibaud
Ce n'est pas ce que j'y vois (heureusement !). Là où tu vois ça, c'est dans l'explication de ce qui est nécessaire pour le conteneur utilisable pour instancier stack. Regarde un peu plus haut et tu verras que stack a bien top/pop/push.
Effectivement, je me bats ma coulpe honteusement.
-- Benoît Sibaud
Ce n'est pas ce que j'y vois (heureusement !). Là où tu vois
ça, c'est dans l'explication de ce qui est nécessaire pour le
conteneur utilisable pour instancier stack. Regarde un peu
plus haut et tu verras que stack a bien top/pop/push.
Ce n'est pas ce que j'y vois (heureusement !). Là où tu vois ça, c'est dans l'explication de ce qui est nécessaire pour le conteneur utilisable pour instancier stack. Regarde un peu plus haut et tu verras que stack a bien top/pop/push.
