Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ recherche d'un element suivant la valeur d'un des champs

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.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
15 16 17 18 19
Avatar
drkm
Gabriel Dos Reis writes:

Je suis contre tout ce qui commence avec #pragma ou variantes.


C'est une idée que je pense avoir rencontrée plusieur fois, sans
jamais en avoir vu les raisons exactes. Quelles sont les tiennes ?

--drkm

Avatar
James Kanze
Arnaud Meurgues writes:

|> wrote:

|> > Applicable, mais non appliqué. Je verrais bien un espèce de
|> > #pragma codeset iso_8859_1
|> > par exemple.

|> Je suis pour.

|> > Une autre possibilité que j'ai considéré, c'est un fichier de
|> > configuration dans le répertoire, du genre .codeset. Si ce fichier
|> > est présent, le compilateur lirait tous les fichiers du répertoire
|> > avec cet encodage.

|> Là, je suis contre car cette solution ne permet pas, telle que tu
|> l'énonces, d'avoir plusieurs encodages dans le même répertoire.
|> Si on affine en permettant que le fichier .codeset puisse:
|> - spécifier un codeset par défaut pour tous les fichiers
|> - spécifier un codeset par fichier remplaçant le défaut
|> alors ça devient une solution que je trouve acceptable.

L'idée, c'est que je livre les en-têtes de ma bibliothèque, écrit en ISO
8859-1, dans un répertoire, et dans ce répertoire, je mets aussi un
fichier .codeset avec ISO 8859-1 écrit dedans. Toi, tu dévelopes en
UTF-8, et tu as un .codeset avec UTF-8 chez toi. Les fichiers que le
compilateur trouve chez toi, il les lit en UTF-8. Ceux qu'il trouve chez
moi, en ISO 8859-1.

C'est loins d'être parfait, mais je le crois plus facilement maintenable
que d'avoir à spécifier le codeset fichier par fichier (sauf si la
spécification est dans le fichier même).

Mais à y penser : je crois que ce qu'il nous faut, c'est simplement un
#codeset. Avec les règles que :

- dans l'absense de ce directif dans un fichier, le fichier serait lu
dans le codeset natif le plus primitif du processeur, c-à-d en
général ASCII 7 bits,

- si le compilateur ne comprend pas le codeset, c'est une erreur, et

- les noms des codesets courant (ASCII, EBCDIC, les UTF et les ISO
8859, au moins) soient normalisés (sans qu'on exige que tout
compilateur les supporte tous).

En ce qui concerne le deuxième point : je crois que c'est mieux d'avoir
une erreur que de courir la risque que le code soit mal compris par le
compilateur. En cas d'erreur, c'est à l'utilisateur éventuellement à
trouver un outil qui convertira le fichier en quelque chose de lisible.

Gaby : tu es plus près du comité que moi. Est-ce que tu penses qu'il
pourrait y avoir de l'intérêt pour ce genre de chose ?

|> > (L'avantage, c'est qu'on peut le faire après le coup, sans
|> > modifier les fichiers sources, et que les compilateurs qui ne
|> > connaissent pas l'astuce ne verrait rien.)

|> Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère
|> pas.

Ça embête en revanche les compilateurs qui l'ont choisi pour d'autres
choses, ou qui ont adopté une syntaxe différente pour la même chose.

On pourrait suivre le chemin d'autres langages, et « normaliser »
certains pragmas. Mais alors, est-ce qu'ils sont des pragmas. Quel est
l'avantage par rapport à un nouveau directif du préprocesseur ?

--
James Kanze
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
James Kanze
"Mickael Pointier" writes:

|> D'ailleur, à titre d'anecdote, il y à eu récement un problème avec
|> une des beta-versions de "whidbey" (le petit nom de Visual Studio
|> 2005), à propos de la gestion des locales dans le compilateur.

|> Un certain nombre de personnes se sont trouvés à ne plus pouvoir de
|> compiler les sources C++ contenant des valeurs littérales en virgule
|> flotante:

|> float pi=3.14159f;

|> Erreur :)

|> La raison est que le compilateur sur ces machines (françaises, et
|> allemandes en autre), se basait sur la locale qui était configurée
|> pour utiliser la virgule en temps que délimitateur décimal.

La norme est claire. Le caractère décimal dans des constantes flottanes,
c'est un '.'. Indépendamment du locale.

|> Super...

