fonction C++ pour comparer deux string

James Kanze

21/09/2003 à 21:29

"Michaël Monerau" writes:

|> James Kanze wrote:
|> >>> int CMP_NoCase (const std::string& s1, const std::string& s2)
|> >>> {
|> >>> std::string::const_iterator p1 = s1.begin();
|> >>> std::string::const_iterator p2 = s2.begin();
|> >>> while (p1 != s1.end() && p2 != s2.end())
|> >>> {
|> >>> if (toupper (*p1) != toupper (*p2))
|> >>> return (toupper (*p1) <
|> >>> toupper (*p2)) ? -1 : 1;

|> > Tu rémarques que sur la plupart des implémentations, le code
|> > ci-dessus est bourré des comportements indéfinis. Tu ne peux
|> > pas passer un char à toupper.

|> Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
|> veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

|> Mais alors, comment expliques-tu le code issu du Stroustrup :

|> p.591, §20.3.8 :
|> #### début citation
|> for example, the 'toupper' function (§20.4.2) allows us to write
|> case-insensitive comparisons :

|> using namespace std;
|> int cmp_nocase (const string& s, const string& s2)
|> {
|> string::const_iterator p = s.begin ();
|> string::const_iterator p2 = s2.begin ();

|> while (p != s.end() && p2 != s2.end)
|> {
|> if (toupper(*p) != toupper (*p2))
|> // blah blah blah
|>
|> // ...
|> }
|> #### fin citation

|> Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

Probablement (vue son age et son expérience), il était au courant
des problèmes de base dans le C de K&R. Et qu'il a naïvement cru
que les corrections apportées par le comité C en étaient les
bonnes.

|> Et au 20.4.2, on a :
|> #### citation
|> In <ctype.h> and <cctype>, the standard library provides a set of
|> useful functions for dealing with ASCII and similar characters sets
|> :

|> ** liste des fonctions **
|> int toupper (int c); // uppercase equivalent to c
|> int tolower (int c); // lowercase equivalent to c
|> #### fin citation

C'est très bon. Seulement, il ne cite pas les restrictions.

|> Par contre, là, pourquoi utiliser un int, je ne sais pas trop...

Parce que la norme C l'exige.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

|> (pour autoriser des caractères sur plusieurs octets plus tard ?)
|> Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
|> isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
|> C++ avec un argument char (qui sera donc converti en int) soit
|> implementation-defined... Sinon, à quoi serviraient ces fonctions
|> ?

D'abord, strictement parlant, la conversion de char en int est défini
par l'implémentation -- si sizeof(int) == 1 et le type char est
non-signé, en tout cas. Dans la pratique, c'est un cas extrème,
qu'on peut tranquillement ignorer sur des processeurs généraux.

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

|> >>> La mise en page est peut-être un peu archaïque,
|> >>> désolé. "toupper" (prononcer "toupet" :p) fait partie de
|> >>> la lib C (donc #include <string.h>).

|> > Non seulement il font partie de la lib C, il ne prenent pas ce
|> > char comme paramètre, et le lui en passer donne un comportement
|> > indéfini.

|> Pourquoi ? une conversion char -> int n'est pas bien compliqué ?!
|> Enfin, je ne connais pas ce domaine...

La conversion n'est pas bien compliqué. Mais rien ne dit que le
résultat de la conversion convient comme paramètre à isxxx.

|> >> Tu peux cependant utiliser std::toupper, mais il faut un locale
|> >>> comme deuxième argument, chose que je ne connais pas encore
|> >>:o)

|> > C'est nettement mieux, parce que le premier paramètre est bien
|> > un char, et non un int avec une portée restreinte qui ne
|> > comprend pas toutes les valeurs d'un char.

|> > En revanche, ça pose un problème de portabilité :
|> > <locale> n'existe que sur un des trois compilateurs qu'on utilise
|> > où je travaille, par exemple.

|> > Note que quoique tu fasses, le résultat dépendra d'un locale.

|> OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
|> dis pas que c'est impossible !!! ;-)

C'est impossible:-).

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

"Michaël Monerau" <cort@meloo.com> writes:

|> James Kanze wrote:
|> >>> int CMP_NoCase (const std::string& s1, const std::string& s2)
|> >>> {
|> >>> std::string::const_iterator p1 = s1.begin();
|> >>> std::string::const_iterator p2 = s2.begin();
|> >>> while (p1 != s1.end() && p2 != s2.end())
|> >>> {
|> >>> if (toupper (*p1) != toupper (*p2))
|> >>> return (toupper (*p1) <
|> >>> toupper (*p2)) ? -1 : 1;

|> > Tu rémarques que sur la plupart des implémentations, le code
|> > ci-dessus est bourré des comportements indéfinis. Tu ne peux
|> > pas passer un char à toupper.

|> Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
|> veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

|> Mais alors, comment expliques-tu le code issu du Stroustrup :

|> p.591, §20.3.8 :
|> #### début citation
|> for example, the 'toupper' function (§20.4.2) allows us to write
|> case-insensitive comparisons :

|> using namespace std;
|> int cmp_nocase (const string& s, const string& s2)
|> {
|> string::const_iterator p = s.begin ();
|> string::const_iterator p2 = s2.begin ();

|> while (p != s.end() && p2 != s2.end)
|> {
|> if (toupper(*p) != toupper (*p2))
|> // blah blah blah
|>
|> // ...
|> }
|> #### fin citation

|> Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

Probablement (vue son age et son expérience), il était au courant
des problèmes de base dans le C de K&R. Et qu'il a naïvement cru
que les corrections apportées par le comité C en étaient les
bonnes.

|> Et au 20.4.2, on a :
|> #### citation
|> In <ctype.h> and <cctype>, the standard library provides a set of
|> useful functions for dealing with ASCII and similar characters sets
|> :

|> ** liste des fonctions **
|> int toupper (int c); // uppercase equivalent to c
|> int tolower (int c); // lowercase equivalent to c
|> #### fin citation

C'est très bon. Seulement, il ne cite pas les restrictions.

|> Par contre, là, pourquoi utiliser un int, je ne sais pas trop...

Parce que la norme C l'exige.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

|> (pour autoriser des caractères sur plusieurs octets plus tard ?)
|> Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
|> isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
|> C++ avec un argument char (qui sera donc converti en int) soit
|> implementation-defined... Sinon, à quoi serviraient ces fonctions
|> ?

D'abord, strictement parlant, la conversion de char en int est défini
par l'implémentation -- si sizeof(int) == 1 et le type char est
non-signé, en tout cas. Dans la pratique, c'est un cas extrème,
qu'on peut tranquillement ignorer sur des processeurs généraux.

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

|> >>> La mise en page est peut-être un peu archaïque,
|> >>> désolé. "toupper" (prononcer "toupet" :p) fait partie de
|> >>> la lib C (donc #include <string.h>).

|> > Non seulement il font partie de la lib C, il ne prenent pas ce
|> > char comme paramètre, et le lui en passer donne un comportement
|> > indéfini.

|> Pourquoi ? une conversion char -> int n'est pas bien compliqué ?!
|> Enfin, je ne connais pas ce domaine...

La conversion n'est pas bien compliqué. Mais rien ne dit que le
résultat de la conversion convient comme paramètre à isxxx.

|> >> Tu peux cependant utiliser std::toupper, mais il faut un locale
|> >>> comme deuxième argument, chose que je ne connais pas encore
|> >>:o)

|> > C'est nettement mieux, parce que le premier paramètre est bien
|> > un char, et non un int avec une portée restreinte qui ne
|> > comprend pas toutes les valeurs d'un char.

|> > En revanche, ça pose un problème de portabilité :
|> > <locale> n'existe que sur un des trois compilateurs qu'on utilise
|> > où je travaille, par exemple.

|> > Note que quoique tu fasses, le résultat dépendra d'un locale.

|> OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
|> dis pas que c'est impossible !!! ;-)

C'est impossible:-).

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

"Michaël Monerau" writes:

|> James Kanze wrote:
|> >>> int CMP_NoCase (const std::string& s1, const std::string& s2)
|> >>> {
|> >>> std::string::const_iterator p1 = s1.begin();
|> >>> std::string::const_iterator p2 = s2.begin();
|> >>> while (p1 != s1.end() && p2 != s2.end())
|> >>> {
|> >>> if (toupper (*p1) != toupper (*p2))
|> >>> return (toupper (*p1) <
|> >>> toupper (*p2)) ? -1 : 1;

|> > Tu rémarques que sur la plupart des implémentations, le code
|> > ci-dessus est bourré des comportements indéfinis. Tu ne peux
|> > pas passer un char à toupper.

|> Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
|> veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

|> Mais alors, comment expliques-tu le code issu du Stroustrup :

|> p.591, §20.3.8 :
|> #### début citation
|> for example, the 'toupper' function (§20.4.2) allows us to write
|> case-insensitive comparisons :

|> using namespace std;
|> int cmp_nocase (const string& s, const string& s2)
|> {
|> string::const_iterator p = s.begin ();
|> string::const_iterator p2 = s2.begin ();

|> while (p != s.end() && p2 != s2.end)
|> {
|> if (toupper(*p) != toupper (*p2))
|> // blah blah blah
|>
|> // ...
|> }
|> #### fin citation

|> Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

Probablement (vue son age et son expérience), il était au courant
des problèmes de base dans le C de K&R. Et qu'il a naïvement cru
que les corrections apportées par le comité C en étaient les
bonnes.

|> Et au 20.4.2, on a :
|> #### citation
|> In <ctype.h> and <cctype>, the standard library provides a set of
|> useful functions for dealing with ASCII and similar characters sets
|> :

|> ** liste des fonctions **
|> int toupper (int c); // uppercase equivalent to c
|> int tolower (int c); // lowercase equivalent to c
|> #### fin citation

C'est très bon. Seulement, il ne cite pas les restrictions.

|> Par contre, là, pourquoi utiliser un int, je ne sais pas trop...

Parce que la norme C l'exige.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

|> (pour autoriser des caractères sur plusieurs octets plus tard ?)
|> Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
|> isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
|> C++ avec un argument char (qui sera donc converti en int) soit
|> implementation-defined... Sinon, à quoi serviraient ces fonctions
|> ?

D'abord, strictement parlant, la conversion de char en int est défini
par l'implémentation -- si sizeof(int) == 1 et le type char est
non-signé, en tout cas. Dans la pratique, c'est un cas extrème,
qu'on peut tranquillement ignorer sur des processeurs généraux.

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

|> >>> La mise en page est peut-être un peu archaïque,
|> >>> désolé. "toupper" (prononcer "toupet" :p) fait partie de
|> >>> la lib C (donc #include <string.h>).

|> > Non seulement il font partie de la lib C, il ne prenent pas ce
|> > char comme paramètre, et le lui en passer donne un comportement
|> > indéfini.

|> Pourquoi ? une conversion char -> int n'est pas bien compliqué ?!
|> Enfin, je ne connais pas ce domaine...

La conversion n'est pas bien compliqué. Mais rien ne dit que le
résultat de la conversion convient comme paramètre à isxxx.

|> >> Tu peux cependant utiliser std::toupper, mais il faut un locale
|> >>> comme deuxième argument, chose que je ne connais pas encore
|> >>:o)

|> > C'est nettement mieux, parce que le premier paramètre est bien
|> > un char, et non un int avec une portée restreinte qui ne
|> > comprend pas toutes les valeurs d'un char.

|> > En revanche, ça pose un problème de portabilité :
|> > <locale> n'existe que sur un des trois compilateurs qu'on utilise
|> > où je travaille, par exemple.

|> > Note que quoique tu fasses, le résultat dépendra d'un locale.

|> OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
|> dis pas que c'est impossible !!! ;-)

C'est impossible:-).

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Michaël Monerau

21/09/2003 à 21:58

James Kanze wrote:

Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

C'est vrai qu'il doit chier dans la colle :-)

Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

ouch :- Ce serait quelque chose à lui rapporter alors... Je lui mettrai
dans le mail que je vais lui écrire (tu peux m'envoyer son adresse s'il te
plaît ? ;) ). Mais avant, je voudrais être sûr d'avoir bien compris la
chose.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int.

En fait, les fonctions 'isxxx' utilisent le locale "C" (c'est-à-dire ASCII
?) ? Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je crois que
les 128 premiers caractères sont les mêmes et que seules les suivants
diffèrent, c'est bien ça ?).

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1 si on
active le "Default char unsigned". Mais cette option n'est pas activée par
défaut... :(

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus,
en ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-) Mais si
je pouvais gérer correctement et entièrement le français (et donc européen,
avec l'allemand, l'espagnol, etc...), y compris le fourbe 'ÿ', ça serait
sympa :-) Ca marcherait en mettant seulement un cast 'unsigned char' dessus
? Et les histoires de locale s'accordent si on reste en ASCII ?

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

Merci pour toutes ces précisions !
--
<=- Michaël "Cortex" Monerau -=>

James Kanze wrote:

Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

C'est vrai qu'il doit chier dans la colle :-)

Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

ouch :- Ce serait quelque chose à lui rapporter alors... Je lui mettrai
dans le mail que je vais lui écrire (tu peux m'envoyer son adresse s'il te
plaît ? ;) ). Mais avant, je voudrais être sûr d'avoir bien compris la
chose.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int.

En fait, les fonctions 'isxxx' utilisent le locale "C" (c'est-à-dire ASCII
?) ? Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je crois que
les 128 premiers caractères sont les mêmes et que seules les suivants
diffèrent, c'est bien ça ?).

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1 si on
active le "Default char unsigned". Mais cette option n'est pas activée par
défaut... :(

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus,
en ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-) Mais si
je pouvais gérer correctement et entièrement le français (et donc européen,
avec l'allemand, l'espagnol, etc...), y compris le fourbe 'ÿ', ça serait
sympa :-) Ca marcherait en mettant seulement un cast 'unsigned char' dessus
? Et les histoires de locale s'accordent si on reste en ASCII ?

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

Merci pour toutes ces précisions !
--
<=- Michaël "Cortex" Monerau -=>

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze wrote:

Ah, je ne savais pas... Sur mon VC 7.1, ça fonctionne, mais je
veux bien croire que ce ne serait pas le cas partout.

Je n'ai pas accès à un VC 7.1, mais avec VC 6.0, compilé avec
les options par défaut, ça ne marche pas. Essaie, par exemple,
toupper('ÿ').

C'est vrai qu'il doit chier dans la colle :-)

Stroustrup aurait écrit quelque chose non conforme ?

Disons qu'il a écrit quelque chose qui ne marche pas avec des
compilateurs auquels j'ai accès : Sun CC 5.1, VC++ 6.0 et g++
(plusieurs versions). Quelque chose qui n'a jamais marché, depuis les
premiers jours de C.

ouch :- Ce serait quelque chose à lui rapporter alors... Je lui mettrai
dans le mail que je vais lui écrire (tu peux m'envoyer son adresse s'il te
plaît ? ;) ). Mais avant, je voudrais être sûr d'avoir bien compris la
chose.

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche
parfaitement. Le problème, c'est que raisonablement, il fallait
restreindre l'étendu qu'elles acceptent en entrée --
l'implémentation classique, qu'on a voulu laisser légale, c'est un
tableau, et on ne peut guère accepter un tableau de INT_MAX-INT_MIN
éléments. La règle donc, c'est qu'il faut que ch soit dans
l'étendue [0...UCHAR_MAX] ou qu'il vaut EOF (qui doit être
négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé.
Ça veut dire que quand on convertit un char en int, on se retrouve
avec des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de
'ÿ' est particulièrement pernicieux, parce que avec ISO 8859-n, et
des char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int.

En fait, les fonctions 'isxxx' utilisent le locale "C" (c'est-à-dire ASCII
?) ? Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je crois que
les 128 premiers caractères sont les mêmes et que seules les suivants
diffèrent, c'est bien ça ?).

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il y
avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et
ça donnait l'air de marcher. Mais c'était une pratique
systèmatique dans toutes les boîtes européenes où j'ai
travaillé, depuis au moins quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1 si on
active le "Default char unsigned". Mais cette option n'est pas activée par
défaut... :(

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne me
dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne
que ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus,
en ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-) Mais si
je pouvais gérer correctement et entièrement le français (et donc européen,
avec l'allemand, l'espagnol, etc...), y compris le fourbe 'ÿ', ça serait
sympa :-) Ca marcherait en mettant seulement un cast 'unsigned char' dessus
? Et les histoires de locale s'accordent si on reste en ASCII ?

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

Merci pour toutes ces précisions !
--
<=- Michaël "Cortex" Monerau -=>

Gabriel Dos Reis

22/09/2003 à 01:39

Fabien LE LEZ writes:

| On 21 Sep 2003 21:04:44 +0200, James Kanze
| wrote:
|
| >Il n'existe aucune comparaison de chaîne de
| >caractères qui ignore la case, en dehors des locales facultatifs.
|
| Y'a pas à dire, le C++, c'est de la merde ! ;-)

