OVH Cloud OVH Cloud

recherche d'un element suivant la valeur d'un des champs

184 réponses
Avatar
Alain Cabiran
Bonjour,

j'ai cherché, testé, retesté, essayé, réessayé et n'ai pas trouvé
de solution à ce problème

assume using namespace std :-)

imaginons avoir :

class objet
{
public:
objet(int valeur) : monchamps(valeur) { } ;
int getChamps() const { return monchamp; } ;
private:
int monchamps();
};

un conteneur : list<objet> liste;
son iterateur : list<objet>::iterator it;

une valeur prédéfinie : int valeur = 5;

est-ce qu'il est possible, en utilisant les adaptateurs stl,
d'avoir l'équivalent de :

cherche dans liste le premier élément avec la condition
it->monchamp == valeur ?

j'ai commencé par :

it = find_if(liste.begin(), liste.end(), TOTO);

ensuite j'ai cherché TOTO : bind2nd(equal_to<int>(), valeur)

et là ... je sais pas, j'ai essayé de placer :

mem_fun_ref(&objet::getChamps) mais je n'ai pas trouvé où le mettre
et même si je peux seulement l'y mettre.

quelqu'un a une idée ?

Alain Cabiran

ps: il manque évidemment le constructeur de copie, les operateurs de
comparaisons, ... dans la classe, c'est juste pour faire plus court.

10 réponses

Avatar
Michel Michaud
Dans le message 4163b2ce$0$22588$,
Par ailleurs, tu dis que la norme impose de pouvoir écrire du code
avec les caractères que l'on veut. Je n'ai pas trouvé où elle
spécifiait ça. C'est où ?


Pas tout à fait « que l'on veut ». C'est l'annexe E et 2.10 qu'il
faut regarder. Le principe est que les u représente les caractères
sous une forme portable, mais qu'ils représentent aussi des symboles
pouvant être affichés directement par les outils.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
Arnaud Meurgues
Michel Michaud wrote:

Actuellement, en France, il est de plus en plus fréquent d'avoir des
équipes internationales à cause de l'ouverture européenne du marché
de l'emploi et de l'européannisation de l'industrie.
Le Québec n'a pas ce soucis là et a au contraire le soucis de
protéger sa culture (en particulier sa langue) de la pression
anglo-saxonne.
Je ne crois vraiment pas que mon argumentation avait un quelconque

rapport avec la politique et la protection de la langue :-)


Moi, je crois que si, d'une certaine manière.
Mais c'est loin d'être le seul argument que je donne. Le plus important
étant qu'en France, aujourd'hui, un nombre très important de projets
informatiques ont une chance non négligeable (>50%) d'être approchés par
des non francophones.

Par exemple, dernièrement, je suis intervenu sur un projet géré par
Alcatel Maroc. Ils sont francophone et moi aussi. Ouf. Mais le projet
avait été développé par Alcatel Portugal et c'est Alcatel Maroc qui en
assurait la maintenance.
Hé bien, heureusement que les développeurs n'avaient pas estimé qu'il
était mieux de donner des noms portugais aux identificateurs !

S'il faut être international, je ne prétends pas qu'il faut
utiliser le français...


Bien. Maintenant, imagine qu'en Europe, actuellement, l'ouverture du
marché du travail fait que sur une très importante partie des projets,
il faut être international.
Ce n'est vraisemblablement pas le cas du Québec qui a une situation
politique (oui, ça compte) très différente de celle de la France.

--
Arnaud
(Supprimez les geneurs pour me répondre)


Avatar
Arnaud Meurgues
Michel Michaud wrote:

En fait, je crois que permettre le jeu de caractères naturel de
la machine est un minimum.


C'est quoi, le jeu de caractères naturel d'une machine ?
Sur la mienne, je peux changer quand je veux son "jeu de caractères
naturel".

--
Arnaud
(Supprimez les geneurs pour me répondre)

Avatar
kanze
"Michel Michaud" wrote in message
news:<rjZ8d.15516$...
Dans le message ,
Il y a une différence entre la difficulté conceptuelle, et la
difficulté pratique de l'implémentation. Faire reconnaître des
caractères de plus par le lexeur, c'est un jeu d'enfant. Mais il ne
faut pas oublir que par la suite, ces caractères vont se rétrouver
dans le tableau de symboles. Un composant qui sert à peu près
partout dans le compilateur. Et qu'ils vont apparaître dans les
messages d'erreur -- du coup, il faut se poser la question comment
les afficher.

