Sens de const - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Sens de const
Goto page Previous 1, 2, 3, 4, 5 ... 48, 49, 50 Next

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

kanze
Guest

Posted: Thu Feb 02, 2006 10:01 am Post subject: Re: Sens de const

Yoxoman wrote:

Quote:

kanze <kanze@gabi-soft.fr> a écrit :

Yoxoman wrote:
kanze <kanze@gabi-soft.fr> a écrit :

Où j'ai un problème, c'est cette distinction entre «
erase » et « remove ». Parce qu'en fin de compte,
list<>::erase() et list<>::remove font exactement la
même chose -- la seule différence, c'est dans leur
manière de choisir l'élément ou les éléments à enlever.

Ils ne font pas *exactement* la même chose, heureusement.

Et qu'est-ce qu'ils font de différent ? list<>::erase() ôte
des éléments de la liste. list<>::remove() ôte des éléments
de la liste. La seule différence, c'est la manière de
désigner les éléments.

Nicolas Sarkozy et Olivier Besancenot font exactement la même
chose : de la politique.

Tout dépend du degré de précision que tu donnes à la *chose*.
Pour moi, il y a une différence entre ôter des éléments
déterminés (au sens où *je* détermine), et ôter des éléments
qui correspondent à une partie déterminée de la liste.

On ôte des éléments déterminés dans les deux cas. La seule
différence, c'est dans la manière de les déterminer. Or, au
moins en anglais, les mots « remove » et « erase » n'ont aucun
rapport avec la manière de choisir ce qui est enlevé ou ce qui
est effacé.

(Si on voulait chercher plus loin, on dirait que « remove »
enleve l'élément complétement, tandis qu'« erase » ne fait que
l'effacer, en laissant le support. C-à-d qu'« erase » appelerait
le destructeur, mais ne libèrerait pas la mémoire. Mais il ne
faut pas exagérer.)

Mais en fin de compte, tu as esquivé la question : en quoi
est-ce que ces deux opérations diffèrent ? Qu'est-ce qu'ils font
de différent pour justifier un nom différent ?

Quote:

Et cela peut justifier leur différence terminologique :
dans leurs actions, erase et remove ne s'appliquent pas à
la même structure.

Ils s'appliquent tous les deux à list<>. Obligatoire, en fin
de compte, parce qu'elles sont des fonctions membre.

J'avais remarqué, merci. Ce que je veux dire, c'est que
list<>::erase s'oriente (sémantiquement) vers la liste
elle-même, tandis que list <>::remove s'oriente
(sémantiquement) vers les éléments de la liste.

Ce qui veut dire quoi ? Tous les deux s'appliquent à une liste.
Tous les deux enlèvent des éléments de la liste, et donc
travaillent sur des éléments. (Si tu régardes l'implémentation,
tu verras probablement que tous les deux font appel à la même
fonction interne.)

Quote:

Et je trouve que ça correspond bien avec la différence de
niveau auxquels s'appliquent les termes effacer et enlever.

Mais selon quel critère ? Tous les deux sont des verbes
transitifs, dont l'objet direct, ici, est l'élément. Si je
regarde le TLFI, effacer est « faire disparaître » ; une des
définitions de « enlever », c'est « Déplacer un objet en le
sortant de l'endroit qu'il occupe [...] en l'effaçant, en le
supprimant ».

Dans le contexte ici, je crois qu'on peut dire qu'« enlever » a
la signification donnée en paragraphe II.C du TLFI. Où le
premier exemple est « enlever un nom d'une liste [...] ». Ce qui
est exactement ce que fait list<>::erase() (et list<>::remove(),
évidemment, vue que les deux font la même chose).

Dans le cas d'« effacer », on n'est amené à considérer que les
significations du paragraphe I.A. (§II couvre les emplois
pronominaux, et §I.B les significations « Empêcher de
paraître@», qui ne me semble pas convenir non plus.) Or, parmi
les utilisations dans §I.A, la seule qui semblerait permise ici
est §I.A.1.b : « Éliminer, faire disparaître (quelque chose) ».
Et là non plus, pas le moindre soupçon que les critères de choix
de ce qu'on élimine entre en ligne de compte.

En somme, ta distinction d'« orientation » ne trouve pas de
justification dans la langue telle qu'elle s'emploie
généralement.

Quote:

L'action d'effacer quelque chose se base sur ce quelque chose
et s'applique au contenu de ce quelque chose, alors que
l'action d'enlever quelque chose se base sur ce quelque chose
et s'applique à ce quelque chose lui-même.

Ce qui donne :

list<>::erase se base sur une partie de la liste et s'applique
à son contenu (ses éléments, qu'il ôte), alors que
list<>::remove se base sur des éléments déterminés (par moi)
de la liste, et s'applique sur ces éléments eux-mêmes (il les
ôte).

C'est moi qui détermine les éléments à enlever. Dans les deux
cas. Les deux fonctions s'applique à la liste, et enlever les
éléments -- évidemment (ou heureusement), elles opèrent aussi
sur les éléments : elles en appellent le destructeur, en libère
la mémoire, etc.

Quote:

C'est mon point de vue, et j'espère être clair.

C'est ton point de vue, mais d'une part, je ne vois toujours pas
la différence que tu sembles y voir, et de l'autre, ton
utilisation des mots « effacer » et « enlever » ne correspond
pas à ce que décrit le TLFI.

Quote:

Je trouve que ça justifie leur différence terminologique.
C'est tout ce que je voulais dire.

Mais pour ça, il faut que tu donnes aux mots une signification
qu'ils n'ont pas.

Il y a une différence dans les deux fonctions : la façon qu'on
désigne ce qui est à enlever. Ça, je crois que personne ne le
dispute. Mais ni « remove » ni « erase » ne contient la moindre
nuace à cet égard -- dans ce cas-ci, le choix d'un ou de l'autre
relève d'un goût personel, et l'un ou l'autre ferait également
bien l'affaire. C'est simplement l'utilisation des deux comme
synonymes qui me gène.

