Bonjour,
J'ai quelques petites fonctions C90, dont je souhaite réutiliser le
code source, éventuellement légèrement modifié (donc pas de mise en
bib).
Faisant largement appel à stdio.h elles sont tout sauf "idiomatiques"
en C++, mais elles sont parfaitement (hum, je l'espère en tous cas)
conformes à la norme de ce langage. Je précise que l'interface
elle-même est C plus que C++. Un exemple:
int AjouteNumLignes(const char nom_in[]
,const char nom_out[]
,const int nbr_caracts
);
Le int de retour est sémantiquement un bool.
Réécririez-vous ces fonctions en vue d'une utilisation en C++, sachant
qu'elles ont été validées par l'usage dans leur version actuelle ?
Quelle serait la raison objective de cette réécriture ?
Pour l'instant, je pense qu'il est possible de réutiliser "as is" ces
fonctions. Eventuellement en modifiant l'interface:
les chaînes sur lesquelles on utilise [] ne sont pas les chaînes qu'on copie par la suite.
Donc, il faudrait pouvoir désactiver COW pour les premières, non ?
Pourquoi ? Il se désactive forcement de lui-même au premier appel de l'opérateur [].
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Luc Hermitte wrote in message news:...
wrote in news:d6652001.0409022332.27f27110 @posting.google.com:
[Intérêt du COW]
Dans mon ésprit, c'est surtout intéressant pour les gens qui utilisent des fonctions qui renvoient des chaînes.
En l'absence de move-semantics, oui.
Ce serait alors à faire sur chaque variable et même il faudrait peut-être changer dynamiquement : string avec COW, sans COW, style rope, avec optimisation de chaînes courtes, à longueur fixe paramétrable... :-) Je me démande si on pourrait pas faire quelque chose avec des
« policies ». Je ne m'y connais pas assez pour savoir.
Andrei Alexandrescu a bossé sur des chaines cutomisables par polices -> flex_string http://www.moderncppdesign.com/code/main.html Je n'ai pas regardé en détail, mais il semble traiter les cas du COW justement.
J'en ai entendu parler. C'est une chose que je veux approfondir, si j'arrive à en trouver le temps. Parce qu'effectivement, selon l'utilisation qu'on en fait, la solution idéale varie. Parfois à l'intérieur d'un même programme. Donc, les solutions qui permettent de copier une chaîne entre plusieurs threads sont beaucoup plus chères que celle de la copie à l'intérieur d'un thread (et très peu de chaînes doivent être copiées entre threads). De même, dans mon code, au moins, les chaînes que je modifie ne sont copiées qu'une seule fois, et les chaînes que je copie ne sont pas modifiées (autrement que par l'opérateur d'affectation) -- l'implémentation optimale n'est pas la même dans les deux cas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Luc Hermitte <hermitte@free.fr.invalid> wrote in message
news:<Xns9559D027ADC6Eisyfur@127.0.0.1>...
kanze@gabi-soft.fr wrote in news:d6652001.0409022332.27f27110
@posting.google.com:
[Intérêt du COW]
Dans mon ésprit, c'est surtout intéressant pour les gens qui utilisent
des fonctions qui renvoient des chaînes.
En l'absence de move-semantics, oui.
Ce serait alors à faire sur chaque variable et même il faudrait
peut-être changer dynamiquement : string avec COW, sans COW, style
rope, avec optimisation de chaînes courtes, à longueur fixe
paramétrable... :-)
Je me démande si on pourrait pas faire quelque chose avec des
« policies ». Je ne m'y connais pas assez pour savoir.
Andrei Alexandrescu a bossé sur des chaines cutomisables par polices ->
flex_string
http://www.moderncppdesign.com/code/main.html
Je n'ai pas regardé en détail, mais il semble traiter les cas du COW
justement.
J'en ai entendu parler. C'est une chose que je veux approfondir, si
j'arrive à en trouver le temps. Parce qu'effectivement, selon
l'utilisation qu'on en fait, la solution idéale varie. Parfois à
l'intérieur d'un même programme. Donc, les solutions qui permettent de
copier une chaîne entre plusieurs threads sont beaucoup plus chères que
celle de la copie à l'intérieur d'un thread (et très peu de chaînes
doivent être copiées entre threads). De même, dans mon code, au moins,
les chaînes que je modifie ne sont copiées qu'une seule fois, et les
chaînes que je copie ne sont pas modifiées (autrement que par
l'opérateur d'affectation) -- l'implémentation optimale n'est pas la
même dans les deux cas.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
wrote in news:d6652001.0409022332.27f27110 @posting.google.com:
[Intérêt du COW]
Dans mon ésprit, c'est surtout intéressant pour les gens qui utilisent des fonctions qui renvoient des chaînes.
En l'absence de move-semantics, oui.
Ce serait alors à faire sur chaque variable et même il faudrait peut-être changer dynamiquement : string avec COW, sans COW, style rope, avec optimisation de chaînes courtes, à longueur fixe paramétrable... :-) Je me démande si on pourrait pas faire quelque chose avec des
« policies ». Je ne m'y connais pas assez pour savoir.
Andrei Alexandrescu a bossé sur des chaines cutomisables par polices -> flex_string http://www.moderncppdesign.com/code/main.html Je n'ai pas regardé en détail, mais il semble traiter les cas du COW justement.
J'en ai entendu parler. C'est une chose que je veux approfondir, si j'arrive à en trouver le temps. Parce qu'effectivement, selon l'utilisation qu'on en fait, la solution idéale varie. Parfois à l'intérieur d'un même programme. Donc, les solutions qui permettent de copier une chaîne entre plusieurs threads sont beaucoup plus chères que celle de la copie à l'intérieur d'un thread (et très peu de chaînes doivent être copiées entre threads). De même, dans mon code, au moins, les chaînes que je modifie ne sont copiées qu'une seule fois, et les chaînes que je copie ne sont pas modifiées (autrement que par l'opérateur d'affectation) -- l'implémentation optimale n'est pas la même dans les deux cas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ
On 7 Sep 2004 23:42:44 -0700, :
Donc, il faudrait pouvoir désactiver COW pour les premières, non ?
Pourquoi ?
Parce qu'à chaque appel de l'opérateur [], le test est fait, ce qui est une pessimisation (cf vector<>::[] vs vector<>::at() ).
Il se désactive forcement de lui-même au premier appel de l'opérateur [].
-- ;-)
On 7 Sep 2004 23:42:44 -0700, kanze@gabi-soft.fr:
Donc, il faudrait pouvoir désactiver COW pour les premières, non ?
Pourquoi ?
Parce qu'à chaque appel de l'opérateur [], le test est fait, ce qui
est une pessimisation (cf vector<>::[] vs vector<>::at() ).
Il se désactive forcement de lui-même au premier appel de
l'opérateur [].