Dans le cas de g++, il ne faut pas oublier non plus qu'il se base la
plupart du temps sur des outils (assembleur, éditeur de liens) du
système hôte. Alors, comment veux-tu que g++ supporte des accents
dans les noms si l'éditeur de liens ne les supporte pas.


Je comprends bien qu'il y a des difficultés. Curieusement peut-être
elles me semblent tout de même peu complexes par rapport à tout le
reste...


Il y a differents types de complexité. Je suis sûr que Gaby saurait
implémenter le support du universal-character-names, sans trop y
reflechir, or que export démandera certainement plus de reflexion. En
revanche, il aurait beaucoup de mal, de l'intérieur du groupe g++, à
faire en sort que l'éditeur de liens Sun les comprenent. J'imagine aussi
qu'il aurait beaucoup de mal du point de vue politique à faire accepter
des modifications qui imposent des modifications sur Solaris que Sun
n'est pas près à faire. Sans parler du fait que parce que le changement
a un impacte partout, il faut le synchroniser avec toutes les équipes ;
il impose un changement dans le langage intermédiaire, ce qui impose à
son tour des changements dans tous les back-ends... et tous les
front-ends, y compris ceux pour des langages qui ne supporte pas les
nouveaux caractères.

Et pour gagner quoi ? La possibilité d'écrire des programmes dont même
les sources ne peuvent être lues que sur la machine où elles ont été
écrites ?

Évidemment, s'il ne s'agit que de permettre les caractères
alphabétiques de ISO 8859-1... La norme en exige beaucoup plus.


En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.


Tu vis trop dans le monde fermé de Windows. J'ai actuellement des
fenêtres ouvertes sur quatre machines différentes, qui tournent sous
trois OS différentes, sur deux architectures différentes. Une utilise
UTF-16, une autre UTF-8 et deux ISO 8859-1. Et évidemment, les fichiers
que j'édite ne se trouvent sur aucun de ces machines, mais sur encore
une autre machine.

Dans ce contexte, quel est le jeu de caractères naturel ?

Mais ISO-8859-1 (ou -15) serait quand même un bon point de départ pour
bien du monde


Il ne suffit même pas pour l'Europe:-).

Mais je crois que la question se présente autrement. La norme a établi
certaines exigences. Je doute que l'équipe de g++ ait envie de faire un
travail pour faire que leur compilateur accepte ISO-8859-1 dans les
symboles (parce qu'il l'accepte déjà tout dans les commentaires et dans
les chaînes de caractères et des constantes de caractères) simplement
pour le réfaire le jour où ils implémentent la norme.

--
James Kanze GABI Software http://www.gabi-soft.fr
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


Avatar
kanze
"Alain Naigeon" wrote in message
news:<41647d13$1$12227$...
"Fabien LE LEZ" a écrit dans le message news:

Je vois les choses d'un autre point de vue : un programme écrit en
ASCII est compilable partout ; un programme écrit en ISO-Latin-1
n'est compilable que sur certaines machines. Dans le premier cas
(ASCII), il n'y a pas de discrimination (toutes les machines sont
acceptées) ; dans le deuxième cas il y en a une.


Comment on dit "nivellement par le bas", en Anglais ?


Portability.

--
James Kanze GABI Software http://www.gabi-soft.fr
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


Avatar
Arnaud Meurgues
Michel Michaud wrote:

Bon, juste une question. Le compilateur reçoit un fichier source.
Comment sait-il dans quel jeu de caractères il est été écrit ? Et
l'encoding ?
Je crois que le raisonnement est à l'envers. Si je veux compiler

un code avec un certain compilateur, je lui donne le code dans le
jeu de caractères qu'il connaît. Il faut convertir dans ce jeu
au besoin, avant de donner le code au compilateur.


Ok. Alors ça doit marcher depuis un petit moment, déjà. Tu convertis ton
code en unicode (uxxxxxxxx) et tu le passes dans le compilateur. Hop.
Mais dans ce cas là, tu ajoutes une étape entre l'édition et la compilation.