(En fait, quand j'ai écrit ma propre classe de liste, tout au
début, mon premier choix de nom pour cette fonction était
delete. C'est un mot technique, très précis. Mais le compilateur
n'était pas d'accord à ce que je l'utilise.)

Quote:

list<>::erase a une sémantique orientée ensemble : on
invalide une partie de la liste, en bloc.

list<>::remove a une sémantique orientée élément : on
invalide des éléments déterminés de l'ensemble "liste".

Toutes les deux ôte des éléments déterminés. Elles ne
diffèrent que dans la façon à désigner les éléments.

Déterminés par qui ?

Par l'utilisateur. Dans tous les cas. Une fonction où c'est la
liste même qui détermine ce qu'elle veut enlever ne serait pas
particulièrement intéressante.

Quote:

Dans list<>::erase, je ne détermine pas les éléments à ôter.

Bien sûr que si. C'est bien toi qui fournis l'itérateur ou les
itérateurs.

Quote:

Par contre, je détermine la partie de la liste dont je veux
ôter les éléments.

Tout à fait. De même que dans le cas de list<>::remove(), c'est
moi qui détermine la condition d'effacement.

La chose qui diffère, ce n'est pas qui fait le choix, mais
comment on précise ce choix.

Quote:

Mais l'action est tout de même comparable à celle de
list<>::remove, donc il peut sembler normal d'avoir le
même nom.

L'action de déplacer un objet dans une suite est comparable
à l'action de l'ôter de la suite ? Tu m'étonnes de plus en
plus.

Si les actions se résument pour toi à *ôter* et *déplacer*,
non.

Quelles sont les autres actions en question ?

En fait, il y a une signification de « remove » qui pourrait
convenir -- quelque chose du genre « he removed the elements to
the end of the sequence » est compréhensible en anglais. Mais il
lève la question : d'où ? (Je me rabats sur l'anglais et « The
American Heritage Dictionary » ici, parce qu'enlever et remove
ne sont pas tout à fait identiques dans leurs significations.)

Mais la première signification rest « To move from a place or
postion occupied », avec comme exemple « removed the cups from
the table ». Ici, la seule « place or position occupied » dont
il peut être question, c'est bien la suite. (Il y a aussi une
signification « to do away with; eliminate », qui pourrait
convenir dans son emploi dans list<>::remove.)

Quote:

C'est bien sûr ailleurs qu'elles se comparent.

#include <iostream
#include <list
#include <iterator

int main()
{
std::list<int> l;
typedef std::list<int>::iterator list_iter;

l.push_back(1);
l.push_back(2);
l.push_back(3);
l.push_back(2);

//l.remove(2); (1)
//list_iter it = std::remove(l.begin(), l.end(), 2); (2)

std::copy(l.begin(), l.end(),
std::ostream_iterator<int>(std::cout, " "));
}

avec (1), on obtient 1 3.
avec (2), on obtient 1 3 3 2, it désigne le troisième élément, et donc
la plage [l.begin(), it), c'est 1 3.

Je trouve ça comparable. Si ça t'étonne, tant pis.

On peut les utiliser pour atteindre les mêmes fins, dans certains
cas. C'est loin de signifier qu'elles font la même chose.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ
Guest

Posted: Fri Feb 03, 2006 2:00 am Post subject: Re: Sens de const

On Wed, 1 Feb 2006 11:40:49 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

Quote:

J'avais remarqué, merci. Ce que je veux dire, c'est que list<>::erase
s'oriente (sémantiquement) vers la liste elle-même, tandis que list
::remove s'oriente (sémantiquement) vers les éléments de la liste.

Si le choix des mots n'était pas dû au hasard, il aurait fallu
reprendre la même sémantique que pour le couple find/find_if, et
donner à list<>::remove le nom "erase_if".

kanze
Guest

Posted: Fri Feb 03, 2006 10:01 am Post subject: Re: Sens de const

Fabien LE LEZ wrote:

Quote:

On Wed, 1 Feb 2006 11:40:49 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

J'avais remarqué, merci. Ce que je veux dire, c'est que
list<>::erase s'oriente (sémantiquement) vers la liste
elle-même, tandis que list <>::remove s'oriente
(sémantiquement) vers les éléments de la liste.

Si le choix des mots n'était pas dû au hasard, il aurait fallu
reprendre la même sémantique que pour le couple find/find_if,
et donner à list<>::remove le nom "erase_if".

À l'état actuel du langage, je crois qu'il n'y aurait même pas
besoin de « _if », au moins dans les fonctions membre. On
pourrait très bien faire un surcharge :

iterator erase( iterator ) ;
iterator erase( iterator, iterator ) ;
iterator erase( value_type ) ;
template< typename Predicate >
iterator erase( Predicate ) ;

Avec la méta-programmation, le template renvoie à une des autres
versions dans le cas où Predicate n'en est pas un (c-à-d qu'il
ne permet pas p( value_type ), avec un type de retour qui
pourrait servir de condition), mais qu'il se convertit
implicitement en iterator ou en value_type.

Une technique semblable pourrait même peut-être servir pour les
fonctions libre, du genre remove et remove_if ; je ne suis pas
sûr.

Mais tout ça, c'est à l'état actuel du langage, et avec les
connaissances des techniques qu'on a aujourd'hui. À l'époque où
Stepanov développait, en revanche, sûrement pas. D'où les noms
distincts.

Dans le cas d'erase et de remove, j'imagine que c'est simplement
parce qu'il avait besoin de deux noms différents, parce que la
résolution de surcharge ne suffisait pas, et qu'il trouvait que
ces deux mots étaient en fait synonymes, au moins ici. Et
erase_if ne marchait pas, parce qu'il aurait fallu alors trois
variants : erase_at( iterator ), erase_if( predicate ) et
erase_if_equal( value ). (Personellement, j'aurais préfèrait
ces noms-là.)

De la même façon, je crois que l'intention de la fonction libre
remove, c'était bien d'enlever les éléments de la suite.
Seulement, techniquement, ce n'était pas possible. Alors, on a
modifier la sémantique pour déplacer les éléments vers la fin,
et renvoyer l'information nécessaire pour qu'on puisse les
enlever. (Seulement, évidemment, elle ne déplace pas les
éléments à enlever à la fin ; elle déplace les éléments à ne
pas
enlever vers le début.) Malheureusement, on n'a pas changé de
nom quand on a changé la sémantique. (Mais j'avoue que j'ai du
mal à trouver un nom qui convient bien à la sémantique réele.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ
Guest

Posted: Fri Feb 03, 2006 10:01 am Post subject: Re: Sens de const

On 3 Feb 2006 01:18:01 -0800, "kanze" <kanze@gabi-soft.fr>:

Quote:

(Mais j'avoue que j'ai du
mal à trouver un nom qui convient bien à la sémantique réele.)

kick_to_the_end_if ?

Gabriel Dos Reis
Guest

Posted: Fri Feb 03, 2006 10:01 am Post subject: Re: Sens de const

"kanze" <kanze@gabi-soft.fr> writes: \| Fabien LE LEZ wrote: \| > On Wed, 1 Feb 2006 11:40:49 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>: \| \| > >J'avais remarqué, merci. Ce que je veux dire, c'est que \| > >list<>::erase s'oriente (sémantiquement) vers la liste \| > >elle-même, tandis que list <>::remove s'oriente \| > >(sémantiquement) vers les éléments de la liste. \| \| > Si le choix des mots n'était pas dû au hasard, il aurait fallu \| > reprendre la même sémantique que pour le couple find/find_if, \| > et donner à list<>::remove le nom "erase_if". \| \| À l'état actuel du langage, je crois qu'il n'y aurait même pas \| besoin de « _if », au moins dans les fonctions membre. On \| pourrait très bien faire un surcharge : \| \| iterator erase( iterator ) ; \| iterator erase( iterator, iterator ) ; \| iterator erase( value_type ) ; \| template< typename Predicate > \| iterator erase( Predicate ) ; \| \| Avec la méta-programmation, le template renvoie à une des autres tu veux dire des hacks horrible comme enable_if? \| versions dans le cas où Predicate n'en est pas un (c-à-d qu'il \| ne permet pas p( value_type ), avec un type de retour qui \| pourrait servir de condition), mais qu'il se convertit \| implicitement en iterator ou en value_type. \| \| Une technique semblable pourrait même peut-être servir pour les \| fonctions libre, du genre remove et remove_if ; je ne suis pas \| sûr. \| \| Mais tout ça, c'est à l'état actuel du langage, et avec les \| connaissances des techniques qu'on a aujourd'hui. À l'époque où \| Stepanov développait, en revanche, sûrement pas. D'où les noms \| distincts. Je sais pas. Je préfère encore le suffix _if aux hacks horribles. -- Gaby

