j'ai besoin d'aide

On 17 Nov 2005 00:49:46 -0800, "kanze" <kanze@gabi-soft.fr>:

Note bien que l'Académie est silent sur les accents sur les
majuscules.

"en français, l’accent a pleine valeur orthographique"
http://www.academie-francaise.fr/langue/questions.html#accentuation

Pour résumer, même si omettre des accents semble courant, ce n'est pas
moins une faute d'orthographe

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

Il y aurait une impossibilité de déduction avec quelque chose comme

struct Cvt {

template< typename _Character >
_Character
tolower(
_Character) {}
};

ou même

struct Cvt {

template< typename _Character >
_Character
tolower(
_Character);

char
tolower(
char);
};

Mais je ne crois pas que le compilateur soit exigé, ou même
autorisé, à faire l'analyse à ce point, selon §13.4 et §14.8.2.2. Ou
peut-être que si ; j'avoue que ce n'est pas du tout clair dans mon
ésprit.

Je ne suis pas dans ton esprit :-) et je ne comprends pas bien ton
interrogation. L'analyse doit être faite au point d'instanciation de
std::transform<>, non ?

Avec Boost, évidemment, on écrirait :

std::transform(
source.begin(), source.end(),
std::back_inserter( dest ),
boost::bind(
&Cvt::tolower,
&std::use_facet< Cvt >( std::locale() ),
_1 ) ) ;

Je crois que bind fait partie aussi de TR1.

Dans 10 (ou peut-être 20 ans) nous pourrons utiliser std::transform<> :-)

--
Franck Branjonneau

Fabien LE LEZ wrote:

On 17 Nov 2005 00:49:46 -0800, "kanze" <kanze@gabi-soft.fr>:

Note bien que l'Académie est silent sur les accents sur les
majuscules.

"en français, l?accent a pleine valeur orthographique"
http://www.academie-francaise.fr/langue/questions.html#accentuation

Pour résumer, même si omettre des accents semble courant, ce
n'est pas moins une faute d'orthographe

Y compris quand la technologie ne le permet pas, comme dans un
texte dactylographié ?

Je suis d'accord avec toi que l'utilisation des accents sur les
majuscules est préférable. Je l'exige dans mon propre travail,
et je m'attends à ce que d'autres le fasse chaque fois que c'est
technologiquement possible. Mais réalistiquement, les omettre
sur les majuscules est répandu, et selon l'utilisation, on
pourrait bien vouloir qu'un programme ne les exige pas pour
fonctionner correctement. (C'est la première règle de
l'Internet, de nouveau : « Be liberal in what you accept, and
conservative in what you require. »)

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

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

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. », 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]. 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. Je crois ce qu'il veut
dire, c'est que dans ce cas-ci, on a quatre P/A pairs :
S (T::*)()/char (Cvt::*)( char ) const
S (T::*)()/char const* (Cvt::*)( char*, char const* ) const
S (T::*)( U )/char (Cvt::*)( char ) const
S (T::*)( U )/char const* (Cvt::*)( char*, char const* ) const
Seulement, si c'est ça, on tombe sur « If type deduction cannot
be done for any P/A pair... » Or, parmi ces quatre paires, il y
en a bien trois où la déduction de type va échouer. Mais si on
l'interprète comme ça, on va avoir des problèmes prèsque chaque
fois qu'il y a surcharge d'une fonction templatée ; ça ne peut
pas être l'intention. Si en revanche on l'interprète comme « si
un des paires a une contexte non-déductible... », ça fait plus
de sens. Et tu aurais raison ; on écarte les fonctions pour
lesquelles on ne peut pas déduire les types, et on ajoute les
autres à l'ensemble de surcharge, pour résolution ultérieur.