Par ailleurs, si tu veux qu'un compilateur marche pour un jeu de
caractères donné, alors il y aura plein de gens qui ne pourront pas
utiliser leur propre jeu de caractères (chinois, japonais,...) parce
qu'il n'y a pas de conversion possible vers le jeu de caractères compris
par le compilateur (s'il s'agit, par exemple, d'ISO-8859-1).

--
Arnaud
(Supprimez les geneurs pour me répondre)


Avatar
kanze
"Michel Michaud" wrote in message
news:<XCZ8d.15530$...
Dans le message ,
"Michel Michaud" wrote in message
news:<hsI8d.11156$...
Dans le message 4162572b$0$8210$,
Il n'est pas nécessaire non plus de s'exprimer aussi bien en
anglais qu'en français pour donner des noms anglais à ses
identificateurs (et heureusement).


Dans ce cas, tu risques d'avoir des noms moins bien choisis. Je ne
sais pas si le coût est justifiable... Un anglophone qui lira tes
noms ne pourra pas deviner ce que tu aurais dû écrire. Si tu écris
en français, il pourra au moins consulter un dictionnaire ou
consulter un francophone pour essayer de comprendre ce que tu
voulais dire.


Le problème n'est pas quand il ne comprend pas. Le problème, c'est
quand il croit comprendre, mais ce n'est pas ce qu'on voulait dire.


Exactement. Il faut toujours être le plus limpide possible et ce
n'est pas si facile dans une langue qui n'est pas parfaitement
maîtrisée.

Ceci dit même des francophones n'y arrivent pas toujours surtout
lorsqu'ils travaillent seuls et n'en voient pas la nécessité...


Et je crois que c'est là la clé. D'abord, il ne s'agit pas d'une
dialectique, qu'on maîtrise une langue ou non, mais d'un continuum,
qu'on maîtrise une langue plus ou moins bien. J'ai bien travaillé avec
des français qui avaient du mal à s'exprimer en écrit en français,
beaucoup plus mal que moi, en tout cas. En quelle langue est-ce qu'ils
doivent écrire leur commentaires.

Ce que je constate (mais Gaby te dirait, sur la base d'un échantionnage
assez faible), c'est que les gens qui savent s'exprimer bien dans leur
propre langue n'ont en général pas trop de problèmes à apprendre à
s'exprimer bien dans d'autres langues, à condition de s'y mettre et d'y
être motivé. Je constate aussi en général que ceux qui ne savent pas
trop bien s'exprimer ne sont pas des meilleurs programmeurs non plus ;
pouvoir bien s'exprimer, c'est une qualité nécessaire (mais pas
forcement suffisante) pour être bon programmeur.

Mais là aussi, il s'agit d'un continuum, et il y a des personnes qui
savent programmer d'une façon adéquate pour le travail à faire, et dont
l'expression orale et écrite dans leur langue native est suffisante pour
ce qu'elles ont à faire, mais qui ont des problèmes de maîtrise dans
d'autres langues. Il y a aussi une question de temps : actuellement,
j'écris en anglais ou en français à à peu près la même vitesse, mais
quand je m'exprime en allemand, il me faut 50% plus de temps (ou je
m'exprime moins bien). Or, je pourrais sans doute m'entrainer à
l'allemand, pour y arriver au niveau qu'en anglais ou en français, mais
le temps qu'il me faudra pour le faire, c'est du temps que je ne passe
pas à apprendre les subtilités des templates, ou des règles de jeu dans
le domaine de l'application.

Tout ça pour dire simplement que dire qu'il faut toujours écrire les
commentaires dans sa langue native, c'est faux, de même que dire qu'il
faut toujours les écrire en anglais. Chaque situation est unique, et la
solution idéale dépend de pas mal de facteurs particuliers à la
situation.

Et que les gens qui font les règles ne se rendent pas toujours compte de
toutes ces subtilités, et que donc il arrive couramment qu'on impose
l'anglais, quand c'est la langue locale qui aurait convenu plus, et vice
versa.

À la fin de leur formation en informatique, je dirais qu'il n'y a pas
plus du tiers de mes élèves qui maîtrisent (mais vraiment) l'art des
commentaires et des identificateurs. Mais ce n'est pas un réel
problème, car en entreprise, la proportion semble encore plus faible
et même les moins bons font normalement très bonne figure :-(


D'après tes postings dans la passée, je crois que le niveau de tes
élèves correspond un peu au BTS ici. Alors, j'avoue que j'ai du mal à
dire ce qu'on devait pouvoir attendre d'eux. Dans le type de projets sur
lesquels je travaille, on ne voit quasiment que les ingenieurs (BAC+5 en
France, Dipl-Ing(TU) en Allemagne, MS, je crois, en Amérique du nord).
Et à ce niveau, on s'attend une certaine compétence linguistique, aussi
bien dans sa propre langue que dans l'anglais. (On s'attend... Parce
qu'au moins en France, on arrête l'étude du français après le premier,
avant le bac. Et que j'ai bien rencontré des « ingenieurs » en France
qui savait à peine écrire. Mais ils n'étaient pas ce que j'aurais appelé
compétents en informatique non plus.)

mais curieusement, j'ai remarqué que souvent, les gens incapable de
bien apprendre une langue étrangère n'étaient souvent pas très
compétent en informatique non plus. Il y a des exceptions, mais
d'après mon expérience, elles sont plutôt rares.


Oui, je suis un peu d'accord, mais deux remarques :

- tu as écrit « bien apprendre un langue étrangère ». Ce n'est pas
comme parler de la maîtrise de cette langue... Je crois qu'il faut
un certaine maîtrise du français pour écrire de bons commentaires
(ou identificateurs) en français. C'est pareil pour les autres
langues, sauf que ça parait moins si la seule personne qui lit le
code est celle qui l'a écrit !


Comme j'ai dit ci-dessus, c'est un continuum. La maîtrise d'une langue,
ce n'est pas quelque chose qu'on a ou qu'on n'a pas. On l'a tous (au
moins dans une langue), mais à différents niveaux.