Yoxoman
Guest

Posted: Fri Feb 03, 2006 11:01 am Post subject: Re: Sens de const

kanze <kanze@gabi-soft.fr> a écrit :

Quote:

Tout dépend du degré de précision que tu donnes à la *chose*.
Pour moi, il y a une différence entre ôter des éléments
déterminés (au sens où *je* détermine), et ôter des éléments
qui correspondent à une partie déterminée de la liste.

On ôte des éléments déterminés dans les deux cas.

Je ne suis pas d'accord. On peut chipoter sur le sens du verbe
"déterminer", mais je pense qu'en appliquant list<>::erase sur une
partie d'une centaine de termes, on ne determine pas les éléments en
question.

Quote:

Bof.

Quote:

Mais en fin de compte, tu as esquivé la question : en quoi
est-ce que ces deux opérations diffèrent ? Qu'est-ce qu'ils font
de différent pour justifier un nom différent ?

?

-- A la question "en quoi est-ce que les deux opérations diffèrent ?" :

* D'un point de vue sémantique, je ne vois pas ce que je peux dire de
plus que ce que j'ai déjà dit.

Les concepteurs de la STL ont fait de choix d'utiliser le terme "erase"
pour désigner une fonction qui efface une partie *déterminée* (par
l'utilisateur) d'une liste (singleton, intervalle). L'utilisateur
regarde sa liste, et, s'il a besoin d'en ôter un bloc, il se dit : je
vais utiliser "erase". Ca tombe bien (choix ou hasard, mystère), le
terme "erase", dans le langage courant, peut s'appliquer sur ce type de
structure. En effet, on dit bien "erase the blackboard". Alors qu'on ne
dirait pas "remove the blackboard", sauf pour signifier autre chose.
(désolé pour le blackboard, je ne suis pas bilingue, mais je suppose que
ça s'applique à toute surface sur laquelle on peut marquer quelque
chose).

D'un autre côté, ils ont fait le choix d'utiliser le terme "remove" pour
désigner une fonction qui efface tous les éléments que l'utilisateur
*détermine*. L'utilisateur regarde sa liste, et, s'il a besoin d'ôter
des éléments particuliers, il se dit : je vais utiliser "remove".

* D'un point de vue pratique, par exemple :

Soit le problème suivant : on a une liste d'entiers. Ecrire une
fonction qui ôte de la liste tous les éléments qui sont après le premier
zéro (celui-ci compris) de la liste, s'il existe.

Voici ce que ma très modeste compétence en C++ me permet de faire :

#include <iostream>
#include <list>
#include <iterator>

void erase_after_zero(std::list<int>& l)
{
typedef std::list<int>::iterator list_iter;

list_iter it = std::find(l.begin(), l.end(), 0);
if (it != l.end()) {
l.erase(it, l.end());
}
}

// test
int main()
{
std::list<int> l;

l.push_back(2);
l.push_back(0);
l.push_back(1);
l.push_back(2);

erase_after_zero(l);

std::copy(l.begin(), l.end(),
std::ostream_iterator<int>(std::cout, " "));
}

Qui affiche 2. OK.

Tu fais comment, avec list<>::remove ?

-- A la question "qu'est-ce qui justifie un nom différent ?" :

La différence sémantique.

Pourquoi ne pas avoir gardé le terme "erase" pour list<>::remove, ou
l'inverse ? Peut-être pour appuyer sur la différence sémantique entre
les deux fonctions (partie déterminée <-> valeur déterminée).

Aurait-on pu echanger les deux noms ? Bof. Le terme "erase" s'applique
bien à la fonction list<>::erase, car ils suggèrent tous deux une
dualité surface <-> marquage, ou ensemble <-> élément : effacer une
surface, et hop le marquage disparait ; list<>::erase une partie de la
liste, et hop les éléments disparaissent.
Pour list<>::remove, on n'a pas besoin de cette dualité. On a juste des
éléments, et on retire ceux d'une certaine forme.

Quote:

J'avais remarqué, merci. Ce que je veux dire, c'est que
list<>::erase s'oriente (sémantiquement) vers la liste
elle-même, tandis que list <>::remove s'oriente
(sémantiquement) vers les éléments de la liste.

Ce qui veut dire quoi ? Tous les deux s'appliquent à une liste.

Au niveau C++, oui. Mais tout ce que ça, ça signifie, c'est que les
fonction sont dans la même portée.

Quote:

Je dois dire ici que je suis parti sur une mauvaise définition de
"effacer". Pour d'obscures raisons, j'ai pensé que la définition
première du terme s'appliquait à une surface dont on faisait disparaitre
les marques (pour reprendre les mots du TLFI). Par exemple : "effacer le
tableau". Alors que la définition exacte voudrait apparemment qu'on
écrive "effacer *ce qu'il y a sur* le tableau". Je remarque que ce
racourci n'apparait même pas la définition. Soit.

Cependant, l'abus reste valable, et au cas où tu n'aurais pas compris,
c'est sur celui-ci que je me base. Tu as d'ailleurs fait mention d'un
"erase the blackboard" dans un post précédent, si je ne m'abuse. Tu
conviendra sans doute qu'il n'a pas le même sens qu'un "remove the
blackboard", qu'il faudrait transformer en "remove *all that is on* the
blackboard".

L'abus est classique. Par exemple, sur le lien

http://www.sgi.com/tech/stl/List.html

au niveau de list<>::erase avec comme argument deux itérateurs, on lit
bien "Erases the range [first, last)", et non "Erases the elements in
the range [first, last)".

Quote:

Non. Si le nom apparait plusieurs fois, un appel à cette fonction ne
marchera pas. Il faudrait plusieurs appels, ce qui n'a plus de sens.

Quote:

(et list<>::remove(),
évidemment, vue que les deux font la même chose).

Ca n'engage que toi.

Quote:

Dans le cas d'« effacer », on n'est amené à considérer que les
significations du paragraphe I.A. (§II couvre les emplois
pronominaux, et §I.B les significations « Empêcher de
paraître@», qui ne me semble pas convenir non plus.) Or, parmi
les utilisations dans §I.A, la seule qui semblerait permise ici
est §I.A.1.b : « Éliminer, faire disparaître (quelque chose) ».
Et là non plus, pas le moindre soupçon que les critères de choix
de ce qu'on élimine entre en ligne de compte.

Moi, je choisirais la première (I.A.1.a) : "faire disparaitre totalement
(ce qui est tracé ou marqué sur une surface)". Parce que la partie entre
parenthèses fait apparaitre cette dualité entre ensemble (la surface) et
les éléments (les marques). C'est celle qui permet l'abus "effacer une
feuille", "effacer un mur"...

Quote:

En somme, ta distinction d'« orientation » ne trouve pas de
justification dans la langue telle qu'elle s'emploie
généralement.

Si. Pas dans sa définition exacte, mais dans des abus courants.
N'emploie-t-on pas généralement l'expression "effacer le
tableau" ?

Quote:

Pas d'accord.

Quote:

[...]

Je trouve que ça justifie leur différence terminologique.
C'est tout ce que je voulais dire.

Mais pour ça, il faut que tu donnes aux mots une signification
qu'ils n'ont pas.

....dans le dictionnaire. Bien que je serais étonné qu'aucun
dictionnaire n'en fasse mention.

Quote:

[...]

Déterminés par qui ?

Par l'utilisateur. Dans tous les cas. Une fonction où c'est la
liste même qui détermine ce qu'elle veut enlever ne serait pas
particulièrement intéressante.

Pas besoin de déterminer un élément pour l'enlever.

Quote:

Dans list<>::erase, je ne détermine pas les éléments à ôter.

Bien sûr que si. C'est bien toi qui fournis l'itérateur ou les
itérateurs.

Et les itérateurs correspondent à une position. Ce que je determine,
c'est la position, pas ce qui se trouve à cette position, que je le
sache ou non.

Quote:

[...]

Si les actions se résument pour toi à *ôter* et *déplacer*,
non.

Quelles sont les autres actions en question ?

Je ne dis pas qu'il y a d'autres actions, je dis que les actions ne se
résument pas *forcément* à "ôter" et "déplacer".

Ton "ôter" pourrait devenir "ôter les éléments qui correspondent à une
certaine valeur", et ton "déplacer" pourrait devenir "remplacer les
éléments de telle sorte que la liste tronquée à un intervalle commençant
par begin() corresponde à celle qu'on aurait construit en ôtant les
éléments qui correspondent à une certaine valeur. Conserver la valeur
des éléments qui sont en dehors de l'intervalle" (j'ai pas trouvé mieux,
désolé).