yup.

| Au fait, existe-t-il des systèmes où les 52 lettres ([A-Za-z]) ne sont
| pas (toutes) présentes ?

Éwé :-).

-- Gaby

Michaël Monerau

22/09/2003 à 07:36

James Kanze wrote:

Fabien LE LEZ writes:
Y'a pas à dire, le C++, c'est de la merde ! ;-) Au fait,
existe-t-il des systèmes où les 52 lettres ([A-Za-z]) ne sont
pas (toutes) présentes ?

Italien. Il n'y a pas de J, K, W, X, ou Y.

Mais alors, tu n'as pas d'initiales en Italien !?!?!

;-)
--
<=- Michaël "Cortex" Monerau -=>

Erwann ABALEA

22/09/2003 à 08:29

On 21 Sep 2003, James Kanze wrote:

À titre d'exemple : tu donnes un fichier avec les noms des villes du
banlieu parisien à un programme écrit en C. Il y en aurait pas mal
qui s'arrête pile au milieu de la ligne avec Le-Haÿ-des-Roses.

Pour y avoir habité pendant 15 ans, je confirme que ça s'écrit bien
L'Haÿ-les-roses, même si ça commence par un H (comme hôpital, l'hôpital,
et pas haricot, le haricot).

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
comment fait on pour craker un logiciel car j'ai le logiciel et le
crack, et quand je lance le crack ca m'ouvre une session dos et c'est
tous, y'a t'il quelque chose à écrire dans cette session sous dos ?
-+- FV in : Guide du Neuneu Usenet : Aidez-moi ou je cracke -+-