|> Donc obligé de changer la locale du système, parce que bien
|> évidement le compilateur n'acceptait pas non plus correctement que
|> l'on tappe "3,14159f" à la place :-)

Ça n'aurait pas été plus raisonable de corriger le compilateur pour
qu'il lise toujours en locale "C", quelque soit le locale du système ?

--
James Kanze
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
Gabriel Dos Reis
James Kanze writes:

[...]

| Mais à y penser : je crois que ce qu'il nous faut, c'est simplement un
| #codeset. Avec les règles que :
|
| - dans l'absense de ce directif dans un fichier, le fichier serait lu
| dans le codeset natif le plus primitif du processeur, c-à-d en
| général ASCII 7 bits,
|
| - si le compilateur ne comprend pas le codeset, c'est une erreur, et
|
| - les noms des codesets courant (ASCII, EBCDIC, les UTF et les ISO
| 8859, au moins) soient normalisés (sans qu'on exige que tout
| compilateur les supporte tous).
|
| En ce qui concerne le deuxième point : je crois que c'est mieux d'avoir
| une erreur que de courir la risque que le code soit mal compris par le
| compilateur. En cas d'erreur, c'est à l'utilisateur éventuellement à
| trouver un outil qui convertira le fichier en quelque chose de lisible.
|
| Gaby : tu es plus près du comité que moi. Est-ce que tu penses qu'il
| pourrait y avoir de l'intérêt pour ce genre de chose ?

Il est difficile pour moi de répondre à la place du comité. Si tu en
fais une proposition formelle, je crois que le groupe d'évolution le
discutera -- il est difficile d'allouer du temps pour des propositions
informelles.

À ce que je vois, « l'invention des UCNs » dans la norme de 1998 avait
quelques déficiences et pas beaucoup de monde s'est précipité dessus.

-- Gaby
Avatar
Gabriel Dos Reis
writes:

[...]

| des personnes qui y étaient à l'époque. (Si Gaby a envie de faire un peu
| de récherche, je serais intéressé à savoir quand les UCN ont apparu dans
| les drafts pour la première fois, et quand ils ont été proposés. J'ai
| l'impression qu'ils y étaient déjà dans le premier draft que j'ai lu,
| environ 1993, mais c'est une impression encore plus vague qu'un
| souvenir -- c-à-d qu'à vrai dire, je ne sais pas.)

Dès que j'ai un peu de temps pou fouiller les archives.
(De toute façon, il faut que je le fasse pour autre chose).

-- Gaby
Avatar
drkm
James Kanze writes:

Mais à y penser : je crois que ce qu'il nous faut, c'est simplement un
#codeset.


Dans le fichier lui-même ? On devrait donc en un sens, pour pouvoir
lire le fichier, en connaître déjà le contenu afin de savoir s'il s'y
trouve un "#codeset".

Je pense que ce problème a été résolu en XML en imposant que

<?xml version="1.0" encoding="ISO-8859-1"?>

se trouve exactement en première position dans le document. En
particulier, il ne peut y avoir de commentaire ou de caractère blanc
le précédant. Je pense que l'analyseur utilise alors "<?" pour
deviner comment lire la suite, en espérant arriver correctement à
"ISO-8859-1".

Je ne connais pas assez les tenants et aboutissants des problèmes
d'encodage. Mais je pressens qu'il y a là un problème, à mettre la
manière de lire un fichier dans le fichier lui-même.

--drkm

Avatar
Jean-Marc Bourguet
drkm writes:

Je pense que ce problème a été résolu en XML en imposant que

<?xml version="1.0" encoding="ISO-8859-1"?>

Je ne connais pas assez les tenants et aboutissants des
problèmes d'encodage. Mais je pressens qu'il y a là un
problème, à mettre la manière de lire un fichier dans le
fichier lui-même.


J'ai pas lu toute cette conversation. Mais la manière
d'interpréter un fichier -- l'encodage en fait partie -- est
nécessairement de l'information hors bande -- exactement
comme le protocole à utiliser pour communiquer est transmis
en dehors de celui-ci.

Ce qui est possible c'est
- d'avoir une confirmation que c'est apparemment bien le
bon format/bon protocole, avec une signature et des
sommes de contrôles par exemple on est assez
raisonnablement sûr;
- d'avoir un format/protocole qui prévoit de donner plus
d'info sur la manière d'interpréter.