Du coup, ça devient comparable.

Au fait, je ne comprend pas ton emploi du terme "déplacer" pour
std::remove.

Quote:

[...]

Je trouve ça comparable. Si ça t'étonne, tant pis.

On peut les utiliser pour atteindre les mêmes fins, dans certains
cas. C'est loin de signifier qu'elles font la même chose.

Qui a dit qu'elles faisaient la même chose ? Moi, j'ai dit qu'elles
étaient comparables.

--
"Yo!"
Martin Heidegger

Yoxoman
Guest

Posted: Fri Feb 03, 2006 12:01 pm Post subject: Re: Sens de const

Fabien LE LEZ <gramster (AT) gramster (DOT) com> a écrit :

Quote:

On Wed, 1 Feb 2006 11:40:49 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

J'avais remarqué, merci. Ce que je veux dire, c'est que list<>::erase
s'oriente (sémantiquement) vers la liste elle-même, tandis que list
::remove s'oriente (sémantiquement) vers les éléments de la liste.

Si le choix des mots n'était pas dû au hasard, il aurait fallu
reprendre la même sémantique que pour le couple find/find_if, et
donner à list<>::remove le nom "erase_if".

Je ne comprend pas.

"_if" suggère un prédicat, et la seule différence entre find et find_if
est la présence d'un prédicat au lieu d'une valeur.

Je trouve la différence sémantique entre list<>::erase et list<>::remove
beaucoup plus forte. Et aucune des deux fonctions n'accepte de prédicat
dans ses arguments.

--
"Yo!"
Martin Heidegger

kanze
Guest

Posted: Mon Feb 06, 2006 9:03 am Post subject: Re: Sens de const

Gabriel Dos Reis wrote:

Quote:

"kanze" <kanze@gabi-soft.fr> writes:

Fabien LE LEZ wrote:
On Wed, 1 Feb 2006 11:40:49 +0100, Yoxoman
yhpnfyrqber (AT) tznvy (DOT) pbz>:

J'avais remarqué, merci. Ce que je veux dire, c'est que
list<>::erase s'oriente (sémantiquement) vers la liste
elle-même, tandis que list <>::remove s'oriente
(sémantiquement) vers les éléments de la liste.

Si le choix des mots n'était pas dû au hasard, il aurait
fallu reprendre la même sémantique que pour le couple
find/find_if, et donner à list<>::remove le nom
"erase_if".

À l'état actuel du langage, je crois qu'il n'y aurait même
pas besoin de « _if », au moins dans les fonctions membre.
On pourrait très bien faire un surcharge :

iterator erase( iterator ) ;
iterator erase( iterator, iterator ) ;
iterator erase( value_type ) ;
template< typename Predicate
iterator erase( Predicate ) ;

Avec la méta-programmation, le template renvoie à une des autres

tu veux dire des hacks horrible comme enable_if?

Plus ou moins. À vrai dire, je ne m'y connais pas assez pour
juger.

Quote:

versions dans le cas où Predicate n'en est pas un (c-à-d
qu'il ne permet pas p( value_type ), avec un type de retour
qui pourrait servir de condition), mais qu'il se convertit
implicitement en iterator ou en value_type.

Une technique semblable pourrait même peut-être servir pour
les fonctions libre, du genre remove et remove_if ; je ne
suis pas sûr.

Mais tout ça, c'est à l'état actuel du langage, et avec les
connaissances des techniques qu'on a aujourd'hui. À l'époque
où Stepanov développait, en revanche, sûrement pas. D'où les
noms distincts.

Je sais pas. Je préfère encore le suffix _if aux hacks horribles.

En fait, je crois que moi aussi. À la rigueur, j'aurais préférer
n'avoir que les formes à prédicate, avec un objet prédicate
prédéfini pour l'égalité. Au moins sur le plan théorique -- dans
la pratique, la solution avec _if marche plutôt bien. (J'aurais
probablement choisi find et find_eq, avec la version à prédicate
sans marque particulière. Mais c'est vraiment une distinction
mineur et sans importance.)