Christophe Lephay

22/09/2003 à 14:19

a écrit dans le message de
news:

Non. Ça a dailleurs posé des problèmes à ma femme (italienne) lorsqu'on
s'est marié.

Ce qu'il y a de bien avec les italiennes, c'est qu'elles sont généralement
ravies au lit (jeu de mots)...

Chris

kanze

22/09/2003 à 15:14

"Michaël Monerau" wrote in message
news:<Opnbb.301987$...

James Kanze wrote:

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche parfaitement.
Le problème, c'est que raisonablement, il fallait restreindre
l'étendu qu'elles acceptent en entrée -- l'implémentation classique,
qu'on a voulu laisser légale, c'est un tableau, et on ne peut guère
accepter un tableau de INT_MAX-INT_MIN éléments. La règle donc,
c'est qu'il faut que ch soit dans l'étendue [0...UCHAR_MAX] ou qu'il
vaut EOF (qui doit être négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé. Ça
veut dire que quand on convertit un char en int, on se retrouve avec
des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de 'ÿ'
est particulièrement pernicieux, parce que avec ISO 8859-n, et des
char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int. En fait, les fonctions 'isxxx'
utilisent le locale "C" (c'est-à-dire ASCII ?) ?

Non. Il utilise le locale courant. C-à-d le locale précisé par le
dernier appel à setlocale.

Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

Si on veut faire rigueureux, le tout est assez compliqué. Selon
ISO-8859-1, par exemple, le code de 'ÿ' est 255. Seulement, dans la
plupart des implémentations, 255 n'est pas représentable sur un char.
Pire, le résultat d'une affectation de la valeur 255 à un char est
défini par l'implémentation, et la norme C est même plus clair
là-dessus, ce « résultat » peut lever un signal.

Côté pratique, dans les implémentations usuelles, char est 8 bit signé,
complément à deux, et les conversions entre types entiers se contentent
de prendre des bits tel quels, sans poser de questions. Dans ces cas-là,
dans la pratique 1) quand tu lis, et la fonction renvoie int, il faut
bien tester pour le EOF *avant* de convertir en char, et 2) quand tu as
des char, et tu veux utiliser une fonction qui prend un int, il faut
convertir explicitement en unsigned char d'abord. Ça fait que 'ÿ', c'est
en fait -1, mais dans la mésure qu'on ne régarde la valeur numérque
qu'après une conversion en unsigned char (suivi normalement d'une
conversion en int), c'est bon. Officiellement, il n'y a rien dans la
norme qui le garantit, mais pratiquement, il y a tellement de code
existant qui en dépend qu'aucun fournisseur n'oserait le casser.