Je ne connais pas assez bien XML, mais il m'a l'air d'être
dans ce cas; je vois au moins deux possibilités:
- il n'admet que des encodages qui sont des surensembles
de l'ascii (latin-1, UTF-8, JIS, ...) mais pas autre
chose (UTF-16, EBCDIC); on peut vraissemblablement
pousser un peu plus loin et vérifier qu'il y a moyen de
faire de l'auto-détection d'un certain nombre de ces
encodages pour autant que le fichier commence bien par
la bonne directive (par exemple UTF-16 c'est de l'ascii
avec des 0 intercallés -- et s'il y a un BOM c'est
encore plus facile -- la chaîne
<?xml version="1.0" encoding="
doit être une assez bonne signature de l'encodage, la
fin permettant de détecter les variantes et extension)
Pour voir à quel point c'est vrai, il faudrait un
connaisseur des encodages asiatiques.
- on transmet de l'ascii jusqu'à la fin de la directive
et après c'est ce qui était déterminé. Mais alors
l'édition du fichier avec un éditeur de texte UTF-16 ou
EBCDIC au mieux est étrange, au pire impossible (parce
que les combinaisons n'ont pas de sens)

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
James Kanze
Jean-Marc Bourguet writes:

|> drkm writes:

|> > Je pense que ce problème a été résolu en XML en imposant que

|> > <?xml version="1.0" encoding="ISO-8859-1"?>

|> > Je ne connais pas assez les tenants et aboutissants des
|> > problèmes d'encodage. Mais je pressens qu'il y a là un problème, à
|> > mettre la manière de lire un fichier dans le fichier lui-même.

|> J'ai pas lu toute cette conversation. Mais la manière d'interpréter
|> un fichier -- l'encodage en fait partie -- est nécessairement de
|> l'information hors bande -- exactement comme le protocole à utiliser
|> pour communiquer est transmis en dehors de celui-ci.

Pas toujours. Il faut une information hors bande pour commencer (mais ça
peut être une information constante -- on commence toujours en 7 bit
ASCII), mais il est même courant de permettre de changer en cours de
route, suite à des informations dans le protocol lui-même. (Pense aux
codes shift-in et shift-out, par exemple.)

Il y a des limites, évidemment. Ceci imposera, par exemple, que la
première ligne (ou toutes les lignes jusqu'à la ligne qui précise le
codeset) soit en ASCII. Même dans un environement normalement EBCDIC. Ou
non. Jusqu'à ce qu'on l'a vraiment défini, on peut pas trop savoir.

|> Ce qui est possible c'est
|> - d'avoir une confirmation que c'est apparemment bien le
|> bon format/bon protocole, avec une signature et des
|> sommes de contrôles par exemple on est assez
|> raisonnablement sûr;
|> - d'avoir un format/protocole qui prévoit de donner plus
|> d'info sur la manière d'interpréter.

|> Je ne connais pas assez bien XML, mais il m'a l'air d'être
|> dans ce cas; je vois au moins deux possibilités:
|> - il n'admet que des encodages qui sont des surensembles
|> de l'ascii (latin-1, UTF-8, JIS, ...) mais pas autre
|> chose (UTF-16, EBCDIC); on peut vraissemblablement
|> pousser un peu plus loin et vérifier qu'il y a moyen de
|> faire de l'auto-détection d'un certain nombre de ces
|> encodages pour autant que le fichier commence bien par
|> la bonne directive (par exemple UTF-16 c'est de l'ascii
|> avec des 0 intercallés -- et s'il y a un BOM c'est
|> encore plus facile -- la chaîne
|> <?xml version="1.0" encoding="
|> doit être une assez bonne signature de l'encodage, la
|> fin permettant de détecter les variantes et extension)
|> Pour voir à quel point c'est vrai, il faudrait un
|> connaisseur des encodages asiatiques.

|> - on transmet de l'ascii jusqu'à la fin de la directive
|> et après c'est ce qui était déterminé. Mais alors
|> l'édition du fichier avec un éditeur de texte UTF-16 ou
|> EBCDIC au mieux est étrange, au pire impossible (parce
|> que les combinaisons n'ont pas de sens)

Je crois que la seule véritable difficulté aujourd'hui, c'est l'EBCDIC.
Mais j'imagine qu'une implémentation EBCDIC ne va supporter que
l'EBCDIC, et aucun des autres encodages. À ce moment-là, dès qu'il
rencontrait un #codeset, il va s'arrêter.

Ce qui ne me plaît pas trop dans la chose, c'est que si je me retrouve
sur un système qui ne supporte pas le codeset, et que je trancode le
fichier par un programme externe, il va falloir que ce programme traite
la ligne #codeset d'une façon spéciale. Je ne pourrais pas, par exemple,
simplement passer un fichier ISO 8859-1 par un programme qui convertit
tous les caractères non ASCII en UCN, parce que le compilateur va quand
même s'arrêter sur la ligne #codeset si on ne l'enlève pas.

--
James Kanze
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
drkm
Jean-Marc Bourguet writes:

J'ai pas lu toute cette conversation. Mais la manière
d'interpréter un fichier -- l'encodage en fait partie -- est
nécessairement de l'information hors bande -- exactement
comme le protocole à utiliser pour communiquer est transmis
en dehors de celui-ci.

Ce qui est possible c'est
- d'avoir une confirmation que c'est apparemment bien le
bon format/bon protocole, avec une signature et des
sommes de contrôles par exemple on est assez
raisonnablement sûr;
- d'avoir un format/protocole qui prévoit de donner plus
d'info sur la manière d'interpréter.

Je ne connais pas assez bien XML, mais il m'a l'air d'être
dans ce cas; je vois au moins deux possibilités:


Je viens de survoler la norme XML (3ème révision). D'après ce que
j'ai compris, le processeur XML est sensé se servir d'infos hors
bande. Dans le cas où elles ne sont pas disponibles, il essaie de
lire les cinq premiers caractères, "<?xml", et d'en déduire un
encodage.

Comme la déclaration XML ne contient que des caractères du
répertoire ASCII, cela permet dans beaucoup de cas d'arriver à la
déclaration du jeu employé (qui fait partie de la déclaration XML).

Il semble donc bien que le principe soit de favoriser l'info hors
bande, mais de se servir d'infos dans le fichier lui-même si ce n'est
pas possible. Sans avoir la certitude dans ce cas de ne pas se
tromper. On utilise alors une info hors bande, comme l'a fait
remarqué James : « le document devrait commencer par "<?xml", ... ».

La section intéressante est « F.1 Detection Without External
Encoding Information ».

--drkm

Avatar
Michel Michaud
Dans le message ,
"Michel Michaud" wrote in message
news:<NLb9d.31747$...
Je ne suis pas certain qu'on se comprend bien. Mon impression est
que les u ont été inventés pour ça : si tu utilises des
caractères qui sont acceptables (codes u acceptés selon l'annexe
de la norme), tu devrais pouvoir les coder en u et les utiliser
sur un autre compilateur.


Tout à fait. Mais je croyais que tu parlais du code qui contenait
réelement des caractères accentués, non des u00E9 et compagnie.


Mais il faut se demander ce que voudrait dire « contenir réellement
des caractères accentués ». Je crois que ça ne peut que signifier
qu'on peut les « décoder » et retrouver des caractères accentués à
l'affichage. Que ce soit un codage par u (qu'il faudra bien encoder
lui aussi) ou autre (Unicode, ISO-8859-?, etc.), il faut que les
outils nous permettent de retrouver ce qu'on veut. Le compilateur
doit-il savoir décoder le jeu de caractères si l'environnement
(machine, éditeur, etc.) ne le sait pas ? Je ne crois pas.

Alors malgré toute cette discussion, je crois encore que si l'on
veut écrire du code en français (et non en anglais ou autre langue),
mettre les accents dans le code ne devrait pas être un problème, en
tout cas, pas plus que les accents ailleurs. Que la norme C++
contienne en plus une façon de transférer du code accentué dans un
codage particulier (UCN), me semble une bonne indication que je
n'ai certainement pas complètement tort, même si je ne suis pas au
courant de tout ce qui se passe sur les ordinateurs russes, bulgares,
allemands ou autres ! (et non, ma vision n'est pas du tout limité à
un jeu de caractères sur Windows...)

En fait, les outils de développement pourraient faire ça pour toi.


Je crois que c'était un peu l'intention. Toi, tu écris été, mais ce
qui se trouvait dans le fichier était u00E9tu00E9. Et évidemment,
quand le fichier contenait u00E9tu00E9, l'éditeur affichait été.

Mais apparamment, mes éditeurs ne sont pas à jour. Parce qu'il ne
reconnaissent pas les uxxxx.


Je suppose que pour un spécialiste de Emacs, ce sera un jeu d'enfant
d'arranger ça. Sinon on devra dire mauvais outil, changer d'outil...

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


15 16 17 18 19