La maîtrise qu'il faut n'est pas toujours non plus la maîtrise qui est
testée dans les cours de langues. Mon allemand écrit est lamentable.
Mais j'estîme que les commentaires que j'écrive en allemand sont souvent
superieur à ceux qu'écrivent certains allemands. On n'a pas besoin d'une
compétence linguistique énorme pour écrire quelque chose comme :

pre
i >= 0 && isValid()

post
value() == old.value() + i

Évidemment, il faut bien plus que ça pour avoir des commentaires
suffisants, mais j'ai déjà vu pas mal du code qui n'avait même pas ça.

Avant la maîtrise d'une langue, je mettrais la volenté de communiquer.
Chose qui, historiquement au moins, a manqué à beaucoup
d'informaticiens.

- je crois qu'il y a vraiment beaucoup de personnes qui ne parlent
que l'anglais et qui sont quand même très compétents, non ? C'est
peut-être qu'ils seraient capable d'apprendre une autre langue,
mais ne l'ont pas encore faits ? Alors la connaissance de l'anglais
d'un programmeur ne serait pas vraiment significative, seulement sa
capacité à l'apprendre !

Pour faire un lien avec C++ : K&R, Lippman, Meyers, Austern et Koenig
parlent-ils une autre langue ? (je sais que c'est le cas des
Stroustrup, Sutter, Alexandrescu, Josuttis, Lajoie, Dos Reis, Kanze,
etc. :-)


J'en sais rien. Mais je me sens assez sûr pour dire qu'ils l'auraient pû
en acquérir une véritable maîtrise s'ils en avaient eu besoin. (En ce
qui me concerne, je sais que je ne suis absolument pas doué en langues,
dans le sens classique. Mais j'en ai eu besoin. Je les ai donc
apprises. Pas parfaitement, mais assez pour faire ce que j'avais à
faire.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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




Avatar
kanze
Arnaud Meurgues wrote in message
news:<4163ad90$0$22592$...
Michel Michaud wrote:

Il n'est pas nécessaire non plus de s'exprimer aussi bien en
anglais qu'en français pour donner des noms anglais à ses
identificateurs (et heureusement).


Dans ce cas, tu risques d'avoir des noms moins bien choisis. Je


