j'ai besoin d'aide

raimondeau@gmail.com wrote:

Je suis sur que le responsable de la faq sera ravi
d'accueillir ta "vérification" à moins que tu n'es pas le
temps de vérifier, juste celui de critiquer :)

Deux points importants :

-- Ce site est loins d'être le seul avec ce genre d'erreur,
voire pire. Une des réponses à la question posée
initialement était du genre « Google est ton ami. Voici ce
qu'il dit. » C'est important à signaler que cette réponse
(apparue ici) est fausse. Google est ton ami SI (et
seulement si) tu connais déjà assez pour faire la part des
choses, et savoir séparer le bon grain de l'ivraie.

(Le problème n'est pas propre à la toile, et j'ai déjà
revelé des erreurs dans l'Encyclopedia Brittanica. Mais la
quantité d'informations à laquelle on est exposé sur la
toile rend le problème particulièrement ardu.)

-- Comme Fabien, je n'ai pas le temps de lire toutes les
entrées de cette « FAQ », et en faire une critique
détaillée. Mais le fait de voir une réponse aussi « naive »
me donne de grandes doutes sur la qualité de la reste. Et si
la reste est de la même veine, en corriger cette réponse,
seule, ne changera pas grand chose dans l'affaire.

Je crois qu'on peut dire que Fabien a fait ce qu'il fallait,
c-à-d avertir le posteur auquel on a donné cette réponse d'être
sur ses gardes. Non seulement vis-à-vis du site en question,
mais plus généralement.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

mais
que developpez.com ne le connaisse pas, c'est plus embetant...

On est au courant au sujet de cette question, j'avais d'ailleurs demandé
ici des précisions:
http://groups.google.fr/group/fr.comp.lang.c++/browse_thread/thread/4407df27f19258c0/60f5fb7adad7116d
J'en avais retenu:

Voyons donc où on en est :


