Extraire les composantes d'une expression régulière ?
22 réponses
Picard
Bonjour,
je dois faire un développement en environnement Linux pour lequel je n'ai pas le
droit d'utiliser des COTS externes à l'environnement par défaut de Suse.
J'ai trouvé comme seul librairie, regexp, qui semble tout à fait correspondre à
ce que j'attends.
Je dois parser une chaîne de caractères dont le format est du genre:
<identifiant composé de caractères quelconques y compris _>_<valeur
entière>-<valeur entière>x<valeur entière>
Mon idée est de pouvoir extraire chaque entité défini entre <>.
Pour cela, j'ai écrit le code décrit ci-dessous.
Je me trouve confronté à différents problèmes:
- si j'utilise l__pattern tel que défini, cela ne matche pas un fichier de nom
"PF_toto_0-320x245.tutu.tata"
- si j'utilise l__pattern="([:alnum:_]+)-", cela matche: il m'affiche la chaîne
"PF_toto_0-" alors que j'attendais seulement "PF_toto_0".
Serait-il possible de m'expliquer pourquoi mon code ne fonctionne pas, s'il vous
plaît ?
Si l'explication est un peu longue, je suis prêt à accepter uniquement le bout
de code qui va bien ;-)
Ma contrainte est d'utiliser des expressions régulières car je souhaite en
comprendre le mécanisme. Je ne suis donc pas intéressé par une solution à base
de strtok.
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > <rant> | > | > Mon impression générale est que TR1 est essentiellement (à l'exception | > | > de regex), un truc fait pour écrivain spécialiste de bibliothèque. | > | | > | Tu exageres un petit peu. smart_ptr, unordered_map, meme array sont | > | d'utilisation plus large que ca. | > | > J'accepte très volontiers unordered_map -- c'était plus un oubli qu'un | > désir de l'écarter. | > | > smart_ptr est très limite pour une autre raison : j'ai vu beaucoup de | > gens l'utiliser sans réfléchir et sans tenir compte des performances | > réellement. En Avril 2004, j'ai assisté à un exposé de Hans Boehm où | > il comparait les performances de smart_ptr, de son GC et d'une autre | > technique dans plusieurs applications. | | La quelle? Est-ce que c'est sur son site? | | (J'ai des objets avec comptages de reference, mais interne d'une part, | et je ne suis pas en multithread d'autre part).
Il s'agissait essentiellement de shared_ptr<> -- et c'était un exposé « invité » chez Adobe. Je ne sais pas s'il a mis les slides sur son site.
Une des raisons de l'inefficacité réside dans la perte de localité de référence, en plus d'une pessimisation induite par bon de ABI -- shared_ptr<> pourrait être passé dans un registre, mais typiquement il ne l'est pas.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| >
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > |
| > | > <rant>
| > | > Mon impression générale est que TR1 est essentiellement (à l'exception
| > | > de regex), un truc fait pour écrivain spécialiste de bibliothèque.
| > |
| > | Tu exageres un petit peu. smart_ptr, unordered_map, meme array sont
| > | d'utilisation plus large que ca.
| >
| > J'accepte très volontiers unordered_map -- c'était plus un oubli qu'un
| > désir de l'écarter.
| >
| > smart_ptr est très limite pour une autre raison : j'ai vu beaucoup de
| > gens l'utiliser sans réfléchir et sans tenir compte des performances
| > réellement. En Avril 2004, j'ai assisté à un exposé de Hans Boehm où
| > il comparait les performances de smart_ptr, de son GC et d'une autre
| > technique dans plusieurs applications.
|
| La quelle? Est-ce que c'est sur son site?
|
| (J'ai des objets avec comptages de reference, mais interne d'une part,
| et je ne suis pas en multithread d'autre part).
Il s'agissait essentiellement de shared_ptr<> -- et c'était un exposé
« invité » chez Adobe. Je ne sais pas s'il a mis les slides sur son
site.
Une des raisons de l'inefficacité réside dans la perte de localité de
référence, en plus d'une pessimisation induite par bon de ABI --
shared_ptr<> pourrait être passé dans un registre, mais typiquement il
ne l'est pas.
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > <rant> | > | > Mon impression générale est que TR1 est essentiellement (à l'exception | > | > de regex), un truc fait pour écrivain spécialiste de bibliothèque. | > | | > | Tu exageres un petit peu. smart_ptr, unordered_map, meme array sont | > | d'utilisation plus large que ca. | > | > J'accepte très volontiers unordered_map -- c'était plus un oubli qu'un | > désir de l'écarter. | > | > smart_ptr est très limite pour une autre raison : j'ai vu beaucoup de | > gens l'utiliser sans réfléchir et sans tenir compte des performances | > réellement. En Avril 2004, j'ai assisté à un exposé de Hans Boehm où | > il comparait les performances de smart_ptr, de son GC et d'une autre | > technique dans plusieurs applications. | | La quelle? Est-ce que c'est sur son site? | | (J'ai des objets avec comptages de reference, mais interne d'une part, | et je ne suis pas en multithread d'autre part).
Il s'agissait essentiellement de shared_ptr<> -- et c'était un exposé « invité » chez Adobe. Je ne sais pas s'il a mis les slides sur son site.
Une des raisons de l'inefficacité réside dans la perte de localité de référence, en plus d'une pessimisation induite par bon de ABI -- shared_ptr<> pourrait être passé dans un registre, mais typiquement il ne l'est pas.
-- Gaby
kanze
Gabriel Dos Reis wrote:
[...]
Il s'agissait essentiellement de shared_ptr<> -- et c'était un exposé « invité » chez Adobe. Je ne sais pas s'il a mis les slides sur son site.
Une des raisons de l'inefficacité réside dans la perte de localité de référence, en plus d'une pessimisation induite par bon de ABI -- shared_ptr<> pourrait être passé dans un registre, mais typiquement il ne l'est pas.
Si shared_ptr<> a encore l'implémentation que je connaissais, il ne passe pas dans un registre sur les machines que je connais ; dans le temps, au moins, il comportait deux pointeurs. (N'oublie pas non plus qu'il a un constructeur de copie défini par utlisateur. Ce qui suffit pour bloquer le passage par registre dans certains compilateurs, je crois.)
Comme Jean-Marc, j'ai mon propre pointeur à comptage de références, que j'ai trouvé bien utile dans certains cas. Mais il faut dire que :
-- C'est invasif. Du coup, il ne peut désigner que des objets qui dérive de RefCntObj. En revanche, sizeof(RefCntPtr) == sizeof(T*), et RefCntPtr( this ) marche sans précautions particulières. (Si on cherche un succédané au glaneurs de cellules, c'est deux propriétés sont à mon avis essentiel.)
-- Il n'est pas thread-safe. Il ne peut donc servir que si tous les pointeurs à un même objet sont dans un seul thread. C'était dans ma liste TODO de le rendre thread-safe, mais j'ai découvert le collecteur de Boehm avant d'y arriver, et ça me semble inutile depuis.
-- Et surtout, mais vraiment surtout, je l'ai trouvé bien utile DANS CERTAINS CAS. Ce n'est pas une panacée, qui permet à résoudre tous les problèmes de la gestion de la durée de vie.
En attendant, j'ai expérimenté avec shared_ptr. (Je ne peux pas trop m'en servir dans des applications réeles, parce qu'il faut encore supporter des versions assez anciennes de Sun CC, ce que n'aime pas Boost.) Il en a des utilisations, surtout avec un « deleter » qui fait autre chose que delete, mais je ne suis pas convaincu qu'il en a assez pour en justifier la normalisation. il fait simplement partie d'une panoplie de pointeurs intelligents qui sont utiles dans des cas bien précis. En tant qu'exemple de l'utilisation d'un modèle de conception, c'est bien, mais je ne crois pas qu'on veut forcement des exemples de tous les modèles de conception dans la bibliothèque standard.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
[...]
Il s'agissait essentiellement de shared_ptr<> -- et c'était un
exposé « invité » chez Adobe. Je ne sais pas s'il a mis les
slides sur son site.
Une des raisons de l'inefficacité réside dans la perte de
localité de référence, en plus d'une pessimisation induite par
bon de ABI -- shared_ptr<> pourrait être passé dans un
registre, mais typiquement il ne l'est pas.
Si shared_ptr<> a encore l'implémentation que je connaissais, il
ne passe pas dans un registre sur les machines que je connais ;
dans le temps, au moins, il comportait deux pointeurs. (N'oublie
pas non plus qu'il a un constructeur de copie défini par
utlisateur. Ce qui suffit pour bloquer le passage par registre
dans certains compilateurs, je crois.)
Comme Jean-Marc, j'ai mon propre pointeur à comptage de
références, que j'ai trouvé bien utile dans certains cas. Mais
il faut dire que :
-- C'est invasif. Du coup, il ne peut désigner que des objets
qui dérive de RefCntObj. En revanche, sizeof(RefCntPtr) ==
sizeof(T*), et RefCntPtr( this ) marche sans précautions
particulières. (Si on cherche un succédané au glaneurs de
cellules, c'est deux propriétés sont à mon avis essentiel.)
-- Il n'est pas thread-safe. Il ne peut donc servir que si tous
les pointeurs à un même objet sont dans un seul thread.
C'était dans ma liste TODO de le rendre thread-safe, mais
j'ai découvert le collecteur de Boehm avant d'y arriver, et
ça me semble inutile depuis.
-- Et surtout, mais vraiment surtout, je l'ai trouvé bien utile
DANS CERTAINS CAS. Ce n'est pas une panacée, qui permet à
résoudre tous les problèmes de la gestion de la durée de
vie.
En attendant, j'ai expérimenté avec shared_ptr. (Je ne peux pas
trop m'en servir dans des applications réeles, parce qu'il faut
encore supporter des versions assez anciennes de Sun CC, ce que
n'aime pas Boost.) Il en a des utilisations, surtout avec un
« deleter » qui fait autre chose que delete, mais je ne suis pas
convaincu qu'il en a assez pour en justifier la normalisation.
il fait simplement partie d'une panoplie de pointeurs
intelligents qui sont utiles dans des cas bien précis. En tant
qu'exemple de l'utilisation d'un modèle de conception, c'est
bien, mais je ne crois pas qu'on veut forcement des exemples de
tous les modèles de conception dans la bibliothèque standard.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Il s'agissait essentiellement de shared_ptr<> -- et c'était un exposé « invité » chez Adobe. Je ne sais pas s'il a mis les slides sur son site.
Une des raisons de l'inefficacité réside dans la perte de localité de référence, en plus d'une pessimisation induite par bon de ABI -- shared_ptr<> pourrait être passé dans un registre, mais typiquement il ne l'est pas.
Si shared_ptr<> a encore l'implémentation que je connaissais, il ne passe pas dans un registre sur les machines que je connais ; dans le temps, au moins, il comportait deux pointeurs. (N'oublie pas non plus qu'il a un constructeur de copie défini par utlisateur. Ce qui suffit pour bloquer le passage par registre dans certains compilateurs, je crois.)
Comme Jean-Marc, j'ai mon propre pointeur à comptage de références, que j'ai trouvé bien utile dans certains cas. Mais il faut dire que :
-- C'est invasif. Du coup, il ne peut désigner que des objets qui dérive de RefCntObj. En revanche, sizeof(RefCntPtr) == sizeof(T*), et RefCntPtr( this ) marche sans précautions particulières. (Si on cherche un succédané au glaneurs de cellules, c'est deux propriétés sont à mon avis essentiel.)
-- Il n'est pas thread-safe. Il ne peut donc servir que si tous les pointeurs à un même objet sont dans un seul thread. C'était dans ma liste TODO de le rendre thread-safe, mais j'ai découvert le collecteur de Boehm avant d'y arriver, et ça me semble inutile depuis.
-- Et surtout, mais vraiment surtout, je l'ai trouvé bien utile DANS CERTAINS CAS. Ce n'est pas une panacée, qui permet à résoudre tous les problèmes de la gestion de la durée de vie.
En attendant, j'ai expérimenté avec shared_ptr. (Je ne peux pas trop m'en servir dans des applications réeles, parce qu'il faut encore supporter des versions assez anciennes de Sun CC, ce que n'aime pas Boost.) Il en a des utilisations, surtout avec un « deleter » qui fait autre chose que delete, mais je ne suis pas convaincu qu'il en a assez pour en justifier la normalisation. il fait simplement partie d'une panoplie de pointeurs intelligents qui sont utiles dans des cas bien précis. En tant qu'exemple de l'utilisation d'un modèle de conception, c'est bien, mais je ne crois pas qu'on veut forcement des exemples de tous les modèles de conception dans la bibliothèque standard.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