Et plus j'y pense, plus je crois que c'est bien ça. (En passant,
et §14.8.2.2 et §13.4 ne parlent que des adresses des fonctions,
non des adresses des fonctions membre. Je suppose
qu'exceptionnellement, on cible les deux, même si en général,
quand on parle d'une adresse d'une fonction ou d'un objet, on
n'inclut pas les pointeurs aux membres.)

Il y aurait une impossibilité de déduction avec quelque chose
comme

struct Cvt {

template< typename _Character >
_Character
tolower(
_Character) {}
};

ou même

struct Cvt {

template< typename _Character >
_Character
tolower(
_Character);

char
tolower(
char);
};

Tout á fait.

Mais je ne crois pas que le compilateur soit exigé, ou même
autorisé, à faire l'analyse à ce point, selon §13.4 et
§14.8.2.2. Ou peut-être que si ; j'avoue que ce n'est pas du
tout clair dans mon ésprit.

Je ne suis pas dans ton esprit :-) et je ne comprends pas bien
ton interrogation. L'analyse doit être faite au point
d'instanciation de std::transform<>, non ?

Il y a bien deux analyses distinctes : la déduction des types,
et la résolution des surcharges. Qui se font dans cet ordre. Mon
erreur, c'était d'oublier que la déduction des types puisse se
faire sur l'ensemble des fonctions, sans que la résolution du
surcharge a eu lieu. Je crois que ce n'est pas 100% clair ; par
exemple, il est clair pour des raisons pratiques que si
l'ensemble des fonctions est infini (parce qu'il y a un
template), la déduction du type ne peut pas se faire, et je ne
vois pas où la norme fait cette distinction. (Il y a un paquet
de DR sur §14.8.2. Alors, peut-être que le problème est déjà
connu et résolu.)

Avec Boost, évidemment, on écrirait :

std::transform(
source.begin(), source.end(),
std::back_inserter( dest ),
boost::bind(
&Cvt::tolower,
&std::use_facet< Cvt >( std::locale() ),
_1 ) ) ;

Je crois que bind fait partie aussi de TR1.

Dans 10 (ou peut-être 20 ans) nous pourrons utiliser
std::transform<> :-)

Avant de pouvoir utiliser export, peut-être:-).

Dans la pratique, std::transform souffre d'une limitation assez
importante : il faut qu'il y ait le même nombre d'éléments
après la transformation qu'avant. Ce qui est moins souvent le
cas qu'on pourrait penser : ce n'est pas le cas général pour
toupper ou tolower, par exemple. On est donc amener la plupart
du temps a se servir de std::copy avec un itérateur
transformant. Ce qui est dommage, parce qu'appeler « copy »
quand ce qu'on fait est « transform », c'est un peu
l'obfuscation.

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

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

Y compris quand la technologie ne le permet pas, comme dans un
texte dactylographié ?

Si tu casses la touche 'a' de ton ordinateur, et que tu tappes un
texte en ne mettant pas les 'a', est-ce une faute d'orthographe ?
A mon avis, c'en est une, mais tu as juste les circonstances
atténuantes.

--
Matthieu

kanze wrote:

Y compris quand la technologie ne le permet pas, comme dans un
texte dactylographié ?

Selon les règles de typographie en usage à l'Imprimerie Nationale, il
faut accentuer les majuscules à condition de pouvoir mettre tous les
accents.
Mais il vaut mieux ne rien accentuer que d'avoir la moitié seulement des
majuscules devant être accentuées, accentuées.

La seule justification pour ne pas accentuer les majuscules est une
impossibilité technique (historiquement, les machines d'imprimerie
souvent d'origine américaine n'en étaient pas capables).

Je suis d'accord avec toi que l'utilisation des accents sur les
majuscules est préférable. Je l'exige dans mon propre travail,
et je m'attends à ce que d'autres le fasse chaque fois que c'est
technologiquement possible.

En ceci, tu sembles être en parfait accord avec l'Imprimerie
Nationale... :-)
--
Arnaud

Salut
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 :)

On 18 Nov 2005 11:44:33 -0800, "raimondeau@gmail.com"
<raimondeau@gmail.com>:

Je suis sur que le responsable de la faq sera ravi d'accueillir ta
"vérification"

Peut-être. Mais franchement, si le reste de cette FAQ est à l'avenant,
je ne crois pas que ça vaille le coup d'essayer de bricoler.