-- le code ne compile pas sur certains compilateurs (mais bien
sur d'autres),


-- ayant résolu ce problème, on tombe sur un cas de
comportement indéfini, et


-- ayant éliminé le comportement indéfini, il s'avère que le
résultat est faux.

Et en suivant le fil de ce débat, on constate que c'est un sujet très
complexe en fait.

Sachant que notre public est francophone (je dis ça par rapport au
problème de l'allemand), et attend à une telle question une réponse
simple (c'est typiquement une demande pour un devoir d'étudiant), nous
avons estimé qu'il n'était pas nécessaire de rajouter un tel niveau de
complexité pour une question somme toute banale. Car comment résumer
tout ce qui a été dit en quelques lignes ? Ce sujet à lui tout seul
mériterait un article dédié...
L'enjeu est de savoir ce que ça rapporte par rapport à ce que ça coûte,
et nous avons pensé que ça apportait beaucoup de confusion pour, en
pratique, rien de mieux (cette solution imparfaite fait la plupart du
temps largement l'affaire).
En revanche, nous n'avons pas mentionné que cette solution est loin
d'être parfaite, et qu'elle ne peut pas être retenue si l'on a des
critères élevés de fiabilité.
Nous en prenons note et allons le préciser.

Pourquoi ? T'aurait-on fait croire que ce site contient des
informations valables ?
J'ai nettement l'impression que pour ce genre de site, l'important est
d'avoir la plus grande quantité possible de contenu. Du coup, aucune
vérification n'est effectuée.

Là je peux t'assurer que c'est faux. D'abord il n'y a pas que le C++, et
certaines sections ont très bonne réputation. Et même pour le C++, si à
ses débuts cette section a effectivement eu tendance à "aspirer" tout ce
qui lui passait sous la main, on essaye maintenant de tirer la qualité
vers le haut. On refuse régulièrement des cours qui nous sont proposés,
et suite au projet de critique des ressources francophones initié par
Loïc Joly je crois (french cpp reviews):
http://perso.numericable.fr/~jlloicjoly40/c++/Critiques/
nous avons retiré de notre liste certains tutoriels. Nous attendions
avec enthousiasme la critique de la FAQ C++, afin de la faire évoluer,
mais le projet s'est essoufflé.

On essaye malgré tout d'en faire un document de qualité, en traitant la
STL, boost, et en introduisant des concepts comme le RAII, etc... Je ne
crois pas qu'il y ait beaucoup de documents francophones traitant de cela.

Mais si d'un côté on essaye d'aborder des sujets plutôt pointus (dans la
limite de nos compétences), de l'autre on n'a aucune réponse à la
question "comment je lis dans un fichier ?", qui elle est réellement
fréquente.
Donc on essaye de jongler entre justesse et accessibilité. Tu dois bien
savoir comme c'est difficile pour avoir initié la FAQ de
fr.comp.os.ms-windows.programmation

Il est clair que ce document ne sera jamais à la hauteur des discussions
de ce newsgroup, mais je ne crois pas que cela en fasse un mauvais
document pour autant. Ne serait-ce que parce qu'on plébiscite
std::string on mérite un peu de considération ;-)
En plus on commence à être cité ici, ce qui est pour moi une
satisfaction, même si on se fait démonter. Petit à petit, on corrigera
les points litigieux, et ainsi on progressera. C'est vraiment mon
souhait de proposer un document (rédigé par des) francophone de qualité.

Concernant les autres ressources, je pense que ça dépasse le cadre de
www.developpez.com pour celui des ressources francophones disponibles.
La question est de savoir s'il y a des documents de qualité que nous
n'hébergeons pas. Si c'est le cas, merci de nous les préciser sans
attendre, nous serons très heureux d'en faire la promotion.
Cependant, j'ai peur que nous hébergions malgré tout le haut du pavé en
ce qui concerne le C++. A qui la faute ? Nous avons conscience que le
Net manque de bonnes ressources en français sur ce sujet, mais que faire
? Ne rien proposer, ou faute de mieux mettre à disposition ce qui existe ?

On est donc conscient de nos faiblesses. Et on essaye de réagir, dans la
limite du temps libre des rares contributeurs. Ainsi, à défaut de
trouver des documents de qualité, et d'être capables de les rédiger, on
s'est récemment lancé dans la traduction de "Thinking in C++", qui date
un peu, mais bon, c'est pas si mal pour débuter.


--
Aurélien Regat-Barrel

On Mon, 21 Nov 2005 16:13:27 +0100, Aurelien Regat-Barrel :

Nous en prenons note et allons le préciser.

Ça me paraît effectivement important.
Sur un sujet aussi épineux que le changement de casse, toute méthode
devrait être accompagnée de ses limites de validité.

Et même pour le C++, si à
ses débuts cette section a effectivement eu tendance à "aspirer" tout ce
qui lui passait sous la main

C'est toujours le même problème : si tu pars d'un amoncellement de
trucs en vrac, même si tu améliores la qualité générale petit à petit,
il est très difficile pour le néophyte de savoir si tel ou tel
document est de bonne qualité ou pas.

Dans des cas comme ça, on s'en sort généralement en faisant un tri
systématique (i.e. tout document n'ayant pas été visé par un expert
est soit enlevé, soit mis dans une catégorie "documents de qualité
inconnue"), puis une campagne de publicité pour tenter d'enlever
l'image négative qu'on avait au départ.

Tu dois bien
savoir comme c'est difficile pour avoir initié la FAQ de
fr.comp.os.ms-windows.programmation

La FAQ d'un forum, c'est facile (mais fastidieux) : on prend les
questions qui reviennent tout le temps dans un forum, et on fait un
copier-coller des réponses habituelles.

Nous avons conscience que le
Net manque de bonnes ressources en français sur ce sujet, mais que faire
? Ne rien proposer, ou faute de mieux mettre à disposition ce qui existe ?

Bonne question...

Je dirais : mettre à disposition ce qui existe, en précisant bien que
c'est "faute de mieux".

Note qu'il faut distinguer entre trois types de publics :

- L'étudiant qui fait du C++ parce que c'est dans son cursus, mais qui
ne s'y intéresse pas particulièrement -- il voit juste la
programmation comme un moyen de gagner des points pour son diplôme. Il
lui faut donc apprendre, sans trop se fatiguer, les méthodes qui vont
satisfaire son prof, point final.

- L'amateur, qui considère la programmation comme un loisir. Il
n'apprendra jamais toutes les finesses du C++, faute de temps, mais ce
n'est pas bien grave.

- Le professionnel, qui programme toute la journée pour gagner sa vie.
Il lit l'anglais technique (c'est un prérequis), et a donc accès aux
ressources et livres anglophones. S'il est bien aiguillé, il
commencera sans doute son apprentissage par "Accelerated C++", qui
semble le livre le plus conseillé sur fclc++.

Si tu présentes une information incomplète et que tu connais une
ressource en anglais qui donne plus de précisions, il ne faut pas
hésiter à le dire. La plupart des gens qui visent un bon niveau en C++
savent lire l'anglais (ou devront l'apprendre un jour ou l'autre),
même s'ils commencent spontanément leur recherche par un site
francophone.

Nous en prenons note et allons le préciser.

Ça me paraît effectivement important.
Sur un sujet aussi épineux que le changement de casse, toute méthode
devrait être accompagnée de ses limites de validité.

A vrai dire il me semblais qu'on avait donné cette précision lors du
traitement de l'erreur avec g++, je sais pas trop pourquoi ça n'a pas
été fait. Un oubli...

Et même pour le C++, si à
ses débuts cette section a effectivement eu tendance à "aspirer" tout ce
qui lui passait sous la main

C'est toujours le même problème : si tu pars d'un amoncellement de
trucs en vrac, même si tu améliores la qualité générale petit à petit,
il est très difficile pour le néophyte de savoir si tel ou tel
document est de bonne qualité ou pas.

Dans des cas comme ça, on s'en sort généralement en faisant un tri
systématique (i.e. tout document n'ayant pas été visé par un expert
est soit enlevé, soit mis dans une catégorie "documents de qualité
inconnue"), puis une campagne de publicité pour tenter d'enlever
l'image négative qu'on avait au départ.

On n'est pas des experts... C'est pour ça qu'on était contents du projet
d'évaluation, on voulait s'en servir pour donner une note aux cours.

Nous avons conscience que le
Net manque de bonnes ressources en français sur ce sujet, mais que faire
? Ne rien proposer, ou faute de mieux mettre à disposition ce qui existe ?

Bonne question...

Je dirais : mettre à disposition ce qui existe, en précisant bien que
c'est "faute de mieux".

Note qu'il faut distinguer entre trois types de publics :

- L'étudiant qui fait du C++ parce que c'est dans son cursus, mais qui
ne s'y intéresse pas particulièrement -- il voit juste la
programmation comme un moyen de gagner des points pour son diplôme. Il
lui faut donc apprendre, sans trop se fatiguer, les méthodes qui vont
satisfaire son prof, point final.

- L'amateur, qui considère la programmation comme un loisir. Il
n'apprendra jamais toutes les finesses du C++, faute de temps, mais ce
n'est pas bien grave.

- Le professionnel, qui programme toute la journée pour gagner sa vie.
Il lit l'anglais technique (c'est un prérequis), et a donc accès aux
ressources et livres anglophones. S'il est bien aiguillé, il
commencera sans doute son apprentissage par "Accelerated C++", qui
semble le livre le plus conseillé sur fclc++.

Je ferai plutôt une distinction entre 2 types de public : ceux qui
veulent une solution rapide à leur problème, et les curieux qui veulent
une explication. Que ce soit dans le cadre des études, du boulot ou du
loisir, on trouve ces 2 profils.

Certains sont totalement dépassés, parce qu'ils viennent d'un autre
métier et se retrouvent bombardés développeur C++ parce que
l'informaticien s'est barré, parce qu'ils sont en reconversion, parce
que la boîte cherche des prétexes pour licencier, ... D'autres
s'essayent au C++ un peu comme ça. Vu que www.developpez.com traite de
nombreux langages, pas mal de débutants débarquent en ayant en tête la
fonction strtoupper() de PHP ou autre, et veulent l'équivalent C++. Tu
peux expliquer qu'il n'y a pas bijection, etc... "oui mais moi je
cherche juste l'équivalent de strtoupper()!".

Donc y'a un impératif de concision de code. Pour être totalement
honnête, dans ce cas précis, je suis réticent à publier un code tel que
l'a posté James:

typedef std::ctype< char >
Cvt ;
std::transform(
source.begin(), source.end(),
std::back_inserter( dest ),
std::bind1st(
std::mem_fun(
static_cast< char (Cvt::*)( char ) const >(
&Cvt::tolower ) ),
&std::use_facet< Cvt >( std::locale() ) ) ) ;

Sans oublier d'initialiser le locale global avant. Et sans
oublier d'inclure <algorithm>, <functional>, <iterator>, <local>

car cela fait très peur déjà, et je ne veux pas que ça alimente des
opinions / trolls sur "le c++ c'est horrible". L'idée de la FAQ est de
présenter une vitrine intéressante du C++, et non pas repoussante. Alors
je me vois mal donner tout ça comme équivalent à strtoupper(). Mais je
réalise que je me suis peut être trompé, il faut savoir admettre les
faiblesses de ses outils.
Et y'a aussi le fait qu'on doit pouvoir expliquer le code, on ne cherche
pas à plagier fr.comp.lang.c++.

Si tu présentes une information incomplète et que tu connais une
ressource en anglais qui donne plus de précisions, il ne faut pas
hésiter à le dire. La plupart des gens qui visent un bon niveau en C++
savent lire l'anglais (ou devront l'apprendre un jour ou l'autre),
même s'ils commencent spontanément leur recherche par un site
francophone.

Je suis d'accord. D'ailleurs à propos du problème de compilation avec
g++, on donne le pdf de GdR en lien. Le problème avec les liens externes
c'est qu'ils sont statistiquement rapidement brisés. Donc sorti des
valeurs sûres comme gotw, on essaye de limiter les références.

--
Aurélien Regat-Barrel

"kanze" <kanze@gabi-soft.fr> écrivait:

Franck Branjonneau wrote:

"kanze" <kanze@gabi-soft.fr> écrivait:

Franck Branjonneau wrote:

Yoxoman <yoxoman@aol.com> écrivait:

La solution avec transform serait quelque chose du
genre :

typedef std::ctype< char >
Cvt ;
std::transform(
source.begin(), source.end(),
std::back_inserter( dest ),
std::bind1st(
std::mem_fun(
static_cast< char (Cvt::*)( char ) const >(
&Cvt::tolower ) ),
&std::use_facet< Cvt >( std::locale() ) ) ) ;

Sans oublier d'initialiser le locale global avant.

Ca me fait penser à un film : Scanners. Ca parle de gens
capables de faire exploser le cerveau d'autres presonnes
à distance.

Si c'est le static_cast<> qui t'ennuie, tu peux l'enelever.

Tu en es sûr ?

Je n'ai aucune certitude.

Il y a bien deux fonctions std::ctype<>::tolower, selon la
norme. C'est vrai que la deuxième prend deux paramètres, et
qu'il n'y a aucune instantiation de std::mem_fun qui accepte
l'adresse d'une fonction à deux paramètres.

Oui mais ce ne sont pas des fonctions templates. Ce sont des
fonctions membres d'une classe template std::ctype<>. Qui,
elle, a été instanciée avec char, le compilateur doit donc
choisir entre les deux signatures

std::ctype< char >::tolower(char) const;
std::ctype< char >::tolower(char, const char) const;

pour choisir quelle std::mem_fun<> utiliser.

C'est juste, mais je ne crois pas que ça change grand chose.

Je crois que si.

Pour déterminer les paramètres d'instantiation de
std::mem_fun<>, on se sert de la déduction des types, qui elle
ne fonctionne (je crois) qu'avec un type connu. Or, pour
connaître le type ici, il faut de la résolution du surcharge.

Je ne suis pas sur que l'on puisse parler de résolution du surcharge,
même si ça revient au même.

Si j'ai bien compris la norme, la résolution du surcharge ne se fait
qu'une fois la déduction des types finie ; de toute façon, il a
besoin de l'instantiation pour faire la résolution du surcharge.

"Résolution de surcharge" et déduction de type font parties
de la déduction des arguments templates (en particulier les types) --
je crois que tu ne différencies pas "déduction de type" et "déduction
des arguments templates".

Mais tes commentaires m'ont amené a regardé dans la norme. En
fait, §14.8.2.2 dit bien que « Template arguments can be deduced
from the type specified when taking the address of an overloaded
function. »

Non, 14.8.2.2 c'est (l'emphase est mienne) « Deducing template arguments taking the
address of a function *template* ».

, et dans §14.8.2.4 :

In some cases, tye deduction is done using a single set of types
P and A. [P est le type du paramètre formel, et A le type du
paramètre réel].

in other cases, there will be a set of corresponding types P and A.

Type deduction is done independantly for each P/A pair, and the
deduced template argument values are then combined. If type
decduction cannot be done for any P/A pair, or if for any pair
the deduction leads to more than one possible set of deduced
values, or if different pairs yield different deduced values, or
if any template argument remains neither deduced nor explicilty
specified, template argument deduction fails.

Ce qui n'est pas particulièrement clair.

L'algorithme en lui même est accessible, determiner P/A est
malaisé. Je pars de 14.8.2.1 « Deducing template arguments from a
function call » et je cale. Aussi je saute en 14.8.2.4/16 « A
template argument can be deduced from a pointer to function or pointer
to member function argument if the set of overloaded functions does
not contain function templates and at most one of a set of overloaded
functions provides a unique match. » Ce qui, je crois, règle le cas de
std::ctype<>::tolower.

Pour le cas de std::tolower/std::tolower<>, tu auras noté que
14.8.2.4/16 est similaire à la résolution de surcharge (dans le sens
de 13.4) avec une contrainte plus forte sur les fonctions templates.
C'est cette contrainte qui, je crois, autorise g++-3.x (x à voir) à
rejeter

std::transform(
source.begin(), source.end(),
cible,
&::tolower)

Je note simplement que g++-4.0 compile ce code.

(C'est une analyse simpliste. Le cas pointeur sur fonction est
distinct du cas pointeur sur fonction membre, en particulier
14.8.2.4/1 prévoit des conversions sur T, A.)

Il y a bien deux analyses distinctes : la déduction des types,
et la résolution des surcharges.

Si d'une part, résolution de surcharge c'est 13.3 -- et par extension
13.4 -- et, d'autre part, déduction des types c'est déduction des
arguments templates, alors non. L'analyse c'est 14.8.2.4/16.

--
Franck Branjonneau

Aurelien Regat-Barrel <nospam.aregatba@yahoo.fr> écrivait:

mais que developpez.com ne le connaisse pas, c'est plus embetant...

On est au courant au sujet de cette question, j'avais d'ailleurs demandé
ici des précisions:
http://groups.google.fr/group/fr.comp.lang.c++/browse_thread/thread/4407df27f19258c0/60f5fb7adad7116d
J'en avais retenu:

Voyons donc où on en est :


-- le code ne compile pas sur certains compilateurs (mais bien
sur d'autres),


-- ayant résolu ce problème, on tombe sur un cas de
comportement indéfini, et


-- ayant éliminé le comportement indéfini, il s'avère que le
résultat est faux.

Et en suivant le fil de ce débat, on constate que c'est un sujet très
complexe en fait.

Sachant que notre public est francophone (je dis ça par rapport au
problème de l'allemand), et attend à une telle question une réponse
simple (c'est typiquement une demande pour un devoir d'étudiant), nous
avons estimé qu'il n'était pas nécessaire de rajouter un tel niveau de
complexité pour une question somme toute banale.

Une réponse simple : « Il n'existe pas de réponse simple. » ou « Je ne
sais pas. » Ne fais pas de réponse inexacte -- à tout le moins que tu
sais inexacte.

--
Franck Branjonneau

Aurelien Regat-Barrel wrote:

mais que developpez.com ne le connaisse pas, c'est plus
embetant...

On est au courant au sujet de cette question, j'avais
d'ailleurs demandé ici des précisions:
http://groups.google.fr/group/fr.comp.lang.c++/browse_thread/thread/4407d f27f19258c0/60f5fb7adad7116d
J'en avais retenu:

Voyons donc où on en est :

-- le code ne compile pas sur certains compilateurs (mais bien
sur d'autres),

-- ayant résolu ce problème, on tombe sur un cas de
comportement indéfini, et

-- ayant éliminé le comportement indéfini, il s'avère que le
résultat est faux.

Et en suivant le fil de ce débat, on constate que c'est un
sujet très complexe en fait.

Sur plusieurs plans, d'ailleurs.

Sachant que notre public est francophone (je dis ça par
rapport au problème de l'allemand), et attend à une telle
question une réponse simple (c'est typiquement une demande
pour un devoir d'étudiant), nous avons estimé qu'il n'était
pas nécessaire de rajouter un tel niveau de complexité pour
une question somme toute banale. Car comment résumer tout ce
qui a été dit en quelques lignes ? Ce sujet à lui tout seul
mériterait un article dédié...

Je suis tout à fait d'accord que dans une FAQ de ce genre, il
n'y a pas besoin d'expliquer toutes les subtilités derrière le
concepte de majuscule et de minuscule. (Je verais bien, en
revanche, une phrase simple qui signale que tout n'y a pas été
dit, avec éventuellement un lien vers le site Unicode, pour ceux
qui veut plus d'informations.)

Encore que... ça me semble tellement évident que ce n'est pas la
peine de le dire, mais on sait jamais : est-ce qu'il faut la
peine de signaler que si les majuscules ne comportent pas
d'accents, les minuscules qu'on en retire n'en auront pas non
plus ? Que c'est vraiment une conversion bête et méchante, et
que dans certains cas, il faut aller plus loin ?

Ça, en ce qui concerne des histoires de 'ß', et l'absence en
général d'une bijection entre les majuscules et les minuscules.
Reste le problème proprement C++. Le code donné est incorrect.
Il n'est pas légal. Il a un comportement indéfini, quand il
compile (ce qui n'est pas garanti non plus). Et... ce
comportement indéfini se manifest par des conversions
« aléatoires » sur bien des machines courantes.

L'enjeu est de savoir ce que ça rapporte par rapport à ce que
ça coûte, et nous avons pensé que ça apportait beaucoup de
confusion pour, en pratique, rien de mieux (cette solution
imparfaite fait la plupart du temps largement l'affaire).

Sauf qu'il ne compile pas avec certains des compilateurs les
plus répandus. Sauf qu'il donne des résultats faux avec
d'autres.

Ce n'est pas ce que j'appelle « fait la plupart du temps
largement l'affaire. » Le code qui y apparaît est faux.

En revanche, nous n'avons pas mentionné que cette solution est
loin d'être parfaite, et qu'elle ne peut pas être retenue si
l'on a des critères élevés de fiabilité. Nous en prenons note
et allons le préciser.

Ce qu'il faudrait au minimum (parce que je comprends bien que tu
n'as pas envie d'y introduire les locale et al.), c'est :

1. Inclure <ctype.h> (ou <cctype>, si tu préfères), et ôter le
commentaire qu'il est inclut par <string> (qui est un aléa
de l'implémentation, et qui risque d'être avec la plupart
des implémentations, y compris la prochaine version du
compilateur que tu utilises de référence).

2. Écrire un petit classe fonctionnelle qui l'utilise :

struct ToLower
{
char operator()( char ch ) const
{
return tolower( static_cast< unsigned char >( ch) ) ;
// ou std::tolower, si tu inclus <cctype>...
}
} ;

Utilise un objet de cette classe dans le transform :

std::transform( ..., ToLower() ) ;

Il n'y a (malheureusement) pas de solution plus simple qui
marche, surtout en français, où sur la plupart des machines, les
caractères accentués ont des valeurs négatives dans un char.
C'est un problème historique, qui était connu déjà des auteurs
de la norme C90 ; déjà en C, les caractères ont deux
représentations, une sur char, et une sur int, et ces
représentations n'ont pas toujours les mêmes valeurs numériques
pour un caractere donné. Alors, dans la mesure où on veut se
servir des fonctions de la bibliothèque C, il faut bien prendre
en compte leurs faiblesses.

Et au fond, je ne sais pas si c'est si malheureux que ça.
L'utilisation d'un objet fonctionnel est vraiment idiomatique en
C++ moderne. C'est une bonne occasion de la montrer, avec un
objet ultra simple, et sans d'autres complications. À la long,
c'est sûrement la leçon qui leur servira le plus de tout ça.

Pourquoi ? T'aurait-on fait croire que ce site contient des
informations valables ? J'ai nettement l'impression que
pour ce genre de site, l'important est d'avoir la plus
grande quantité possible de contenu. Du coup, aucune
vérification n'est effectuée.

Là je peux t'assurer que c'est faux.

Je ne connais pas le site en question. Je n'en dis donc rien.
N'empèche que l'attitude « je l'ai trouvé avec Google, c'est
sûrement correct » provoque une certaine méfiance de ma part.
Certes, Google est une résource extraordinaire, quand on y
connaît assez pour faire le tri. Mais il faut bien faire le
tri ; il y a plus de dèsinformation de que de l'information.
Pour une question d'aussi bas niveau, alors, Google n'est pas
l'ami.

--
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

On Mon, 21 Nov 2005 17:55:09 +0100, Aurelien Regat-Barrel
<nospam.aregatba@yahoo.fr>:

Je ferai plutôt une distinction entre 2 types de public : ceux qui
veulent une solution rapide à leur problème, et les curieux qui veulent
une explication.

Donc y'a un impératif de concision de code. Pour être totalement
honnête, dans ce cas précis, je suis réticent à publier un code tel que
l'a posté James:

Ben oui mais non.
Le plus efficace serait d'écrire, dans la FAQ, une fonction à
copier-coller :

std::string strtoupper (std::string const& s)
{
[le code de James]
}

Ceux qui veulent comprendre chercheront à comprendre le code ; ceux
qui veulent une réponse rapide font un copier-coller de la fonction et
se contentent d'utiliser cette fonction strtoupper comme s'ils étaient
en PHP.

car cela fait très peur déjà, et je ne veux pas que ça alimente des
opinions / trolls sur "le c++ c'est horrible".

James et moi sommes en désaccord sur ce point.
Lui veut impérativement utiliser les algorithmes de la STL quoi qu'il
arrive ; moi je suis plus favorable à l'utilisation d'une boucle for()
quand ça simplifie le code.

Alors
je me vois mal donner tout ça comme équivalent à strtoupper().

Il s'agit du _contenu_ de la fonction strtoupper().
Le programmeur PHP ne regarde pas le code de la fonction strtoupper()
mais se contente de l'utiliser ; le programmeur C++ peut faire pareil.

Fabien LE LEZ wrote:

[...]

James et moi sommes en désaccord sur ce point.
Lui veut impérativement utiliser les algorithmes de la STL
quoi qu'il arrive ; moi je suis plus favorable à l'utilisation
d'une boucle for() quand ça simplifie le code.

Pas quoiqu'il arrive. Je ne me servirais jamais de
std::transform pour une conversion majuscule en minuscule dans
une application professionnelle. Ne serait-ce que parce que la
transformation n'est pas un-à-un. (En fait, si je régarde ce que
j'ai fait professionnellement, les transformations un-à-un sont
rarissime, toujours sur place, et souvent sur des objets qui ne
supportent pas l'affectation. Du coup, je ne vois pas l'intérêt
de std::transform.)

Dans un but pédégogique, en revanche, l'énoncé simplifié du
problème (et std::transform) permet de montrer quelque principes
de base simples, comme l'utilisation des objets fonctionnels ET
de prévenir du piège de tolower (présente dans toutes les
fonctions dans <ctype.h>). Et pour ceci, je crois que
std::transform est idéal. Une version réelement utilisable
professionnellement introduirait des complications
supplémentaires ici qui nuiraient à l'efficacité de la
présentation.

--
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

Ce qu'il faudrait au minimum (parce que je comprends bien que tu
n'as pas envie d'y introduire les locale et al.), c'est :

1. Inclure <ctype.h> (ou <cctype>, si tu préfères), et ôter le
commentaire qu'il est inclut par <string> (qui est un aléa
de l'implémentation, et qui risque d'être avec la plupart
des implémentations, y compris la prochaine version du
compilateur que tu utilises de référence).

2. Écrire un petit classe fonctionnelle qui l'utilise :

struct ToLower
{
char operator()( char ch ) const
{
return tolower( static_cast< unsigned char >( ch) ) ;
// ou std::tolower, si tu inclus <cctype>...
}
} ;

Utilise un objet de cette classe dans le transform :

std::transform( ..., ToLower() ) ;

Ah ben oui, je pense que c'est uen très bonne solution ça, parce
qu'effectivement on donne un exemple d'utilisation des foncteurs, mais
on peut rajouter en précision que le ToLower() de l'exemple est limité,
et l'idéal serait de définir sa propre fonction avec une table de
correspondances. Je pense que ça reste très accessible, surtout qu'on
détaille ailleurs le principe des foncteurs.

Merci bien à vous tous.

--
Aurélien Regat-Barrel