Dans le cas de std::list : pourquoi pas : remove_element,
remove_range, remove_eq et remove_if ? L'utilisation de erase et
de remove me semble un peu arbitraire.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ
Guest

Posted: Mon Feb 06, 2006 11:03 am Post subject: Re: Sens de const

On 6 Feb 2006 00:49:03 -0800, "kanze" <kanze@gabi-soft.fr>:

Quote:

Dans le cas de std::list : pourquoi pas : remove_element,
remove_range, remove_eq et remove_if ?

Si std::remove() n'efface pas d'éléments, une fonction membre qui en
efface ne devrait pas s'appeler remove.
Donc, pour suivre ton idée : list<>::erase_element,
list<>::erase_range, list<>::erase_eq et list<>::erase_if.

kanze
Guest

Posted: Mon Feb 06, 2006 12:02 pm Post subject: Re: Sens de const

Yoxoman wrote:

Quote:

kanze <kanze@gabi-soft.fr> a écrit :

Tout dépend du degré de précision que tu donnes à la
*chose*. Pour moi, il y a une différence entre ôter des
éléments déterminés (au sens où *je* détermine), et ôter
des éléments qui correspondent à une partie déterminée de
la liste.

On ôte des éléments déterminés dans les deux cas.

Je ne suis pas d'accord. On peut chipoter sur le sens du verbe
"déterminer", mais je pense qu'en appliquant list<>::erase sur
une partie d'une centaine de termes, on ne determine pas les
éléments en question.

Qui les détermine, alors ? La fonction n'enlève pas des éléments
aléatoires -- elle enlève les éléments qui je lui dis d'enlever.

Quote:

La seule différence, c'est dans la manière de les
déterminer. Or, au moins en anglais, les mots « remove » et
« erase » n'ont aucun rapport avec la manière de choisir ce
qui est enlevé ou ce qui est effacé. (Si on voulait chercher
plus loin, on dirait que « remove » enleve l'élément
complétement, tandis qu'« erase » ne fait que l'effacer, en
laissant le support. C-à-d qu'« erase » appelerait le
destructeur, mais ne libèrerait pas la mémoire. Mais il ne
faut pas exagérer.)

Bof.

Mais en fin de compte, tu as esquivé la question : en quoi
est-ce que ces deux opérations diffèrent ? Qu'est-ce qu'ils
font de différent pour justifier un nom différent ?

?

-- A la question "en quoi est-ce que les deux opérations diffèrent ?" :

* D'un point de vue sémantique, je ne vois pas ce que je peux
dire de plus que ce que j'ai déjà dit.

Jusqu'ici, tu n'en as rien dit. Sauf un vague sentiment sur une
sémantique des mots mêmes, qui est tout à fait personnel et
arbitraire, dans la mesure où il ne correspond pas à
l'utilisation habituelle, telle qu'elle est décrite dans TLFI
(pour le français) ou « American Heritage Dictionary » pour
l'anglais.

Quote:

Les concepteurs de la STL ont fait de choix d'utiliser le
terme "erase" pour désigner une fonction qui efface une partie
*déterminée* (par l'utilisateur) d'une liste (singleton,
intervalle). L'utilisateur regarde sa liste, et, s'il a besoin
d'en ôter un bloc, il se dit : je vais utiliser "erase". Ca
tombe bien (choix ou hasard, mystère), le terme "erase", dans
le langage courant, peut s'appliquer sur ce type de structure.
En effet, on dit bien "erase the blackboard".

Sauf que la fonction qui correspondrait à « erase the
blackboard » s'appelle clear. On est amener à « erase x from the
blackboard », où « x » spécifie ce qu'on veut effacer. Dans ce
sens-là, dans ce contexte, le mot « erase » étonne un peu -- la
signification primitive est « to remove by rubbing, wiping, or
scraping », c-à-d d'enlever d'une façon particulière (qui ne
s'applique pas ici). Mais on l'a déjà étendu à l'effacement
d'une bande magnétique, etc. Il y a aussi une signification « to
remove all traces of ». Dans une explication plus étendue, le
«@American Heritage Dictionary » dit « These verbs mean to
remove or invalidate somthing, especially something stored,
recorded or written down. » (En fait, en lisant ces
explications, il est apparent que le mot qui conviendrait le
plus, c'est « delete ». Mais il y a de très fortes raisons
techniques pour ne pas l'utiliser ici.)

J'avoue que ce que dit le « American Heritage Dictionary »
correspond à mon intuition pour le langage -- « erase »
correspond primorialement à une certaine façon de « remove » ;
on peut l'utiliser par extention quand il y a analogie -- le
contenu d'une bande magnetique est une forme d'écriture, par
exemple. On peut aussi l'utiliser par extension dans des cas
abstraits : « erase a thought from one's mind ». Mais il ne
convient pas vraiment ici, où on verrait plus facilement
« remove » ou encore plus précis « delete » (seulement qu'en
C++, « delete » est déjà pris).

Quote:

Alors qu'on ne dirait pas "remove the blackboard", sauf pour
signifier autre chose. (désolé pour le blackboard, je ne suis
pas bilingue, mais je suppose que ça s'applique à toute
surface sur laquelle on peut marquer quelque chose).

Tout à fait. Mais on ne dit pas ici « remove the list » non
plus. On dirait « remove the element », ou « remove the range »,
ou « remove the values » ou « remove the elements where x is
true ». En fait, je verrais bien les noms « remove_element »,
« remove_range », « remove_value » et « remove_if ».

Une nuance importante, dans toutes les significations de
« remove », est « from » -- on « remove » toujours quelque chose
de quelque part ou de quelque chose d'autre. C'est, je crois, ce
qui distingue « remove » des autres verbes à signification
rapprochante.

Quote:

D'un autre côté, ils ont fait le choix d'utiliser le terme
"remove" pour désigner une fonction qui efface tous les
éléments que l'utilisateur *détermine*.

Ils ont (ou plutôt il a) fait un choix arbitraire. Je comprends
bien qu'il ait voulu deux mots différents. Je comprends aussi
qu'il n'y a pas de mots dans le langage courant qui puissent
s'appliquer exactement, parce qu'on parle de quelque chose qui
n'existe pas dans le langage courant. N'empèche que l'action
dans les deux cas est rigueureusement identique -- on ôte des
éléments (0 à n) de la liste. De ce point de vue, « remove »
convient prèsque parfaitement. Si on prend en compte le fait
qu'on détruit ces éléments, « delete » conviendra mieux, mais
d'une part, le mot n'est pas disponible, et de l'autre, j'aurais
plutôt tendance à considére que le fait qu'on les detruit est
sécondaire, et lié à la sémantique de valeur qui est idiomatique
en C++.

En tant qu'anglophone, en revanche, « erase » sonne un peu
faux -- on le comprend, mais ce n'est pas le mot qu'un vrai
anglophone choisira (en supposant que son choix soient libre, et
non conditionné par des considérations techniques -- du genre,
il *faut* distinguer cette fonction d'une autre fonction, qui a
déjà le nom qu'on préfèrerait).

(En passant, l'auteur de la STL n'est pas anglophone, et il a
même un accent reconnaissable quand il parle. Mais je ne crois
pas que le problème vient de là ; je crois que c'est vraiement
un cas où il a trop de fonctions qu'il veut distinguer, et pas
assez de mots différents qui conviennent. Et dans le cas de
std::remove, pas de mot de tout qui convient.)

Quote:

L'utilisateur regarde sa liste, et, s'il a besoin d'ôter des
éléments particuliers, il se dit : je vais utiliser "remove".

Sauf que si j'ai besoin d'ôter un élément particulier, il faut
choisir entre « remove », « remove_if » et « erase », selon la
façon que je veux désigner l'élément.

En fait, le choix entre « remove_if » et « erase » se fait
souvent selon que j'ai un prédicate disponible, ou que je dois
en écrire un -- ou selon que le prédicate ait besoin des
variables locales ou non.

Quote:

* D'un point de vue pratique, par exemple :

Soit le problème suivant : on a une liste d'entiers. Ecrire
une fonction qui ôte de la liste tous les éléments qui sont
après le premier zéro (celui-ci compris) de la liste, s'il
existe.

Voici ce que ma très modeste compétence en C++ me permet de faire :

#include <iostream
#include <list
#include <iterator

void erase_after_zero(std::list<int>& l)
{
typedef std::list<int>::iterator list_iter;

list_iter it = std::find(l.begin(), l.end(), 0);
if (it != l.end()) {
l.erase(it, l.end());

Pourquoi pas simplement :

l.erase( st::find( l.begin(), l.end(), 0 ), l.end() ) ;

C'est l'écriture la plus naturelle avec la STL.

Quote:

}
}

// test
int main()
{
std::list<int> l;

l.push_back(2);
l.push_back(0);
l.push_back(1);
l.push_back(2);

erase_after_zero(l);

std::copy(l.begin(), l.end(),
std::ostream_iterator<int>(std::cout, " "));
}

Qui affiche 2. OK.

Tu fais comment, avec list<>::remove ?

On peut aussi le faire avec list<>::remove_if. Mais là n'est pas
la question. C'est claire que j'utilise la fonction qui convient
le mieux, quelque soit son nom. C'est aussi clair que si j'avais
à décrire ce que fait la fonction ci-dessus, en anglais courant,
je dirais que « it removes [ou deletes] all of the elements
after the first 0. » Il ne viendrait pas à l'ésprit d'un
anglophone d'utiliser « erase » dans ce cas-ci.

Sauf, évidemment, s'il voulait faire un rapprochement à la STL.
Mais ça, c'est une argumentation circulaire -- les noms de la
STL convient parce qu'ils conviennent à la signification qu'ils
ont dans la STL.

Quote:

-- A la question "qu'est-ce qui justifie un nom différent ?" :

La différence sémantique.

Il n'y a pas de différence dans la sémantique de base. La seule
différence, c'est dans la façon de désigner ce qui est à
enlever. Et l'idée de comment désigner ce qu'il y a à ôter
n'existe ni en « remove », en en « erase » -- au delà du simple
fait d'« ôter », « remove » implique « de quelque chose ou de
quelque part », et « erase » implique en première ligne une
façon particulière de le faire. Si tu enlèves en grattant ou en
essuyant, c'est « erase ». Par extension, si tu assimiles ce que
tu enlèves à une forme d'écriture, on peut aussi utiliser
«@erase ». Mais ni dans erase ni dans remove il n'y a le moindre
soupçon d'une idée de critère ou de choix.

Quote:

Pourquoi ne pas avoir gardé le terme "erase" pour
list<>::remove, ou l'inverse ?

Pourquoi, en effet ? Dans le contexte, on peut dire qu'il sont
synonymes. (Sauf qu'un anglophone n'utilisera pas « erase » dans
ce contexte, sauf contrainte externe.)

Quote:

Peut-être pour appuyer sur la différence sémantique entre les
deux fonctions (partie déterminée <-> valeur déterminée).

C'est une différence qui n'existe pas dans les deux mots.
Cherche les définitions dans un dictionnaire.

Quote:

Aurait-on pu echanger les deux noms ?

Ça n'aurait rien changer dans la compréhensibilité.

Quote:

Bof. Le terme "erase" s'applique bien à la fonction
list<>::erase, car ils suggèrent tous deux une dualité surface
-> marquage, ou ensemble <-> élément : effacer une surface,
et hop le marquage disparait ; list<>::erase une partie de la
liste, et hop les éléments disparaissent.

Exactement comme list<>::remove. Hop, les éléments
disparaissent.

Quote:

Pour list<>::remove, on n'a pas besoin de cette dualité. On a
juste des éléments, et on retire ceux d'une certaine forme.

Quelle dualité. On enlève quelque chose de quelque part ou de
quelque chose. Parmi les deux, c'est « erase » qui peut servir
dans un sens abstrait (mais ce n'est pas sa signification ici,
ou on enlève bien des éléments concrets).

Quote:

Non. Ça veut dire que je ne peux pas enlever les éléments sans
les enlever de quelque chose.

C'est aussi la raison pourquoi std::remove ne convient pas. Je
n'ai rien (au niveau de la fonction) d'où enlever les éléments.

Quote:

[...]

Et je trouve que ça correspond bien avec la différence de
niveau auxquels s'appliquent les termes effacer et
enlever.

Mais selon quel critère ? Tous les deux sont des verbes
transitifs, dont l'objet direct, ici, est l'élément. Si je
regarde le TLFI, effacer est « faire disparaître » ;

Je dois dire ici que je suis parti sur une mauvaise définition
de "effacer". Pour d'obscures raisons, j'ai pensé que la
définition première du terme s'appliquait à une surface dont
on faisait disparaitre les marques (pour reprendre les mots du
TLFI). Par exemple : "effacer le tableau". Alors que la
définition exacte voudrait apparemment qu'on écrive "effacer
*ce qu'il y a sur* le tableau". Je remarque que ce racourci
n'apparait même pas la définition. Soit.

Cependant, l'abus reste valable, et au cas où tu n'aurais pas
compris, c'est sur celui-ci que je me base.

Je n'avais pas compris, parce que cette signification-là ne
s'applique sûrement pas. On n'efface pas la liste -- la fonction
qui efface la liste s'appelle « clear ». (À vrai dire, je
m'attendrais aussi à un peu plus d'une fonction qui s'appelle
clear. Mais dans ce cas-ci, je me démande si ce n'est pas à
cause de ma formation initiale en électronique, et son
utilisation en électronique.)

Quote:

Tu as d'ailleurs fait mention d'un "erase the blackboard" dans
un post précédent, si je ne m'abuse. Tu conviendra sans doute
qu'il n'a pas le même sens qu'un "remove the blackboard",
qu'il faudrait transformer en "remove *all that is on* the
blackboard".

L'abus est classique. Par exemple, sur le lien

http://www.sgi.com/tech/stl/List.html

au niveau de list<>::erase avec comme argument deux
itérateurs, on lit bien "Erases the range [first, last)", et
non "Erases the elements in the range [first, last)".

Je ne crois pas que c'est un abus. C'est une utilisation tout à
fait courante et correcte. Mais c'est une utilisation qui ne
s'applique pas ici -- on n'efface pas la liste entière ; on en
enlève des éléments.

En ce qui concerne la doc STL : tu rétombes sur une
argumentation circulaire. La STL utilise les mots dans le sens
que les utililse la STL. Ce qui ne prouve rien ; ces
distinctions ne sont pas supportées par des dictionnaires
anglophones (ni, en supposant la traduction « erase » ->
« effacer » et « remove » -> « enlever », par les dictionnaires
français).

Pour cité Lewis Carroll : « When I use a word, it means exactly
what I want it to mean. » On peut utiliser les mots comme on
veut ; il n'y a rien qui ne l'interdit. Mais l'utilisation avec
une signification arbitraire, qui ne correspond pas à
l'utilisation habituelle par l'ensemble de parleurs de la
langue, n'améliore pas la communication. Ici, je veux bien qu'il
y a eu des contraintes techniques qui l'ont amener à forcer les
significations un peu, et à créer des distinctions
artificielles, mais ça ne change rien au fait que c'est un
compromis, et que le choix des mots n'est pas idéal.

Quote:

une des définitions de « enlever », c'est « Déplacer un
objet en le sortant de l'endroit qu'il occupe [...] en
l'effaçant, en le supprimant ». Dans le contexte ici, je
crois qu'on peut dire qu'« enlever » a la signification
donnée en paragraphe II.C du TLFI. Où le premier exemple est
« enlever un nom d'une liste [...] ». Ce qui est exactement
ce que fait list<>::erase()

Non. Si le nom apparait plusieurs fois, un appel à cette
fonction ne marchera pas. Il faudrait plusieurs appels, ce qui
n'a plus de sens.

(et list<>::remove(), évidemment, vue que les deux font la
même chose).

Ca n'engage que toi.

Et le « American Heritage Dictionary », pour l'anglais, et le
TLFI pour le français.

Je me sens en bonne companie.

Quote:

Dans le cas d'« effacer », on n'est amené à considérer que
les significations du paragraphe I.A. (§II couvre les
emplois pronominaux, et §I.B les significations « Empêcher
de paraître@», qui ne me semble pas convenir non plus.) Or,
parmi les utilisations dans §I.A, la seule qui semblerait
permise ici est §I.A.1.b : « Éliminer, faire disparaître
(quelque chose) ». Et là non plus, pas le moindre soupçon
que les critères de choix de ce qu'on élimine entre en ligne
de compte.

Moi, je choisirais la première (I.A.1.a) : "faire disparaitre
totalement (ce qui est tracé ou marqué sur une surface)".

Ce qui pourrait, à la rigueur, correspondre à la fonction
« clear », mais pas du tout à « erase ».

En passant, c'est intérssant à remarque la différence de nuance
entre « effacer » et « erase ». Dans le dictionnaire anglais, on
choisit d'insister sur l'idée de gratter ou d'essuyer : la façon
qu'on ôte l'écriture. Tandis que dans le français, la
distinction importante semble être l'idée qu'on efface une
surface (c-à-d que ce n'est pas « effacer » quand on enlève
quelque chose de l'intérieur).

Ici, évidemment, on n'a ni l'idée d'une surface (les éléments
qu'on enlève se trouve bien DANS la liste), ni l'idée de gratter
ou d'essuyer.

Quote:

Parce que la partie entre parenthèses fait apparaitre cette
dualité entre ensemble (la surface) et les éléments (les
marques). C'est celle qui permet l'abus "effacer une feuille",
"effacer un mur"...

Laissons tomber l'« abus ». Ce n'est pas un abus. C'est
simplement une signification qui ne peut pas s'appliquer ici.

Quote:

En somme, ta distinction d'« orientation » ne trouve pas de
justification dans la langue telle qu'elle s'emploie
généralement.

Si. Pas dans sa définition exacte, mais dans des abus
courants. N'emploie-t-on pas généralement l'expression
"effacer le tableau" ?

Oui. Avec la signification qui se rapproche à ce que fait la
fonction clear(). Se rapprocher seulement, parce que dans ce
signification, on n'efface qu'une surface, et pas quelque chose
qui se trouve dedans. (Et en anglais, on « erase » en grattant
ou en essuyant, toujours des actions superficielles.)

Quote:

L'action d'effacer quelque chose se base sur ce quelque
chose et s'applique au contenu de ce quelque chose, alors
que l'action d'enlever quelque chose se base sur ce
quelque chose et s'applique à ce quelque chose lui-même.

Ce qui donne :

list<>::erase se base sur une partie de la liste et
s'applique à son contenu (ses éléments, qu'il ôte), alors
que list<>::remove se base sur des éléments déterminés
(par moi) de la liste, et s'applique sur ces éléments
eux-mêmes (il les ôte).

C'est moi qui détermine les éléments à enlever. Dans les deux
cas.

Pas d'accord.

Alors, c'est qui qui les détermine ? Ou est-ce qu'on les choisit
au hazard, sans determination ?

Soyons raisonables, quand même.

Quote:

[...]

Je trouve que ça justifie leur différence terminologique.
C'est tout ce que je voulais dire.

Mais pour ça, il faut que tu donnes aux mots une
signification qu'ils n'ont pas.

...dans le dictionnaire. Bien que je serais étonné qu'aucun
dictionnaire n'en fasse mention.

Alors, trouves-en un. Une dictionnaire qui donne ou à « remove »
ou à « erase » une sémantique qui se base sur les critères de
sélection. D'après mon sens de la langue en anglais, ça
m'étonnera -- et le seul dictionnaire que je connais en ligne
semble en être d'accord. Mais c'est sûr que la langue est une
chose complexe et variable, et que c'est possible que d'autres
gens le voit différemment. (Mon anglais, par exemple, est
pûrement américain, et c'est le cas aussi du dictionnaire que je
cite -- comme son nom indique. Peut-être les anglais ont une
utilisation légèrement différente. Je ne me rappelle pas de
l'avoir rencontré dans mes lectures, mais c'est possible. Que
dit le dictionnaire d'Oxford ?)

Quote:

[...]

Déterminés par qui ?

Par l'utilisateur. Dans tous les cas. Une fonction où c'est
la liste même qui détermine ce qu'elle veut enlever ne
serait pas particulièrement intéressante.

Pas besoin de déterminer un élément pour l'enlever.

On en choisit un au hazard ?

Avec std::list<>::clear(), on enlève tous les éléments, dans
distinction. Avec remove, remove_if ou erase, c'est moi,
l'utilisateur, qui définit quels éléments sont à enlever.

Remarque que dans d'autres bibliothèques, où pour une raison ou
une autre on n'a pas les mêmes contraintes techniques, on
utilise le même mot. En Java, par exemple, on a
Collection.remove(), avec la signification de list<>::remove(),
et Iterator.remove(), avec la signification de list<>::erase()
-- du fait qu'on peut ôter à partir de l'itérateur élimine le
contrainte technique d'utiliser un mot différent. (Il a d'autres
désavantages, évidemment, et ce n'est pas une solution parfaite
non plus.)

Quote:

Dans list<>::erase, je ne détermine pas les éléments à
ôter.

Bien sûr que si. C'est bien toi qui fournis l'itérateur ou
les itérateurs.

Et les itérateurs correspondent à une position. Ce que je
determine, c'est la position, pas ce qui se trouve à cette
position, que je le sache ou non.

C'est une autre manière à préciser l'élément, oui. On peut
le préciser par sa position dans la liste, par sa valeur, ou par
un prédicat quelconque.

Et alors ? Quel rapport avec la signification de « erase » ou de
« remove ».

Quote:

[...]

Si les actions se résument pour toi à *ôter* et
*déplacer*, non.

Quelles sont les autres actions en question ?

Je ne dis pas qu'il y a d'autres actions, je dis que les
actions ne se résument pas *forcément* à "ôter" et "déplacer".

Ton "ôter" pourrait devenir "ôter les éléments qui
correspondent à une certaine valeur", et ton "déplacer"
pourrait devenir "remplacer les éléments de telle sorte que la
liste tronquée à un intervalle commençant par begin()
corresponde à celle qu'on aurait construit en ôtant les
éléments qui correspondent à une certaine valeur. Conserver la
valeur des éléments qui sont en dehors de l'intervalle" (j'ai
pas trouvé mieux, désolé).

Du coup, ça devient comparable.

Au fait, je ne comprend pas ton emploi du terme "déplacer"
pour std::remove.

Au fait, j'ai du mal à trouver un bon mot pour ce que fait
std::remove. Il copie les éléments qui ne correspondent pas à la
critère donné vers l'avant de la suite. Dans le sens qu'un
élément de valeur x se trouve à un autre endroit dans la suite
qu'avant, on peut dire qu'elle l'a déplacé. Mais c'est vrai que
la fonction ne déplace pas d'élément, elle utilise l'affectation
pour changer la valeur des éléments.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ
Guest

Posted: Mon Feb 06, 2006 1:02 pm Post subject: Re: Sens de const

On Fri, 3 Feb 2006 11:48:37 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

Quote:

Si, au contraire : on dit à peu de choses près "vire-moi le septième
élément".
Par contre, quand on dit "vire-moi les éléments dont la valeur est 42"
ou "éjecte les éléments pour lesquels f(x) est vrai", c'est le moteur
de std::list<> qui doit déterminer les éléments en question, d'après
les critères fournis.

Yoxoman
Guest

Posted: Mon Feb 06, 2006 9:02 pm Post subject: Re: Sens de const

Fabien LE LEZ <gramster (AT) gramster (DOT) com> a écrit :

Quote:

On Fri, 3 Feb 2006 11:48:37 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

Je ne suis pas d'accord. On peut chipoter sur le sens du verbe
"déterminer", mais je pense qu'en appliquant list<>::erase sur une
partie d'une centaine de termes, on ne determine pas les éléments en
question.

Si, au contraire : on dit à peu de choses près "vire-moi le septième
élément".
Par contre, quand on dit "vire-moi les éléments dont la valeur est 42"
ou "éjecte les éléments pour lesquels f(x) est vrai", c'est le moteur
de std::list<> qui doit déterminer les éléments en question, d'après
les critères fournis.

La question est : comment determine-t-on un élément ? Par sa position ?
Par sa valeur ?

Je ne sais pas.

--
"Yo!"
Martin Heidegger

Yoxoman
Guest

Posted: Mon Feb 06, 2006 9:02 pm Post subject: Re: Sens de const

kanze <kanze@gabi-soft.fr> a écrit : [plein de choses] Bon. Je pense que je vais arrêter là, cette discussion me prend beaucoup de temps, et elle grandit dangereusement trop. De plus, elle ne m'est pas particulièrement utile dans un contexte d'apprentissage du c++ (je suis débutant) que je recherche sur fclc++. Désolé de ne pas donner suite aux 545 lignes de ton post, mais, même si je ne suis franchement pas d'accord sur tout, je sens que cette discussion pourrait tourner en rond longtemps. -- "Yo!" Martin Heidegger

Gabriel Dos Reis
Guest

Posted: Mon Feb 06, 2006 10:02 pm Post subject: Re: Sens de const

Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz> writes: [...] \| Désolé de ne pas donner suite aux 545 lignes de ton post, ha ha ha, James t'a eu à la longueur :-) -- Gaby

Fabien LE LEZ
Guest

Posted: Tue Feb 07, 2006 8:03 am Post subject: Re: Sens de const

On Mon, 6 Feb 2006 21:59:53 +0100, Yoxoman <yhpnfyrqber (AT) tznvy (DOT) pbz>:

[Rappel : je parle ici de std::list, std::vector et std::deque]

Quote:

La question est : comment determine-t-on un élément ? Par sa position ?
Par sa valeur ?

Un élément est déterminé de façon non équivoque par sa position,
généralement donnée sous la forme d'un itérateur.

La valeur ne peut pas déterminer un élément, mais une classe
d'éléments : l'ensemble des éléments dont la valeur est égale à la
valeur de référence.

Si tu cherches 42 dans le tableau { 0, 42, 5, 5, 42, 6 }, la classe
des élements trouvés est { deuxième élément ; cinquième élément },
ou { begin()+1, begin()+4 }.

Note par ailleurs que la notion de "valeur" est ici trompeuse :
list::remove() n'effectue pas une recherche sur une valeur, mais sur
un prédicat "operator== (élément, référence)".

Un exemple pour bien montrer la différence :

struct C
{
int a;
int b;
bool operator== (C const& autre) const
{ return a == autre.a; }
};

std::list<C> ma_liste;

Si tu ajoutes un élément (avec ma_liste.push_back()), il y a une copie
des membres a et b.
Si tu cherches un élément (avec ma_liste.remove()), tu effectues une
comparaison sur le membre a uniquement.

Bien évidemment, pour std::set et std::map, il en va tout autrement.

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT Goto page Previous 1, 2, 3, 4, 5 ... 48, 49, 50 Next
Page 4 of 50