Dans les deux cas, les fonctions comme isxxx interprète la valeur
numérique -- 255 est bien 'ÿ' en 8859-1 ; alors, islower( 255 ) doit
renvoyer vrai si le locale selectionné utilise un encodage 8859-1.

Toujours est-il que quand des contraints de portabilité le permet (pas
souvent actuellement, mais on espère à une amélioration), il est
préférable à se servir des isxxx de <locale>.

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je
crois que les 128 premiers caractères sont les mêmes et que seules les
suivants diffèrent, c'est bien ça ?).

C'est effectivement ça. ASCII est un code à sept bits, donc de 0 à 127.
Les ISO-8859-n sont des codes à huit bits, de 0 à 255, avec les
caractères de 0 à 127 identiques à ASCII.

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il
y avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et ça
donnait l'air de marcher. Mais c'était une pratique systèmatique
dans toutes les boîtes européenes où j'ai travaillé, depuis au moins
quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1
si on active le "Default char unsigned". Mais cette option n'est pas
activée par défaut... :(

C'est une longue discussion. Logiquement, il serait plus raisonable que
les char soit nonsigné. Selon K&R, il pourrait être signé ou non, et
parmi les premières implémentations, on trouvait les deux, selon ce qui
était plus efficace sur la machine. Mais la plus efficace sur PDP-11,
c'était signé, et par la suite, il y a eu pas mal de code qui comptait
dessus. Le resultat, c'est que les implémenteurs, quand il n'y avait pas
une grande différence, choisissait signé, pour que le code incorrect,
mais qui semblait marcher, continue à sembler marcher.

Si tu peux, je privilègerais bien l'option char nonsigné. À l'encontre
d'un certain nombre d'autres options (sur l'alignement, par exemple), je
ne crois pas qu'elle puisse poser des problèmes si d'autres modules sont
compilées sans l'option -- théoriquement, peut-être, mais ici aussi, ça
marche parce que sauf dans de cas particuliers, le compilateur passe des
bits sans trop démander ce qu'ils signifient. Alors, tu passes une
valeur 255 ; l'autre voit un -1, mais vue qu'il s'attend à un caractère,
il le traite correctement.

Quand je compile le code à mon site avec VC++, j'utilise bien les char
non-signé. (Option /J à la ligne de commande.) Seulement, ça fait un
moment que je n'ai pas eu accès à un compilateur Windows. Depuis, une
semaine ou deux, je ai de nouveau accès à VC++ 6.0, mais entretemps, mon
code a évolué, et VC++ ne l'accepte plus:-(.

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne
me dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne que
ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-)
Mais si je pouvais gérer correctement et entièrement le français (et
donc européen, avec l'allemand, l'espagnol, etc...), y compris le
fourbe 'ÿ', ça serait sympa :-) Ca marcherait en mettant seulement un
cast 'unsigned char' dessus ?

