Il y a pas mal de doc sur Perl et Unicode, mais ça reste flou et le
comportement semble bizarre. Voici un exemple nommé "enctest":
#!/usr/bin/env perl
use strict;
my $agrave = chr(0xe0);
my $str = "A grave = '$agrave'";
print "stdout: $str\n";
print STDERR "stderr: $str\n";
warn " warn: $str\n";
die " die: $str\n";
Je voudrais obtenir un "à" encodé correctement, que ce soit avec des
locales en ISO-8859-1 ou avec des locales en UTF-8 (évidemment, le
terminal est configuré de manière cohérente avec les locales). Je me
demande ce que je dois ajouter à ce script (de manière la plus simple
possible).
Je passe sur le cas des locales en ISO-8859-1, qui ne posent pas
vraiment de problèmes. Je considère alors qu'on est en UTF-8.
Si j'exécute "./enctest" ou "perl enctest", ça sort en ISO-8859-1,
comme indiqué dans la doc. Je ne veux pas une solution basée sur
l'option -C, car je veux pouvoir exécuter le script comme ceci:
"./enctest". Il faut que la solution soit dans le script lui-même
(de manière aussi à ne pas affecter les autres scripts Perl, donc
pas de PERL_UNICODE non plus).
Cependant, l'option -C n'a pas l'air de bien fonctionner, donc je
vais tout de même mentionner ceci:
$ perl -C enctest
stdout: A grave = 'à'
stderr: A grave = 'à'
warn: A grave = '?'
die: A grave = '?'
Note: le '?' désigne ici un "à" encodé en ISO-8859-1, que le terminal
ne comprend donc pas. Pourquoi le warn et le die ne fonctionnent-ils
pas correctement?
Si j'utilise
use encoding ':locale';
alors j'obtiens sans l'option -C:
stdout: A grave = 'à'
stderr: A grave = '?'
warn: A grave = 'à'
die: A grave = 'à'
Un "man encoding" dit que STDERR n'est pas affecté par le use encoding,
c'est donc normal pour les deux premières lignes. Mais alors pourquoi
le warn et le die sont-ils maintenant en UTF-8???
Maintenant, si j'utilise seulement
use open OUT => ':locale';
alors j'ai le même résultat qu'avec -C (c'est cohérent). La solution
pour obtenir un "à" correctement encodé est d'utiliser les deux:
use encoding ':locale';
use open OUT => ':locale';
Un des gros problèmes d'UTF-8 n'est-il pas la taille variable en octet des caractères, qui doit terriblement ralentir les opérations d'extraction de sous-chaîne sur position ? J'imagine l'inefficacité *intrinsèque* , par exemple, d'instructions du genre
De nombreux logiciels n'utilisent pas UTF-8 en interne, mais des "wide characters", qui correspondent aux codes 32 bits Unicode. Maintenant on peut choisir l'un ou l'autre suivant ce qu'on veut faire. Je pense que pour les opérations courantes en Perl, UTF-8 doit convenir.
Dans l'article <43a7300b$0$13113$79c14f64@nan-newsreader-05.noos.net>,
FDA <armingaud@gmail.com> écrit:
Un des gros problèmes d'UTF-8 n'est-il pas la taille variable en octet
des caractères, qui doit terriblement ralentir les opérations
d'extraction de sous-chaîne sur position ? J'imagine l'inefficacité
*intrinsèque* , par exemple, d'instructions du genre
De nombreux logiciels n'utilisent pas UTF-8 en interne, mais des
"wide characters", qui correspondent aux codes 32 bits Unicode.
Maintenant on peut choisir l'un ou l'autre suivant ce qu'on veut
faire. Je pense que pour les opérations courantes en Perl, UTF-8
doit convenir.
Un des gros problèmes d'UTF-8 n'est-il pas la taille variable en octet des caractères, qui doit terriblement ralentir les opérations d'extraction de sous-chaîne sur position ? J'imagine l'inefficacité *intrinsèque* , par exemple, d'instructions du genre
De nombreux logiciels n'utilisent pas UTF-8 en interne, mais des "wide characters", qui correspondent aux codes 32 bits Unicode. Maintenant on peut choisir l'un ou l'autre suivant ce qu'on veut faire. Je pense que pour les opérations courantes en Perl, UTF-8 doit convenir.
Vincent Lefevre wrote in message <20051221215931$:
C'est discutable. Avec ce point de vue, il ne faut pas non plus traduire l'interface. Dans la réalité, les programmes traduisent stderr, à commencer par les coreutils, donc je dois supposer que STDERR peut contenir des caractères non ASCII.
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants, et tu constateras rapidement que les messages d'erreur traduits sont une horreur.
Vincent Lefevre wrote in message
<20051221215931$3270@prunille.vinc17.org>:
C'est discutable. Avec ce point de vue, il ne faut pas non plus
traduire l'interface. Dans la réalité, les programmes traduisent
stderr, à commencer par les coreutils, donc je dois supposer que
STDERR peut contenir des caractères non ASCII.
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants,
et tu constateras rapidement que les messages d'erreur traduits sont une
horreur.
Vincent Lefevre wrote in message <20051221215931$:
C'est discutable. Avec ce point de vue, il ne faut pas non plus traduire l'interface. Dans la réalité, les programmes traduisent stderr, à commencer par les coreutils, donc je dois supposer que STDERR peut contenir des caractères non ASCII.
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants, et tu constateras rapidement que les messages d'erreur traduits sont une horreur.
Vincent Lefevre
Dans l'article <docngd$1gj0$, Nicolas George <nicolas$ écrit:
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants, et tu constateras rapidement que les messages d'erreur traduits sont une horreur.
Rien n'empêche un logiciel d'afficher la version anglaise *et* la version traduite. Tout le monde ne comprend pas l'anglais, et imposer des messages d'erreur en anglais seulement n'est pas raisonnable.
De toute façon, si le débutant comprend l'anglais au point d'aller demander de l'aide dans les forums anglophones, il peut toujours configurer son système (ou son application) en anglais. C'est mieux, car ainsi tout est en anglais et on pourra mieux l'aider (pour l'aide, il n'y a pas que les messages d'erreur, mais aussi l'interface, comme les entrées des menus, etc.).
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que les logiciels soient capables (à la demande) de logger tout ce qui se passe, et cette fois-ci systématiquement en anglais.
Dans l'article <docngd$1gj0$1@biggoron.nerim.net>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants,
et tu constateras rapidement que les messages d'erreur traduits sont une
horreur.
Rien n'empêche un logiciel d'afficher la version anglaise *et*
la version traduite. Tout le monde ne comprend pas l'anglais,
et imposer des messages d'erreur en anglais seulement n'est pas
raisonnable.
De toute façon, si le débutant comprend l'anglais au point d'aller
demander de l'aide dans les forums anglophones, il peut toujours
configurer son système (ou son application) en anglais. C'est mieux,
car ainsi tout est en anglais et on pourra mieux l'aider (pour
l'aide, il n'y a pas que les messages d'erreur, mais aussi
l'interface, comme les entrées des menus, etc.).
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que
les logiciels soient capables (à la demande) de logger tout ce qui se
passe, et cette fois-ci systématiquement en anglais.
Dans l'article <docngd$1gj0$, Nicolas George <nicolas$ écrit:
Lis pendant quelques semaines des forums consacrés à l'aide aux débutants, et tu constateras rapidement que les messages d'erreur traduits sont une horreur.
Rien n'empêche un logiciel d'afficher la version anglaise *et* la version traduite. Tout le monde ne comprend pas l'anglais, et imposer des messages d'erreur en anglais seulement n'est pas raisonnable.
De toute façon, si le débutant comprend l'anglais au point d'aller demander de l'aide dans les forums anglophones, il peut toujours configurer son système (ou son application) en anglais. C'est mieux, car ainsi tout est en anglais et on pourra mieux l'aider (pour l'aide, il n'y a pas que les messages d'erreur, mais aussi l'interface, comme les entrées des menus, etc.).
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que les logiciels soient capables (à la demande) de logger tout ce qui se passe, et cette fois-ci systématiquement en anglais.
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que les logiciels soient capables (à la demande) de logger tout ce qui se passe, et cette fois-ci systématiquement en anglais.
IBM donnait à chaque erreur de chaque programme un numéro, une gravité parmi 4 et un libellé. Aux marketings des différents pays de traduire, s'ils l'estimaient important, les messages en question sans changer les numéros associés. Ou de ne traduire qu'une classe de gravité, ce qui était toutefois plus rare.
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que
les logiciels soient capables (à la demande) de logger tout ce qui se
passe, et cette fois-ci systématiquement en anglais.
IBM donnait à chaque erreur de chaque programme un numéro, une gravité
parmi 4 et un libellé. Aux marketings des différents pays de traduire,
s'ils l'estimaient important, les messages en question sans changer les
numéros associés. Ou de ne traduire qu'une classe de gravité, ce qui
était toutefois plus rare.
Le mieux pour l'aide, les rapports de bugs et le débuggage serait que les logiciels soient capables (à la demande) de logger tout ce qui se passe, et cette fois-ci systématiquement en anglais.
IBM donnait à chaque erreur de chaque programme un numéro, une gravité parmi 4 et un libellé. Aux marketings des différents pays de traduire, s'ils l'estimaient important, les messages en question sans changer les numéros associés. Ou de ne traduire qu'une classe de gravité, ce qui était toutefois plus rare.
FDA
substr $a, 6000, 2000
lorsqu'on passe de l'ASCII à l'UTF-8 :-(
Même en ASCII c'est inefficace.
Tu plaisantes ? Cela se traduit certainement par moins de 5 instructions assembleur ! C'est *long* , certes, mais en aucun cas *inefficace* .
substr $a, 6000, 2000
lorsqu'on passe de l'ASCII à l'UTF-8 :-(
Même en ASCII c'est inefficace.
Tu plaisantes ? Cela se traduit certainement par moins de 5 instructions
assembleur ! C'est *long* , certes, mais en aucun cas *inefficace* .
Tu plaisantes ? Cela se traduit certainement par moins de 5 instructions assembleur ! C'est *long* , certes, mais en aucun cas *inefficace* .
FDA
L'accès direct à un caractère de chaîne par position est une opération fondamentalement inutile.
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi. Je ne sais pas comment les choses sont codées en Perl, mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme). Avec des caractères de taille variable, cela restera utile, mais ne pourra en revanche plus être fait de la même façon.
Pour une chaîne, le mode d'opération normal est de la parcourir à la recherche de motifs, typiquement avec un moteur d'expression rationnelles ou un parseur plus évolué
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance. ce n'est pas effectuer une normalisation que de dire à tout un chacun "faites comme moi" :-D
dans ces conditions, il est possible de noter un index direct vers les positions retenues, qui n'est pas une position en caractères mais est exploitable immédiatement pour toutes les opérations d'extraction de sous-chaîne.
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
En rpincipe, les responsabilités sont bien partagées : au programmeur d'écrire de façon lisible - c'est tout ce qu'on lui demande parce que faire autrement coûte *très* cher en maintenance, qui bouffe 50% des budgets - et au compilateur optimiseur (ou à tout autre dispositif dans le cas d'un interpréteur) d'optimiser.
L'accès direct à un caractère de chaîne par position est une opération
fondamentalement inutile.
Sauf quand tu veux faire une recherche limitée à une sous-chaîne
précise, pour des raisons ne regardant que toi. Je ne sais pas comment
les choses sont codées en Perl, mais dans des langages comme PL/I,
substr est une pseudo-fonction qui ne fait que définir une table
d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on
peut mettre un substr() à gauche d'un signe = sans état d'âme). Avec des
caractères de taille variable, cela restera utile, mais ne pourra en
revanche plus être fait de la même façon.
Pour une chaîne, le mode
d'opération normal est de la parcourir à la recherche de motifs, typiquement
avec un moteur d'expression rationnelles ou un parseur plus évolué
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance. ce
n'est pas effectuer une normalisation que de dire à tout un chacun
"faites comme moi" :-D
dans
ces conditions, il est possible de noter un index direct vers les positions
retenues, qui n'est pas une position en caractères mais est exploitable
immédiatement pour toutes les opérations d'extraction de sous-chaîne.
Comment fais-tu pour noter ce "index direct qui n'est pas une position
en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
En rpincipe, les responsabilités sont bien partagées : au programmeur
d'écrire de façon lisible - c'est tout ce qu'on lui demande parce que
faire autrement coûte *très* cher en maintenance, qui bouffe 50% des
budgets - et au compilateur optimiseur (ou à tout autre dispositif dans
le cas d'un interpréteur) d'optimiser.
L'accès direct à un caractère de chaîne par position est une opération fondamentalement inutile.
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi. Je ne sais pas comment les choses sont codées en Perl, mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme). Avec des caractères de taille variable, cela restera utile, mais ne pourra en revanche plus être fait de la même façon.
Pour une chaîne, le mode d'opération normal est de la parcourir à la recherche de motifs, typiquement avec un moteur d'expression rationnelles ou un parseur plus évolué
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance. ce n'est pas effectuer une normalisation que de dire à tout un chacun "faites comme moi" :-D
dans ces conditions, il est possible de noter un index direct vers les positions retenues, qui n'est pas une position en caractères mais est exploitable immédiatement pour toutes les opérations d'extraction de sous-chaîne.
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
En rpincipe, les responsabilités sont bien partagées : au programmeur d'écrire de façon lisible - c'est tout ce qu'on lui demande parce que faire autrement coûte *très* cher en maintenance, qui bouffe 50% des budgets - et au compilateur optimiseur (ou à tout autre dispositif dans le cas d'un interpréteur) d'optimiser.
Nicolas George
FDA wrote in message <43ab1bd2$0$18863$:
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu définie par son index de début et de fin, qui sont des index directs.
mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise.
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance.
Non, non, non : prends n'importe quel programme en perl un tant soit peu idiomatique, et compare le nombre d'utilisations des expressions rationnelles et de substr.
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un détail d'implémentation sans grande importance.
FDA wrote in message
<43ab1bd2$0$18863$79c14f64@nan-newsreader-05.noos.net>:
Sauf quand tu veux faire une recherche limitée à une sous-chaîne
précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu
définie par son index de début et de fin, qui sont des index directs.
mais dans des langages comme PL/I,
substr est une pseudo-fonction qui ne fait que définir une table
d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on
peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est
mauvaise.
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance.
Non, non, non : prends n'importe quel programme en perl un tant soit peu
idiomatique, et compare le nombre d'utilisations des expressions
rationnelles et de substr.
Comment fais-tu pour noter ce "index direct qui n'est pas une position
en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un
scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un
détail d'implémentation sans grande importance.
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu définie par son index de début et de fin, qui sont des index directs.
mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise.
Lire "pour une chaîne, le mode d'opération que j'utilise", nuance.
Non, non, non : prends n'importe quel programme en perl un tant soit peu idiomatique, et compare le nombre d'utilisations des expressions rationnelles et de substr.
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un détail d'implémentation sans grande importance.
FDA
FDA wrote in message <43ab1bd2$0$18863$:
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu définie par son index de début et de fin, qui sont des index directs.
Et il ne te vient pas à l'idée que ça oblige à compter tous les caractères depuis le début, de savoir quel octet ou double octet contient ton index de fin ?
mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise.
???
Non, non, non : prends n'importe quel programme en perl un tant soit peu idiomatique, et compare le nombre d'utilisations des expressions rationnelles et de substr.
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus d'expression de tableaux et de rang : l'utilisateur utilise dans chaque langage ce qui s'y trouve de plus concis et de plus puissant. C'est humain, même si parfois inévitablement cela conduit à un peu d'overkill (voir l'histoire du tailleur, de Fernand Raynaud).
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un détail d'implémentation sans grande importance.
L'intérêt d'un langage est tout de même souvent de présenter une présentation unifiée entre des morceaux de programme écrits par des contributeurs différents. Si chacun doit se bricoler sa petite boite à outils dans son coin et à son idée, alors les programmes ne seront guère lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça, c'est dans tous les langages).
FDA wrote in message
<43ab1bd2$0$18863$79c14f64@nan-newsreader-05.noos.net>:
Sauf quand tu veux faire une recherche limitée à une sous-chaîne
précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu
définie par son index de début et de fin, qui sont des index directs.
Et il ne te vient pas à l'idée que ça oblige à compter tous les
caractères depuis le début, de savoir quel octet ou double octet
contient ton index de fin ?
mais dans des langages comme PL/I,
substr est une pseudo-fonction qui ne fait que définir une table
d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on
peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est
mauvaise.
???
Non, non, non : prends n'importe quel programme en perl un tant soit peu
idiomatique, et compare le nombre d'utilisations des expressions
rationnelles et de substr.
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus
d'expression de tableaux et de rang : l'utilisateur utilise dans chaque
langage ce qui s'y trouve de plus concis et de plus puissant. C'est
humain, même si parfois inévitablement cela conduit à un peu d'overkill
(voir l'histoire du tailleur, de Fernand Raynaud).
Comment fais-tu pour noter ce "index direct qui n'est pas une position
en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un
scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un
détail d'implémentation sans grande importance.
L'intérêt d'un langage est tout de même souvent de présenter une
présentation unifiée entre des morceaux de programme écrits par des
contributeurs différents. Si chacun doit se bricoler sa petite boite à
outils dans son coin et à son idée, alors les programmes ne seront guère
lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa
lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça,
c'est dans tous les langages).
Sauf quand tu veux faire une recherche limitée à une sous-chaîne précise, pour des raisons ne regardant que toi.
Je ne vois pas le problème : la sous-chaîne en question est bien entendu définie par son index de début et de fin, qui sont des index directs.
Et il ne te vient pas à l'idée que ça oblige à compter tous les caractères depuis le début, de savoir quel octet ou double octet contient ton index de fin ?
mais dans des langages comme PL/I, substr est une pseudo-fonction qui ne fait que définir une table d'accès: une adresse d'octet, une longueur en octets (ce qui fait qu'on peut mettre un substr() à gauche d'un signe = sans état d'âme).
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise.
???
Non, non, non : prends n'importe quel programme en perl un tant soit peu idiomatique, et compare le nombre d'utilisations des expressions rationnelles et de substr.
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus d'expression de tableaux et de rang : l'utilisateur utilise dans chaque langage ce qui s'y trouve de plus concis et de plus puissant. C'est humain, même si parfois inévitablement cela conduit à un peu d'overkill (voir l'histoire du tailleur, de Fernand Raynaud).
Comment fais-tu pour noter ce "index direct qui n'est pas une position en caractères", et cela ne se fait-il pas au détriment de la lisibilité?
Une possibilité qui vient à l'esprit immédiatement est que ce soit un scalaire contenant un objet surchargeant l'addition. Mais ce n'est qu'un détail d'implémentation sans grande importance.
L'intérêt d'un langage est tout de même souvent de présenter une présentation unifiée entre des morceaux de programme écrits par des contributeurs différents. Si chacun doit se bricoler sa petite boite à outils dans son coin et à son idée, alors les programmes ne seront guère lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça, c'est dans tous les langages).
Nicolas George
FDA wrote in message <43aba19c$0$19609$:
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise. ???
De toute évidence tu n'as pas bien compris mon propos. Je reprends plus calmement, depuis le début.
Quand on manipule une chaîne de caractères, on ne va jamais décider « tiens, je veux les caractères 1729 à 1771 » de but-en-blanc. Ça arrive quand on manipule des tableaux (typiquement, pour des tables de hashage), mais avec des chaînes de caractères, donc quelque chose qui contient du texte, c'est exceptionnellement rare. À noter qu'il y a une différence importante entre une chaîne de caractères et un tableau d'octets, et un langage très bien conçu devrait avoir deux types bien différents pour ces deux notions.
La seule manière naturelle de manipuler une chaîne, c'est de la parcourir, en partant du début ou de la fin, à la recherche de motifs. Dans ces conditions, ce n'est pas un problème si l'accès aléatoire au n-ième caractère a une complexité en O(n), puisqu'on n'accède jamais au n-ième caractère sans avoir auparavant examiné le (n-1)-ième, le (n-2)-ième, etc.
Ce qui peut arriver, c'est qu'on souhaite accéder à un moment donné à une position dans la chaîne qu'on avait repérée beaucoup plus tôt dans le programme. Mais dans ce cas, rien ne nous oblige à noter la position repérée sous forme d'un compte de caractères depuis le début de la chaîne : au moment où on trouve la position intéressante, on a accès aux informations précises de position dans la chaîne, et on peut les stocker.
Au final, ce dont on a besoin, c'est d'un type pointeur-dans-une-chaîne, de fonctions pour obtenir le pointeur vers le début et la fin d'une chaîne, et du nécessaire pour passer au caractère suivant et au précédent. Historiquement, c'est un entier qui remplit ce rôle, mais ça n'a rien de nécessaire, et c'est une mauvaise idée en pratique, puisque ça apporte trop de rigidité.
Une telle interface a d'autres intérêts que de gérer correctement les caractères dont la représentation est de taille variable. En pariculier, elle permet de gérer des chaînes dont la représentation n'est pas contiguë en mémoire, ce qui autorise des opérations de concaténation rapide.
Les détails de l'interface dépendent de ce qu'on veut obtenir exactement. Ça va dépendre entre autres de si l'on souhaite des chaînes immuables ou pas, et de l'idiomatisme du langage. Mais au final on peut trouver quelque chose de très agréable à utiliser.
FDA wrote in message <43aba19c$0$19609$:
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus d'expression de tableaux et de rang
Quelque part, ça veut dire que l'interface des chaînes est plus puissante et mieux conçue en Perl.
L'intérêt d'un langage est tout de même souvent de présenter une présentation unifiée entre des morceaux de programme écrits par des contributeurs différents. Si chacun doit se bricoler sa petite boite à outils dans son coin et à son idée, alors les programmes ne seront guère lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça, c'est dans tous les langages).
C'est un peu oiseux, en l'occurence, puisque Perl _a_ fait un choix sur l'interface et la représentation des chaînes, choix qui me semble tout à fait sain. À vrai dire, c'est le langage dont l'API des chaîne est la mieux conçue parmi ceux que je connais.
FDA wrote in message
<43aba19c$0$19609$79c14f64@nan-newsreader-05.noos.net>:
Le principe est bon, mais l'idée de le faire avec des index numériques est
mauvaise.
???
De toute évidence tu n'as pas bien compris mon propos. Je reprends plus
calmement, depuis le début.
Quand on manipule une chaîne de caractères, on ne va jamais décider « tiens,
je veux les caractères 1729 à 1771 » de but-en-blanc. Ça arrive quand on
manipule des tableaux (typiquement, pour des tables de hashage), mais avec
des chaînes de caractères, donc quelque chose qui contient du texte, c'est
exceptionnellement rare. À noter qu'il y a une différence importante entre
une chaîne de caractères et un tableau d'octets, et un langage très bien
conçu devrait avoir deux types bien différents pour ces deux notions.
La seule manière naturelle de manipuler une chaîne, c'est de la parcourir,
en partant du début ou de la fin, à la recherche de motifs. Dans ces
conditions, ce n'est pas un problème si l'accès aléatoire au n-ième
caractère a une complexité en O(n), puisqu'on n'accède jamais au n-ième
caractère sans avoir auparavant examiné le (n-1)-ième, le (n-2)-ième, etc.
Ce qui peut arriver, c'est qu'on souhaite accéder à un moment donné à une
position dans la chaîne qu'on avait repérée beaucoup plus tôt dans le
programme. Mais dans ce cas, rien ne nous oblige à noter la position repérée
sous forme d'un compte de caractères depuis le début de la chaîne : au
moment où on trouve la position intéressante, on a accès aux informations
précises de position dans la chaîne, et on peut les stocker.
Au final, ce dont on a besoin, c'est d'un type pointeur-dans-une-chaîne, de
fonctions pour obtenir le pointeur vers le début et la fin d'une chaîne, et
du nécessaire pour passer au caractère suivant et au précédent.
Historiquement, c'est un entier qui remplit ce rôle, mais ça n'a rien de
nécessaire, et c'est une mauvaise idée en pratique, puisque ça apporte trop
de rigidité.
Une telle interface a d'autres intérêts que de gérer correctement les
caractères dont la représentation est de taille variable. En pariculier,
elle permet de gérer des chaînes dont la représentation n'est pas contiguë
en mémoire, ce qui autorise des opérations de concaténation rapide.
Les détails de l'interface dépendent de ce qu'on veut obtenir exactement. Ça
va dépendre entre autres de si l'on souhaite des chaînes immuables ou pas,
et de l'idiomatisme du langage. Mais au final on peut trouver quelque chose
de très agréable à utiliser.
FDA wrote in message
<43aba19c$0$19609$79c14f64@nan-newsreader-05.noos.net>:
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus
d'expression de tableaux et de rang
Quelque part, ça veut dire que l'interface des chaînes est plus puissante et
mieux conçue en Perl.
L'intérêt d'un langage est tout de même souvent de présenter une
présentation unifiée entre des morceaux de programme écrits par des
contributeurs différents. Si chacun doit se bricoler sa petite boite à
outils dans son coin et à son idée, alors les programmes ne seront guère
lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa
lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça,
c'est dans tous les langages).
C'est un peu oiseux, en l'occurence, puisque Perl _a_ fait un choix sur
l'interface et la représentation des chaînes, choix qui me semble tout à
fait sain. À vrai dire, c'est le langage dont l'API des chaîne est la mieux
conçue parmi ceux que je connais.
Le principe est bon, mais l'idée de le faire avec des index numériques est mauvaise. ???
De toute évidence tu n'as pas bien compris mon propos. Je reprends plus calmement, depuis le début.
Quand on manipule une chaîne de caractères, on ne va jamais décider « tiens, je veux les caractères 1729 à 1771 » de but-en-blanc. Ça arrive quand on manipule des tableaux (typiquement, pour des tables de hashage), mais avec des chaînes de caractères, donc quelque chose qui contient du texte, c'est exceptionnellement rare. À noter qu'il y a une différence importante entre une chaîne de caractères et un tableau d'octets, et un langage très bien conçu devrait avoir deux types bien différents pour ces deux notions.
La seule manière naturelle de manipuler une chaîne, c'est de la parcourir, en partant du début ou de la fin, à la recherche de motifs. Dans ces conditions, ce n'est pas un problème si l'accès aléatoire au n-ième caractère a une complexité en O(n), puisqu'on n'accède jamais au n-ième caractère sans avoir auparavant examiné le (n-1)-ième, le (n-2)-ième, etc.
Ce qui peut arriver, c'est qu'on souhaite accéder à un moment donné à une position dans la chaîne qu'on avait repérée beaucoup plus tôt dans le programme. Mais dans ce cas, rien ne nous oblige à noter la position repérée sous forme d'un compte de caractères depuis le début de la chaîne : au moment où on trouve la position intéressante, on a accès aux informations précises de position dans la chaîne, et on peut les stocker.
Au final, ce dont on a besoin, c'est d'un type pointeur-dans-une-chaîne, de fonctions pour obtenir le pointeur vers le début et la fin d'une chaîne, et du nécessaire pour passer au caractère suivant et au précédent. Historiquement, c'est un entier qui remplit ce rôle, mais ça n'a rien de nécessaire, et c'est une mauvaise idée en pratique, puisque ça apporte trop de rigidité.
Une telle interface a d'autres intérêts que de gérer correctement les caractères dont la représentation est de taille variable. En pariculier, elle permet de gérer des chaînes dont la représentation n'est pas contiguë en mémoire, ce qui autorise des opérations de concaténation rapide.
Les détails de l'interface dépendent de ce qu'on veut obtenir exactement. Ça va dépendre entre autres de si l'on souhaite des chaînes immuables ou pas, et de l'idiomatisme du langage. Mais au final on peut trouver quelque chose de très agréable à utiliser.
FDA wrote in message <43aba19c$0$19609$:
Bien sûr, de même que si l'on prend APL, on aura beaucoup plus d'expression de tableaux et de rang
Quelque part, ça veut dire que l'interface des chaînes est plus puissante et mieux conçue en Perl.
L'intérêt d'un langage est tout de même souvent de présenter une présentation unifiée entre des morceaux de programme écrits par des contributeurs différents. Si chacun doit se bricoler sa petite boite à outils dans son coin et à son idée, alors les programmes ne seront guère lisibles. C'est dommage vu que l'un des atouts de Perl est justement sa lisibilité (hormis quand on ne veut pas qu'il soit lisible, mais ça, c'est dans tous les langages).
C'est un peu oiseux, en l'occurence, puisque Perl _a_ fait un choix sur l'interface et la représentation des chaînes, choix qui me semble tout à fait sain. À vrai dire, c'est le langage dont l'API des chaîne est la mieux conçue parmi ceux que je connais.
Vincent Lefevre
Dans l'article <43ab19f1$0$16772$, FDA écrit:
substr $a, 6000, 2000
lorsqu'on passe de l'ASCII à l'UTF-8 :-(
Même en ASCII c'est inefficace.
Tu plaisantes ? Cela se traduit certainement par moins de 5 instructions assembleur ! C'est *long* , certes, mais en aucun cas *inefficace* .
Ce n'est jamais le nombre d'instructions qui est important, mais le temps qu'on y passe.
