Qu'en pensez vous ?
Qu'en pensez vous ?
Qu'en pensez vous ?
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ writes:
>
>> Qu'en pensez vous ?
> Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
> l'utilisation des membres xalloc(), iword(), pword() et register_callback()
> de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
> pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ <michael.doubez@free.fr> writes:
>
>> Qu'en pensez vous ?
> Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
> l'utilisation des membres xalloc(), iword(), pword() et register_callback()
> de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
> pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ writes:
>
>> Qu'en pensez vous ?
> Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
> l'utilisation des membres xalloc(), iword(), pword() et register_callback()
> de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
> pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Michael DOUBEZ <michael.doubez@free.fr> writes:
Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Michael DOUBEZ writes:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Mon probleme c'est que tu as l'air de vouloir:
cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>
Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << b
- en jouant aussi avec les streambufs.
Michael DOUBEZ <michael.doubez@free.fr> writes:
Jean-Marc Bourguet a écrit :
Michael DOUBEZ <michael.doubez@free.fr> writes:
Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Mon probleme c'est que tu as l'air de vouloir:
cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>
Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << b
- en jouant aussi avec les streambufs.
Michael DOUBEZ writes:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question. As-tu envisage
l'utilisation des membres xalloc(), iword(), pword() et register_callback()
de ios_base? Si non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as rejete et
pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la structure de stockage
des stream. Je pourrais marquer les tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation rende équivalent
d'écrire cout<<b<<"data" ou cout<<"<b>"<<"data"<<<"</b>".
Le RAII du XML en quelque sorte.
Mon probleme c'est que tu as l'air de vouloir:
cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>
Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << b
- en jouant aussi avec les streambufs.
J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ writes:
>> Jean-Marc Bourguet a écrit :
>>> Michael DOUBEZ writes:
>>>> Qu'en pensez vous ?
>>> Il faudra le temps d'y repenser, mais j'ai une question.
>>> As-tu envisage l'utilisation des membres xalloc(),
>>> iword(), pword() et register_callback() de ios_base? Si
>>> non, c'est peut-etre une piste, si oui, pourquoi n'en
>>> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
>>> rejete et pourquoi.
>> Effectivement, je n'ai pas considéré d'utiliser la
>> structure de stockage des stream. Je pourrais marquer les
>> tags en attente.
>> Ce que j'aimerais c'est une solution qui à la compilation
>> rende équivalent d'écrire cout<<b<<"data" ou
>> cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
>> sorte.
> Mon probleme c'est que tu as l'air de vouloir:
> cout << b; donnant <b/>
> et
> cout << b << "data"; donnant <b>data</b>
> Ca ne me semble possible que de deux manieres:
> - en changeant le type de cout << b
C'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.
Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.
> - en jouant aussi avec les streambufs.
C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ <michael.dou...@free.fr> writes:
>> Jean-Marc Bourguet a écrit :
>>> Michael DOUBEZ <michael.dou...@free.fr> writes:
>>>> Qu'en pensez vous ?
>>> Il faudra le temps d'y repenser, mais j'ai une question.
>>> As-tu envisage l'utilisation des membres xalloc(),
>>> iword(), pword() et register_callback() de ios_base? Si
>>> non, c'est peut-etre une piste, si oui, pourquoi n'en
>>> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
>>> rejete et pourquoi.
>> Effectivement, je n'ai pas considéré d'utiliser la
>> structure de stockage des stream. Je pourrais marquer les
>> tags en attente.
>> Ce que j'aimerais c'est une solution qui à la compilation
>> rende équivalent d'écrire cout<<b<<"data" ou
>> cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
>> sorte.
> Mon probleme c'est que tu as l'air de vouloir:
> cout << b; donnant <b/>
> et
> cout << b << "data"; donnant <b>data</b>
> Ca ne me semble possible que de deux manieres:
> - en changeant le type de cout << b
C'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.
Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.
> - en jouant aussi avec les streambufs.
C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
Jean-Marc Bourguet a écrit :
> Michael DOUBEZ writes:
>> Jean-Marc Bourguet a écrit :
>>> Michael DOUBEZ writes:
>>>> Qu'en pensez vous ?
>>> Il faudra le temps d'y repenser, mais j'ai une question.
>>> As-tu envisage l'utilisation des membres xalloc(),
>>> iword(), pword() et register_callback() de ios_base? Si
>>> non, c'est peut-etre une piste, si oui, pourquoi n'en
>>> parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
>>> rejete et pourquoi.
>> Effectivement, je n'ai pas considéré d'utiliser la
>> structure de stockage des stream. Je pourrais marquer les
>> tags en attente.
>> Ce que j'aimerais c'est une solution qui à la compilation
>> rende équivalent d'écrire cout<<b<<"data" ou
>> cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
>> sorte.
> Mon probleme c'est que tu as l'air de vouloir:
> cout << b; donnant <b/>
> et
> cout << b << "data"; donnant <b>data</b>
> Ca ne me semble possible que de deux manieres:
> - en changeant le type de cout << b
C'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.
Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.
> - en jouant aussi avec les streambufs.
C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
On 2008-12-01, Michael DOUBEZ wrote:J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
On 2008-12-01, Michael DOUBEZ <michael.doubez@free.fr> wrote:
J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
On 2008-12-01, Michael DOUBEZ wrote:J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
On Dec 1, 12:10 pm, Michael DOUBEZ wrote:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question.
As-tu envisage l'utilisation des membres xalloc(),
iword(), pword() et register_callback() de ios_base? Si
non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
rejete et pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la
structure de stockage des stream. Je pourrais marquer les
tags en attente.Ce que j'aimerais c'est une solution qui à la compilation
rende équivalent d'écrire cout<<b<<"data" ou
cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
sorte.Mon probleme c'est que tu as l'air de vouloir:cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << bC'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.- en jouant aussi avec les streambufs.C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
L'un n'exclut pas l'autre ; les types pourraient être des
espèces d'OutputStreamWrapper, qui insèrent et enlève le
streambuf filtrant.
Méfie-toi quand même de l'ordre de destruction. C'est l'inverse
de l'ordre de construction, non de l'ordre d'invocation des <<.
Si les temporaires qui t'intéressent apparaissent tous comme
valeurs de retour des <<, il ne doit pas y avoir des problèmes,
mais sinon...
On Dec 1, 12:10 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Jean-Marc Bourguet a écrit :
Michael DOUBEZ <michael.dou...@free.fr> writes:
Jean-Marc Bourguet a écrit :
Michael DOUBEZ <michael.dou...@free.fr> writes:
Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question.
As-tu envisage l'utilisation des membres xalloc(),
iword(), pword() et register_callback() de ios_base? Si
non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
rejete et pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la
structure de stockage des stream. Je pourrais marquer les
tags en attente.
Ce que j'aimerais c'est une solution qui à la compilation
rende équivalent d'écrire cout<<b<<"data" ou
cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
sorte.
Mon probleme c'est que tu as l'air de vouloir:
cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>
Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << b
C'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.
Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.
- en jouant aussi avec les streambufs.
C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
L'un n'exclut pas l'autre ; les types pourraient être des
espèces d'OutputStreamWrapper, qui insèrent et enlève le
streambuf filtrant.
Méfie-toi quand même de l'ordre de destruction. C'est l'inverse
de l'ordre de construction, non de l'ordre d'invocation des <<.
Si les temporaires qui t'intéressent apparaissent tous comme
valeurs de retour des <<, il ne doit pas y avoir des problèmes,
mais sinon...
On Dec 1, 12:10 pm, Michael DOUBEZ wrote:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Jean-Marc Bourguet a écrit :Michael DOUBEZ writes:Qu'en pensez vous ?
Il faudra le temps d'y repenser, mais j'ai une question.
As-tu envisage l'utilisation des membres xalloc(),
iword(), pword() et register_callback() de ios_base? Si
non, c'est peut-etre une piste, si oui, pourquoi n'en
parles-tu pas -- ne fut-ce que pour indiquer que tu l'as
rejete et pourquoi.
Effectivement, je n'ai pas considéré d'utiliser la
structure de stockage des stream. Je pourrais marquer les
tags en attente.Ce que j'aimerais c'est une solution qui à la compilation
rende équivalent d'écrire cout<<b<<"data" ou
cout<<"<b>"<<"data"<<<"</b>". Le RAII du XML en quelque
sorte.Mon probleme c'est que tu as l'air de vouloir:cout << b; donnant <b/>
et
cout << b << "data"; donnant <b>data</b>Ca ne me semble possible que de deux manieres:
- en changeant le type de cout << bC'est la solution que j'ai choisie. En fait, les tags
possèdent des traits qui sont utilisés dans une machine d'état
à la compilation. Parmi ces traits et policies il y a si le
tag:
* peut posséder des attributs et lesquels
* peut avoir des données (données brutes, tags et lesquels)
et autres joyeusetés.Ainsi si j'essaye de faire:
cout<<html<<h1<<"Titre";
J'aurai une erreur à la compilation car html ne supporte que
header, body, frameset.- en jouant aussi avec les streambufs.C'est une solution. Par exemple en utilisant les
filtres/inserters de streambuf de James Kanze. Mais à ce
moment là, la vérification des contraintes se fait au runtime
et je perd l'avantage de la décoration des streams.
L'un n'exclut pas l'autre ; les types pourraient être des
espèces d'OutputStreamWrapper, qui insèrent et enlève le
streambuf filtrant.
Méfie-toi quand même de l'ordre de destruction. C'est l'inverse
de l'ordre de construction, non de l'ordre d'invocation des <<.
Si les temporaires qui t'intéressent apparaissent tous comme
valeurs de retour des <<, il ne doit pas y avoir des problèmes,
mais sinon...
Marc Boyer a écrit :On 2008-12-01, Michael DOUBEZ wrote:J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
Pas exactement, je suis content avec l'associativité à droite puisque je
décore de gauche à droite html<<head<<body ....
Mais ça résume très bien le problème pour scope: ce serait effectivement
une associativité à gauche:
cout<<scoped<<html -> scoped(cout)(html<<...)
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Je suis d'accord avec toi, les expression template sont idéales pour
inverser l'ordre puisque je pourrai avoir une évaluation différée du
membre à droite de scoped.
Dans ce cas, je passerais tout en expression template plutôt que mon
système actuel d'état de stream. C'est juste que les ET ont tendance à
générer des ligne de debug assez conséquentes.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
Merci. En écrivant ma réponse, je me demande si mon argument du debugage
n'est pas un peu faible.
Je ne suis pas sûr que ce soit si trivial et intuitif de différer
l'écriture des données dans la stream.
Marc Boyer a écrit :
On 2008-12-01, Michael DOUBEZ <michael.doubez@free.fr> wrote:
J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
Pas exactement, je suis content avec l'associativité à droite puisque je
décore de gauche à droite html<<head<<body ....
Mais ça résume très bien le problème pour scope: ce serait effectivement
une associativité à gauche:
cout<<scoped<<html -> scoped(cout)(html<<...)
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Je suis d'accord avec toi, les expression template sont idéales pour
inverser l'ordre puisque je pourrai avoir une évaluation différée du
membre à droite de scoped.
Dans ce cas, je passerais tout en expression template plutôt que mon
système actuel d'état de stream. C'est juste que les ET ont tendance à
générer des ligne de debug assez conséquentes.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
Merci. En écrivant ma réponse, je me demande si mon argument du debugage
n'est pas un peu faible.
Je ne suis pas sûr que ce soit si trivial et intuitif de différer
l'écriture des données dans la stream.
Marc Boyer a écrit :On 2008-12-01, Michael DOUBEZ wrote:J'ai envisagé:
- les expression template mais ça me parait
beaucoup de complication pour si peu et le
debugage devient impossible
- une locale transmise de bout en bout mais alors
mes tstream doivent avoir un parent commun et
j'ai toujours un état runtime à mettre à jour dans la locale
- demander à fermer la stream par un appel qui ferme
tous les tag mais c'est lourd pour des cas aussi simple que
std::cout<<"Data"<<br<<endt;
Qu'en pensez vous ?
J'en pense que tu as un opérateur associatif a gauche auquel
tu veux donner une sémantique associative à droite, et que
c'est pas facile.
cout<<x<<y vaut operator<<( operator<<(cout,x), y )
alors que tu aimerais
printhtml( x , printhtml( y ) )
Pas exactement, je suis content avec l'associativité à droite puisque je
décore de gauche à droite html<<head<<body ....
Mais ça résume très bien le problème pour scope: ce serait effectivement
une associativité à gauche:
cout<<scoped<<html -> scoped(cout)(html<<...)
ce qui implique de passer par une pile, en jouant
sur les contructeurs/destructeurs.
En plus, tu ne veux pas d'état au runtime, ce qui impose
de gérer la pile à la compilation, mais tu ne veux pas de template,
alors que ça me semble l'outil le plus riche pour résoudre des
trucs compliqués (comme une pile) à la compilation.
Je suis d'accord avec toi, les expression template sont idéales pour
inverser l'ordre puisque je pourrai avoir une évaluation différée du
membre à droite de scoped.
Dans ce cas, je passerais tout en expression template plutôt que mon
système actuel d'état de stream. C'est juste que les ET ont tendance à
générer des ligne de debug assez conséquentes.
Voilà ma maigre contrib (après avoir passé un peu de temps
à tenter de faire une solution template).
Merci. En écrivant ma réponse, je me demande si mon argument du debugage
n'est pas un peu faible.
Je ne suis pas sûr que ce soit si trivial et intuitif de différer
l'écriture des données dans la stream.