Ça dépendrait toujours des locales supportés sur la machine en question.

Sur les Sparc et les Linux que j'administre, ça marchera. Dans les deux
cas, par défaut à l'installation, tu as des locales européens
nécessaires. Sur les Sparc que j'utilise au travail, ça ne marcherait
qu'en partie ; pour je ne sais pas quelle raison, ils ont virée la
plupart des locales -- il reste ios_8859_1, ce qui suffirait je crois
pour les isxxx, mais je n'ai pas de formattage des nombres ni de dates
comme il faut. Sous Windows, je ne sais pas ce qu'est la politique
vis-à-vis des locales. Je sais que j'ai pu utiliser des locales avec
VC++ 5.0 sous Windows NT, et que ça a marché, mais je ne sais pas
comment les machines ont été configurées et installées.

Ça dépend aussi du compilateur -- et ce n'est pas rare que ça marche
avec <locale.h> et setlocale, mais pas avec <locale> et les std::isxxx.

Et les histoires de locale s'accordent si on reste en ASCII ?

Qu'est-ce que tu veux dire par « rester en ASCII » ? Si tu es dans un
locale 8859-1, tu es en 8859-1, non ASCII.

Maintenant, si tu es dans un locale de l'Europe (mais non la Turquie)
avec des caractères latins, le résultats de n'importe quel fonction de
<cctype> (ou les équivalents dans <locale>) ne doit pas changé pour un
caractère compris dans l'encodage ASCII.

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

En principe, mais ce n'est pas évident, et je ne suis pas sûr dans
quelle mésure c'est portable.

En fait, une des premières décisions que tu dois faire, c'est vis-à-vis
de la portabilité. Tu as mentionné VC++ 7.1 -- c'est un des compilateurs
les plus avancés en ce qui concerne la partie internationalisation de la
norme. Si les locales sont bien installés (et je répète, je n'ai aucune
idée comment ça se fait sous Windows), et tu n'as pas de problème de
portabilité -- tu sais que ça reste sous Windows, avec VC++, tu as
toutes les cartes qu'il faut. Tu as l'option pour que les char soient
non-signé, et tu as l'implémentation la plus avancée de la bilbiothèque
standard.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

"Michaël Monerau" <cort@meloo.com> wrote in message
news:<Opnbb.301987$ef4.3302750@news.chello.at>...

James Kanze wrote:

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche parfaitement.
Le problème, c'est que raisonablement, il fallait restreindre
l'étendu qu'elles acceptent en entrée -- l'implémentation classique,
qu'on a voulu laisser légale, c'est un tableau, et on ne peut guère
accepter un tableau de INT_MAX-INT_MIN éléments. La règle donc,
c'est qu'il faut que ch soit dans l'étendue [0...UCHAR_MAX] ou qu'il
vaut EOF (qui doit être négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé. Ça
veut dire que quand on convertit un char en int, on se retrouve avec
des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de 'ÿ'
est particulièrement pernicieux, parce que avec ISO 8859-n, et des
char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int. En fait, les fonctions 'isxxx'
utilisent le locale "C" (c'est-à-dire ASCII ?) ?

Non. Il utilise le locale courant. C-à-d le locale précisé par le
dernier appel à setlocale.

Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

Si on veut faire rigueureux, le tout est assez compliqué. Selon
ISO-8859-1, par exemple, le code de 'ÿ' est 255. Seulement, dans la
plupart des implémentations, 255 n'est pas représentable sur un char.
Pire, le résultat d'une affectation de la valeur 255 à un char est
défini par l'implémentation, et la norme C est même plus clair
là-dessus, ce « résultat » peut lever un signal.

Côté pratique, dans les implémentations usuelles, char est 8 bit signé,
complément à deux, et les conversions entre types entiers se contentent
de prendre des bits tel quels, sans poser de questions. Dans ces cas-là,
dans la pratique 1) quand tu lis, et la fonction renvoie int, il faut
bien tester pour le EOF *avant* de convertir en char, et 2) quand tu as
des char, et tu veux utiliser une fonction qui prend un int, il faut
convertir explicitement en unsigned char d'abord. Ça fait que 'ÿ', c'est
en fait -1, mais dans la mésure qu'on ne régarde la valeur numérque
qu'après une conversion en unsigned char (suivi normalement d'une
conversion en int), c'est bon. Officiellement, il n'y a rien dans la
norme qui le garantit, mais pratiquement, il y a tellement de code
existant qui en dépend qu'aucun fournisseur n'oserait le casser.

Dans les deux cas, les fonctions comme isxxx interprète la valeur
numérique -- 255 est bien 'ÿ' en 8859-1 ; alors, islower( 255 ) doit
renvoyer vrai si le locale selectionné utilise un encodage 8859-1.