à moins que tu n'es pas le temps

Je confirme, je ne suis pas Saturne, je suis Fabien.

Matthieu Moy wrote:

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

Y compris quand la technologie ne le permet pas, comme dans un texte
dactylographié ?

Si tu casses la touche 'a' de ton ordinateur, et que tu tappes un
texte en ne mettant pas les 'a', est-ce une faute d'orthographe ? A
mon avis, c'en est une, mais tu as juste les circonstances
atténuantes.

Il y a une différence énorme entre une machine qui est cassée, et qui ne
fournit pas toutes les fonctionnalités prévues, et une machine qui
fonctionne comme prévu par sa conception. Dans le cas du texte
dactylographié, la machine fonctionne comme prévu par sa conception.

Aujourd'hui, évidemment, les textes dactylographiés n'existent pour
ainsi dire plus. Avec Word, c'est bien possible d'entrer des majuscules
accentuées. Ce n'est même pas difficile, pour peu qu'on y cherche un
peu. N'empèche qu'ils ne sont pas sur le clavier. Est-ce une faiblesse
de la technologie, ou de l'utilisateur, quand l'utilisateur ne se sert
pas des majuscules accentuées ?

À mon avis, et ça n'engage que moi, ça dépend de l'utilisateur. Si
j'embauche un informaticien, je m'attendrais à ce qu'il ait assez de
sens de précision de de communication pour vouloir mettre les accents
sur les majuscules, et assez de débrouillardise technique pour y trouver
le moyen. Une manque systèmatiquement des accents sur les majuscules sur
le CV, et il atterrit tout de suite à la poubelle. Qu'un artiste s'en
passe dans certaines contextes (parce que la précision ne l'intéresse
pas), ou qu'un secrétaire n'y arrive pas, c'est plus compréhensible.

Et comme j'ai dit, c'est mon avis. Si un client me démande une
conversion de majescules en minuscules, je commencerai par lui démander
son avis, et ce qu'il faut faire dans le cas des majuscules non
accentuées. Avant de lui donner un prix ou un termine:-)... s'il veut
que je convertisse les majuscules sans accents en minuscules avec
accents, ça va coûter beaucoup plus cher, prendre beaucoup plus de
temps, et il y aurait des réserves sur les résultats. (En fait, le faire
en français ne me paraît pas faisable, au moins que d'analyser toute la
phrase.)

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

Arnaud Meurgues wrote:

kanze wrote:

Y compris quand la technologie ne le permet pas, comme dans un
texte dactylographié ?

Selon les règles de typographie en usage à l'Imprimerie
Nationale, il faut accentuer les majuscules à condition de
pouvoir mettre tous les accents. Mais il vaut mieux ne rien
accentuer que d'avoir la moitié seulement des majuscules
devant être accentuées, accentuées.

La seule justification pour ne pas accentuer les majuscules
est une impossibilité technique (historiquement, les machines
d'imprimerie souvent d'origine américaine n'en étaient pas
capables).

Dans l'industrie, il n'y a pas si longtemps, la dactylographie
règnait. Et l'impossibilité technique de mettre des accents sur
les majuscules (sauf les trèma et les circonflexes).

Je suis d'accord avec toi que l'utilisation des accents sur les
majuscules est préférable. Je l'exige dans mon propre travail,
et je m'attends à ce que d'autres le fasse chaque fois que c'est
technologiquement possible.

En ceci, tu sembles être en parfait accord avec l'Imprimerie
Nationale... :-)

Ce n'est pas un hazard. Ma référence dans la matiere, c'est bien
la "Lexique des règles typographiques un usage à l'imprimerie
nationale".

Et je ne veux surtout pas disputer avec ceux qui trouvent que
c'est mieux. Je dis seulement qu'on écrit un programme pour
remplir un cahier de charges, et qu'on ne peut pas toujours
imposer tout ce qu'on veut à ce cahier de charges. Si le client
a le texte sans accents, je ne vais pas réfuser le contrat pour
autant.

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