Peut-être. Mais pour un non francophone, il vaut mieux un nom pas très
bien choisi qu'un nom incompréhensible, parce que dans une langue
qu'il ne connaît pas.


Un nom mal choisi risque d'être aussi incompréhensible qu'un nom dans
une langue qu'on ne connaît pas. Avec la différence qu'on peut avoir
l'impression d'avoir compris dans le premier cas, même si ce n'est pas
vrai.

ne sais pas si le coût est justifiable... Un anglophone qui lira tes
noms ne pourra pas deviner ce que tu aurais dû écrire. Si tu


Faut pas pousser non plus. Le niveau d'anglais nécessaire pour choisir
des noms explicites n'est tout de même pas celui d'une langue
maternelle. La plupart du temps, on reste cantonné à un vocabulaire
technique qui ne nécessite pas de savoir lire Shakespeare dans le
texte ("oldValue", "finalResult", "DiplayVisitor", etc.).


Beaucoup dépend du domaine. En ce qui concerne le langage technique, ça
m'étonnerait que quelqu'un puisse être compétent en C++ et ne pas
maîtriser assez d'anglais pour bien choisir les noms. En ce qui concerne
les termes de metier, en revanche, ça me semble beaucoup moins certain.
Si je régarde autour de moi ici, personne ne se sent obligé à lire
l'anglais pour rester à jour dans le domaine bancaire. Et si personne
n'aurait de problème pour trouver des symboles comme oldState ou
loopCount, même moi, j'aurais du mal à trouver de l'anglais qui
conviendrait à « affectation », « titre » ou « obligation » (dans leurs
signification boursière). Et c'est justement sur ces termes qu'un à peu
près peut préter à la plus de confusion.

--
James Kanze GABI Software http://www.gabi-soft.fr
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



Avatar
kanze
Arnaud Meurgues wrote in message
news:<4163af84$0$22603$...
Fabien LE LEZ wrote:

[*] Je précise que je préfère les 52 caractères de l'alphabet
utilisé en anglais, aux milliers de kanjis du chinois. Ben oui, si
on laisse tomber l'anglais, la langue "forte" risque fort d'être le
chinois, vu la population chinoise...


Rassures-toi, l'indi est une langue alphabétique, et non
idéogramatique. ;-)


Mais il a parlé du chinois.

En ce concerne l'informatique, la langue usuelle en Inde est l'anglais,
non l'hindi. (Le centre principal de l'informatique en Inde est
Bangalore. Où on parle le Kannada, et non l'Hindi.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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


Avatar
kanze
Arnaud Meurgues wrote in message
news:<4163b2ce$0$22588$...
Michel Michaud wrote:
etc. De même qu'un code C++ écrit sous Windows doit être lisible
sous Linux (sinon, autant programmer en VB).


Ça semble facile et maîtrisé par les outils actuels. Ce n'est pas là
qu'il y a complexité...


Ben si. Actuellement, à ce que je sache, la norme C++ ne fournit aucun
moyen de connaître le jeu de caractères utilisé par un fichier.


Et pour cause. La plupart des systèmes ne fournit aucun moyen de le
connaître. Alors, si le C++ l'imposait, comment est-ce que tu ferais
pour l'implémenter.

Le seul moyen serait alors de passer en argument au compilateur le jeu
de caractères à pendre en compte. Mais cela signifie que tous les
fichiers doivent utiliser le même jeu de caractère. Que fera le
compilateur si un fichier include utiliser un autre jeu de caractère ?


Ce que l'implémentation accepte en entrée est défini par
l'implémentation. J'imagine que chez Microsoft, ils acceptent du UTF-16,
étant donné que c'est l'encodage natif du système. Sur des systèmes plus
polyvalents, en revanche, où il n'y a pas vraiment un encodage natif, le
problème est plus complexe.

Par ailleurs, tu dis que la norme impose de pouvoir écrire du code
avec les caractères que l'on veut. Je n'ai pas trouvé où elle
spécifiait ça. C'est où ?


La norme impose qu'une implémentation comprenne tous les caractères de
base. Elle impose aussi qu'elle comprenne des « universal character
names ». Elle laisse l'implémentation libre de traduire les fichiers en
entrée comme elle veut.

--
James Kanze GABI Software http://www.gabi-soft.fr
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