Toujours est-il que quand des contraints de portabilité le permet (pas
souvent actuellement, mais on espère à une amélioration), il est
préférable à se servir des isxxx de <locale>.

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je
crois que les 128 premiers caractères sont les mêmes et que seules les
suivants diffèrent, c'est bien ça ?).

C'est effectivement ça. ASCII est un code à sept bits, donc de 0 à 127.
Les ISO-8859-n sont des codes à huit bits, de 0 à 255, avec les
caractères de 0 à 127 identiques à ASCII.

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il
y avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et ça
donnait l'air de marcher. Mais c'était une pratique systèmatique
dans toutes les boîtes européenes où j'ai travaillé, depuis au moins
quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1
si on active le "Default char unsigned". Mais cette option n'est pas
activée par défaut... :(

C'est une longue discussion. Logiquement, il serait plus raisonable que
les char soit nonsigné. Selon K&R, il pourrait être signé ou non, et
parmi les premières implémentations, on trouvait les deux, selon ce qui
était plus efficace sur la machine. Mais la plus efficace sur PDP-11,
c'était signé, et par la suite, il y a eu pas mal de code qui comptait
dessus. Le resultat, c'est que les implémenteurs, quand il n'y avait pas
une grande différence, choisissait signé, pour que le code incorrect,
mais qui semblait marcher, continue à sembler marcher.

Si tu peux, je privilègerais bien l'option char nonsigné. À l'encontre
d'un certain nombre d'autres options (sur l'alignement, par exemple), je
ne crois pas qu'elle puisse poser des problèmes si d'autres modules sont
compilées sans l'option -- théoriquement, peut-être, mais ici aussi, ça
marche parce que sauf dans de cas particuliers, le compilateur passe des
bits sans trop démander ce qu'ils signifient. Alors, tu passes une
valeur 255 ; l'autre voit un -1, mais vue qu'il s'attend à un caractère,
il le traite correctement.

Quand je compile le code à mon site avec VC++, j'utilise bien les char
non-signé. (Option /J à la ligne de commande.) Seulement, ça fait un
moment que je n'ai pas eu accès à un compilateur Windows. Depuis, une
semaine ou deux, je ai de nouveau accès à VC++ 6.0, mais entretemps, mon
code a évolué, et VC++ ne l'accepte plus:-(.

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne
me dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne que
ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-)
Mais si je pouvais gérer correctement et entièrement le français (et
donc européen, avec l'allemand, l'espagnol, etc...), y compris le
fourbe 'ÿ', ça serait sympa :-) Ca marcherait en mettant seulement un
cast 'unsigned char' dessus ?

Ça dépendrait toujours des locales supportés sur la machine en question.

Sur les Sparc et les Linux que j'administre, ça marchera. Dans les deux
cas, par défaut à l'installation, tu as des locales européens
nécessaires. Sur les Sparc que j'utilise au travail, ça ne marcherait
qu'en partie ; pour je ne sais pas quelle raison, ils ont virée la
plupart des locales -- il reste ios_8859_1, ce qui suffirait je crois
pour les isxxx, mais je n'ai pas de formattage des nombres ni de dates
comme il faut. Sous Windows, je ne sais pas ce qu'est la politique
vis-à-vis des locales. Je sais que j'ai pu utiliser des locales avec
VC++ 5.0 sous Windows NT, et que ça a marché, mais je ne sais pas
comment les machines ont été configurées et installées.

Ça dépend aussi du compilateur -- et ce n'est pas rare que ça marche
avec <locale.h> et setlocale, mais pas avec <locale> et les std::isxxx.

Et les histoires de locale s'accordent si on reste en ASCII ?

Qu'est-ce que tu veux dire par « rester en ASCII » ? Si tu es dans un
locale 8859-1, tu es en 8859-1, non ASCII.

Maintenant, si tu es dans un locale de l'Europe (mais non la Turquie)
avec des caractères latins, le résultats de n'importe quel fonction de
<cctype> (ou les équivalents dans <locale>) ne doit pas changé pour un
caractère compris dans l'encodage ASCII.

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

En principe, mais ce n'est pas évident, et je ne suis pas sûr dans
quelle mésure c'est portable.

En fait, une des premières décisions que tu dois faire, c'est vis-à-vis
de la portabilité. Tu as mentionné VC++ 7.1 -- c'est un des compilateurs
les plus avancés en ce qui concerne la partie internationalisation de la
norme. Si les locales sont bien installés (et je répète, je n'ai aucune
idée comment ça se fait sous Windows), et tu n'as pas de problème de
portabilité -- tu sais que ça reste sous Windows, avec VC++, tu as
toutes les cartes qu'il faut. Tu as l'option pour que les char soient
non-signé, et tu as l'implémentation la plus avancée de la bilbiothèque
standard.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

"Michaël Monerau" wrote in message
news:<Opnbb.301987$...

James Kanze wrote:

En fait, le but initial, je crois, c'était qu'on puisse les utiliser
de façon :

int ch = getchar() ;
while ( isspace( ch ) ) ...

sans problème, même dans le cas de EOF. Ce qui marche parfaitement.
Le problème, c'est que raisonablement, il fallait restreindre
l'étendu qu'elles acceptent en entrée -- l'implémentation classique,
qu'on a voulu laisser légale, c'est un tableau, et on ne peut guère
accepter un tableau de INT_MAX-INT_MIN éléments. La règle donc,
c'est qu'il faut que ch soit dans l'étendue [0...UCHAR_MAX] ou qu'il
vaut EOF (qui doit être négatif, et qui est typiquement -1).

Or, dans beaucoup d'implémentations courantes : g++, Sun CC, et VC++
sans option particulière, par exemple, char est un type signé. Ça
veut dire que quand on convertit un char en int, on se retrouve avec
des valeurs négatives -- qui ne se trouve pas dans l'étendue
[0...UCHAR_MAX] donc. D'où un comportement indéfini. Le cas de 'ÿ'
est particulièrement pernicieux, parce que avec ISO 8859-n, et des
char de 8 bits, sa valeur est -1 -- du coup, le comportement est
défini, mais pas ce qu'on veut : islower( 'ÿ' ) rend faux.

D'accord, je comprends le coup du int. En fait, les fonctions 'isxxx'
utilisent le locale "C" (c'est-à-dire ASCII ?) ?

Non. Il utilise le locale courant. C-à-d le locale précisé par le
dernier appel à setlocale.

Du coup, si on veut utiliser le ISO-8859-1, comment on peut faire avec
les 'isxxx' ?? On ne peut pas ?

Si on veut faire rigueureux, le tout est assez compliqué. Selon
ISO-8859-1, par exemple, le code de 'ÿ' est 255. Seulement, dans la
plupart des implémentations, 255 n'est pas représentable sur un char.
Pire, le résultat d'une affectation de la valeur 255 à un char est
défini par l'implémentation, et la norme C est même plus clair
là-dessus, ce « résultat » peut lever un signal.

Côté pratique, dans les implémentations usuelles, char est 8 bit signé,
complément à deux, et les conversions entre types entiers se contentent
de prendre des bits tel quels, sans poser de questions. Dans ces cas-là,
dans la pratique 1) quand tu lis, et la fonction renvoie int, il faut
bien tester pour le EOF *avant* de convertir en char, et 2) quand tu as
des char, et tu veux utiliser une fonction qui prend un int, il faut
convertir explicitement en unsigned char d'abord. Ça fait que 'ÿ', c'est
en fait -1, mais dans la mésure qu'on ne régarde la valeur numérque
qu'après une conversion en unsigned char (suivi normalement d'une
conversion en int), c'est bon. Officiellement, il n'y a rien dans la
norme qui le garantit, mais pratiquement, il y a tellement de code
existant qui en dépend qu'aucun fournisseur n'oserait le casser.

Dans les deux cas, les fonctions comme isxxx interprète la valeur
numérique -- 255 est bien 'ÿ' en 8859-1 ; alors, islower( 255 ) doit
renvoyer vrai si le locale selectionné utilise un encodage 8859-1.

Toujours est-il que quand des contraints de portabilité le permet (pas
souvent actuellement, mais on espère à une amélioration), il est
préférable à se servir des isxxx de <locale>.

(Au fait, quelle est la différence entre ISO-8859-1 et ASCII ? Je
crois que les 128 premiers caractères sont les mêmes et que seules les
suivants diffèrent, c'est bien ça ?).

C'est effectivement ça. ASCII est un code à sept bits, donc de 0 à 127.
Les ISO-8859-n sont des codes à huit bits, de 0 à 255, avec les
caractères de 0 à 127 identiques à ASCII.

(pour autoriser des caractères sur plusieurs octets plus tard ?)
Mais c'est le cas de toutes les fonctions 'is*' (come isalpha,
isupper, etc...). Et je doute qu'utiliser une de ces fonctions en
C++ avec un argument char (qui sera donc converti en int) soit
implementation-defined... Sinon, à quoi serviraient ces fonctions
?

[...]

Ensuite, il y a le problème que sur la plupart des implémentations
aujourd'hui, pour diverses raisons historiques, char est signé.
C-à-d qu'il peut prendre des valeurs négatives, et même que
dans la pratique, étant donné qu'il a en général huit bits,
il prend réelement des valeurs négatives. Valeurs qui sont
maintenues lors de la conversion de char en int, et qui donne un
comportement indéfini à des fonctions isxxx dans <ctype.h> (ou
<cctype>).

OK.

Historiquement, en C, la pratique courante était d'utiliser une
conversion explicite : isxxx( (unsigned char)ch ). C'est vrai qu'il
y avait beaucoup d'américains qui ne le faisait pas -- il ne
rencontrait pas de caractères accentués dans leurs fichiers, et ça
donnait l'air de marcher. Mais c'était une pratique systèmatique
dans toutes les boîtes européenes où j'ai travaillé, depuis au moins
quinze ans.

C'est vrai que c'est un bon workaround. Ca serait inutile dans VC 7.1
si on active le "Default char unsigned". Mais cette option n'est pas
activée par défaut... :(

C'est une longue discussion. Logiquement, il serait plus raisonable que
les char soit nonsigné. Selon K&R, il pourrait être signé ou non, et
parmi les premières implémentations, on trouvait les deux, selon ce qui
était plus efficace sur la machine. Mais la plus efficace sur PDP-11,
c'était signé, et par la suite, il y a eu pas mal de code qui comptait
dessus. Le resultat, c'est que les implémenteurs, quand il n'y avait pas
une grande différence, choisissait signé, pour que le code incorrect,
mais qui semblait marcher, continue à sembler marcher.

Si tu peux, je privilègerais bien l'option char nonsigné. À l'encontre
d'un certain nombre d'autres options (sur l'alignement, par exemple), je
ne crois pas qu'elle puisse poser des problèmes si d'autres modules sont
compilées sans l'option -- théoriquement, peut-être, mais ici aussi, ça
marche parce que sauf dans de cas particuliers, le compilateur passe des
bits sans trop démander ce qu'ils signifient. Alors, tu passes une
valeur 255 ; l'autre voit un -1, mais vue qu'il s'attend à un caractère,
il le traite correctement.

Quand je compile le code à mon site avec VC++, j'utilise bien les char
non-signé. (Option /J à la ligne de commande.) Seulement, ça fait un
moment que je n'ai pas eu accès à un compilateur Windows. Depuis, une
semaine ou deux, je ai de nouveau accès à VC++ 6.0, mais entretemps, mon
code a évolué, et VC++ ne l'accepte plus:-(.

OK. Mais alors, comment faire un cmp_nocase en C++ portable ? Ne
me dis pas que c'est impossible !!! ;-)

C'est impossible:-).

;-)

Sérieusement, beaucoup dépend de tes besoins. Dans l'absolu, c'est
impossible, mais souvent, tu n'as pas besoin de traiter tous les
caractères du monde, dans tous les locales possibles. Alors, des
compromises peuvent être considérer. Si le problème ne concerne que
ISO-8859-1, par exemple, il suffit d'utiliser le code ci-dessus, en
ajoutant des conversions vers unsigned char sur les paramètres.

Il est vrai que je ne veux pas gérer tous les alphabets mondiaux ;-)
Mais si je pouvais gérer correctement et entièrement le français (et
donc européen, avec l'allemand, l'espagnol, etc...), y compris le
fourbe 'ÿ', ça serait sympa :-) Ca marcherait en mettant seulement un
cast 'unsigned char' dessus ?

Ça dépendrait toujours des locales supportés sur la machine en question.

Sur les Sparc et les Linux que j'administre, ça marchera. Dans les deux
cas, par défaut à l'installation, tu as des locales européens
nécessaires. Sur les Sparc que j'utilise au travail, ça ne marcherait
qu'en partie ; pour je ne sais pas quelle raison, ils ont virée la
plupart des locales -- il reste ios_8859_1, ce qui suffirait je crois
pour les isxxx, mais je n'ai pas de formattage des nombres ni de dates
comme il faut. Sous Windows, je ne sais pas ce qu'est la politique
vis-à-vis des locales. Je sais que j'ai pu utiliser des locales avec
VC++ 5.0 sous Windows NT, et que ça a marché, mais je ne sais pas
comment les machines ont été configurées et installées.

Ça dépend aussi du compilateur -- et ce n'est pas rare que ça marche
avec <locale.h> et setlocale, mais pas avec <locale> et les std::isxxx.

Et les histoires de locale s'accordent si on reste en ASCII ?

Qu'est-ce que tu veux dire par « rester en ASCII » ? Si tu es dans un
locale 8859-1, tu es en 8859-1, non ASCII.

Maintenant, si tu es dans un locale de l'Europe (mais non la Turquie)
avec des caractères latins, le résultats de n'importe quel fonction de
<cctype> (ou les équivalents dans <locale>) ne doit pas changé pour un
caractère compris dans l'encodage ASCII.

Est-il possible de définir sa (/son ?) propre locale pour avoir le bon
comportement ?

En principe, mais ce n'est pas évident, et je ne suis pas sûr dans
quelle mésure c'est portable.

En fait, une des premières décisions que tu dois faire, c'est vis-à-vis
de la portabilité. Tu as mentionné VC++ 7.1 -- c'est un des compilateurs
les plus avancés en ce qui concerne la partie internationalisation de la
norme. Si les locales sont bien installés (et je répète, je n'ai aucune
idée comment ça se fait sous Windows), et tu n'as pas de problème de
portabilité -- tu sais que ça reste sous Windows, avec VC++, tu as
toutes les cartes qu'il faut. Tu as l'option pour que les char soient
non-signé, et tu as l'implémentation la plus avancée de la bilbiothèque
standard.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze

22/09/2003 à 15:18

Erwann ABALEA wrote in message
news:...

On 21 Sep 2003, James Kanze wrote:

À titre d'exemple : tu donnes un fichier avec les noms des villes du
banlieu parisien à un programme écrit en C. Il y en aurait pas mal
qui s'arrête pile au milieu de la ligne avec Le-Haÿ-des-Roses.

Pour y avoir habité pendant 15 ans, je confirme que ça s'écrit bien
L'Haÿ-les-roses, même si ça commence par un H (comme hôpital,
l'hôpital, et pas haricot, le haricot).

Merci pour la correction. Je n'y suis jamais habité, et j'avoue que la
seule chose que je connais de la ville, c'est que c'est la plus grande
commune en France avec un ÿ dans son nom:-). Pour la reste, j'ai bien vu
des panneaux sur l'A 86 en passant, mais je n'y ai jamais prété trop
d'attention.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Christophe Lephay

22/09/2003 à 15:29

"Christophe Lephay" a écrit dans le message
de news:bkmteb$6mr$

a écrit dans le message de
news:
Je n'y suis jamais habité, et j'avoue que la
seule chose que je connais de la ville, c'est que c'est la plus grande
commune en France avec un ÿ dans son nom:-). Pour la reste, j'ai bien vu
des panneaux sur l'A 86 en passant, mais je n'y ai jamais prété trop
d'attention.

Il me semble me souvenir que c'était aussi un terminus du RER à une époque

Ce qui, soit dit en passant, ne présente absolument aucun intérêt...

Chris

Erwann ABALEA

22/09/2003 à 18:36

On Mon, 22 Sep 2003, Christophe Lephay wrote:

a écrit dans le message de
news:
Je n'y suis jamais habité, et j'avoue que la
seule chose que je connais de la ville, c'est que c'est la plus grande
commune en France avec un ÿ dans son nom:-). Pour la reste, j'ai bien vu
des panneaux sur l'A 86 en passant, mais je n'y ai jamais prété trop
d'attention.

Il me semble me souvenir que c'était aussi un terminus du RER à une époque

Non, il n'y a pas de gare RER à L'Haÿ-les-roses. Dans les villes voisines,
c'est possible (Bagneux, Arcueil, Cachan, ...).

Mais effectivement, ça n'a pas grand intérêt.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
FC> Commencez par ne pas envoyer vos contributions en triple exemplaire
JD> Quelle contribution ?
J'abandonne. PLONK.
-+- FC in GNU : Une fois, 2 fois, 3 fois, adjugé au plonké du fond -+-

fonction C++ pour comparer deux string

10 réponses

Veuillez sélectionner un problème