J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)
Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Donc, avez vous une solution assez elegante ?
Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)
Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Donc, avez vous une solution assez elegante ?
Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)
Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Donc, avez vous une solution assez elegante ?
Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
"amerio" wrote in message
news:<fgflb.69950$...J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Tout à fait.Donc, avez vous une solution assez elegante ?
J'en ai plusieurs, mais d'abord, il faut que je sache le problème.Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
C'est le moindre des problèmes : à quoi sert les templates, après tout.
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
--
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
"amerio" <amerio@hotmail.com> wrote in message
news:<fgflb.69950$bU3.886142@news.chello.at>...
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)
Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Tout à fait.
Donc, avez vous une solution assez elegante ?
J'en ai plusieurs, mais d'abord, il faut que je sache le problème.
Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
C'est le moindre des problèmes : à quoi sert les templates, après tout.
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
--
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
"amerio" wrote in message
news:<fgflb.69950$...J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.donc je peux faire :
myostream out;
out << manip(1);
et manip(1) manipule un membre privé de myostream (c'est un friend)Mon probleme :
out << manip(1); marche tres bien
out << manip(1) << "toto"; marche aussi
out << "toto" << manip(1); ne compile meme pas car operator<<(string&) renvoie un
ostream& de base, et manip attend un myostream&.
Tout à fait.Donc, avez vous une solution assez elegante ?
J'en ai plusieurs, mais d'abord, il faut que je sache le problème.Je ne peux bien sur pas reecrire tous les operator<< pour les types de
base, car je veux que myostream accepte aussi les types utilisateurs
(c'est qd meme le but des stream !)
C'est le moindre des problèmes : à quoi sert les templates, après tout.
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
--
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
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec paramètre, c'est tout.
[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec paramètre, c'est tout.
[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
J'ai un ostream surchargé, avec des manipulateurs maison spécifiques.
En simplifiant :
myostream derive publiquement de std::basic_ostream<...>
et manip est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
En général, la seule raison d'hériter de ostream, c'est de fournir les
constructeurs de commodité qui utilisent un streambuf propre. Sur le
modèle de ofstream ou de ostringstream, par exemple.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique en
fait à tous les flux, ou bien, il lui faut un streambuf particulier.
Sans savoir lequel, c'est impossible à donner une bonne solution.
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec paramètre, c'est tout.
[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres privés,
est prèsque toujours une errur. Mais sans connaître le problème que tu
essaies de résoudre de cette façon, c'est impossible à te dire ce que tu
dois faire à la place.
J'ai un ostream surchargé, avec des manipulateurs maison
spécifiques. En simplifiant :
myostream derive publiquement de std::basic_ostream<...> et manip
est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
Mon stream implemente un streambuf spécialisé, et doit gerer une stack
de propriété (états).En général, la seule raison d'hériter de ostream, c'est de fournir
les constructeurs de commodité qui utilisent un streambuf propre.
Sur le modèle de ofstream ou de ostringstream, par exemple.
Exactement.Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique
en fait à tous les flux, ou bien, il lui faut un streambuf
particulier. Sans savoir lequel, c'est impossible à donner une bonne
solution.
Mon manipulateur ne peut pas s'appliquer à un stream générique. Son
but est de modifier plusieus états spécifiques du flux. Je donner un
exempel après.je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec
paramètre, c'est tout. Il ne dérive pas de nouveau stream.[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres
privés, est prèsque toujours une errur. Mais sans connaître le
problème que tu essaies de résoudre de cette façon, c'est impossible
à te dire ce que tu dois faire à la place.
Ok, partons du problème initial alors.
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) << "bleu" << pop
<< "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
J'ai un ostream surchargé, avec des manipulateurs maison
spécifiques. En simplifiant :
myostream derive publiquement de std::basic_ostream<...> et manip
est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
Mon stream implemente un streambuf spécialisé, et doit gerer une stack
de propriété (états).
En général, la seule raison d'hériter de ostream, c'est de fournir
les constructeurs de commodité qui utilisent un streambuf propre.
Sur le modèle de ofstream ou de ostringstream, par exemple.
Exactement.
Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique
en fait à tous les flux, ou bien, il lui faut un streambuf
particulier. Sans savoir lequel, c'est impossible à donner une bonne
solution.
Mon manipulateur ne peut pas s'appliquer à un stream générique. Son
but est de modifier plusieus états spécifiques du flux. Je donner un
exempel après.
je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec
paramètre, c'est tout. Il ne dérive pas de nouveau stream.
[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres
privés, est prèsque toujours une errur. Mais sans connaître le
problème que tu essaies de résoudre de cette façon, c'est impossible
à te dire ce que tu dois faire à la place.
Ok, partons du problème initial alors.
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) << "bleu" << pop
<< "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
J'ai un ostream surchargé, avec des manipulateurs maison
spécifiques. En simplifiant :
myostream derive publiquement de std::basic_ostream<...> et manip
est un manipulateur à paramétre pour un myostream
Pourquoi faire ? Qu'est-ce que ton flux fait différemment de ostream ?
Mon stream implemente un streambuf spécialisé, et doit gerer une stack
de propriété (états).En général, la seule raison d'hériter de ostream, c'est de fournir
les constructeurs de commodité qui utilisent un streambuf propre.
Sur le modèle de ofstream ou de ostringstream, par exemple.
Exactement.Du coup, ou bien, ton manipulateur fait quelque chose qui s'applique
en fait à tous les flux, ou bien, il lui faut un streambuf
particulier. Sans savoir lequel, c'est impossible à donner une bonne
solution.
Mon manipulateur ne peut pas s'appliquer à un stream générique. Son
but est de modifier plusieus états spécifiques du flux. Je donner un
exempel après.je me suis inspiré de ca :
http://www.two-sdg.demon.co.uk/curbralan/papers/WritingStreamManipulators.html
Ça m'étonne qu'il les crée pour un type dérivé de ostream seulement.
Non, il donne juste un exemple de création de manipulateur avec
paramètre, c'est tout. Il ne dérive pas de nouveau stream.[...]
Dériver d'un ostream, comme tu as fait, en ajoutant des membres
privés, est prèsque toujours une errur. Mais sans connaître le
problème que tu essaies de résoudre de cette façon, c'est impossible
à te dire ce que tu dois faire à la place.
Ok, partons du problème initial alors.
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) << "bleu" << pop
<< "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Dans ce cas, je réimplémenterais effectivement tous les opérateurs <<,
mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Avec l'appartenance, et non l'héritage, et une fonction template, sans
doute avec pas mal de fonctions non template (pour tout les types
speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes manipulateurs
ne marche que sur des MyStream, jamais sur d'autres types de flux.
Si tu veux appeler une fonction existante qui insère quelque chose dans
le flux, tu appelles la fonction avec myStream.stream().
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Dans ce cas, je réimplémenterais effectivement tous les opérateurs <<,
mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Avec l'appartenance, et non l'héritage, et une fonction template, sans
doute avec pas mal de fonctions non template (pour tout les types
speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes manipulateurs
ne marche que sur des MyStream, jamais sur d'autres types de flux.
Si tu veux appeler une fonction existante qui insère quelque chose dans
le flux, tu appelles la fonction avec myStream.stream().
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux que
ces attributs soit maintenus dans une pile. Pour donner un exemple je
veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les bons
attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Dans ce cas, je réimplémenterais effectivement tous les opérateurs <<,
mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Avec l'appartenance, et non l'héritage, et une fonction template, sans
doute avec pas mal de fonctions non template (pour tout les types
speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes manipulateurs
ne marche que sur des MyStream, jamais sur d'autres types de flux.
Si tu veux appeler une fonction existante qui insère quelque chose dans
le flux, tu appelles la fonction avec myStream.stream().
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux
que ces attributs soit maintenus dans une pile. Pour donner un
exemple je veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les
bons attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Dans ce cas, je réimplémenterais effectivement tous les
opérateurs <<, mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Manque return dest; je pense
Mais je vois le principe ;-)
Avec l'appartenance, et non l'héritage, et une fonction template,
sans doute avec pas mal de fonctions non template (pour tout les
types speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes
manipulateurs ne marche que sur des MyStream, jamais sur d'autres
types de flux.
Oui, c'est bien ce qui m'interessent, car une verification en runtime
avec dynamic_cast me gene (moins beau)
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux
que ces attributs soit maintenus dans une pile. Pour donner un
exemple je veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les
bons attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Dans ce cas, je réimplémenterais effectivement tous les
opérateurs <<, mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Manque return dest; je pense
Mais je vois le principe ;-)
Avec l'appartenance, et non l'héritage, et une fonction template,
sans doute avec pas mal de fonctions non template (pour tout les
types speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes
manipulateurs ne marche que sur des MyStream, jamais sur d'autres
types de flux.
Oui, c'est bien ce qui m'interessent, car une verification en runtime
avec dynamic_cast me gene (moins beau)
Je veux implémenter un stream gérant des attributs supplémentaires
(couleur, taille de police, position du curseur, etc.) et je veux
que ces attributs soit maintenus dans une pile. Pour donner un
exemple je veux pouvoir faire :
output << "hello" << color(255,0,0) << "rouge" << push << color(0,0,255) <<
"bleu" << pop << "rouge" << render;
output << "hello" << size(10) << "petit" << size(20) << "gros" << render;
etc...
Le dernier manip "render" effectuant un rendu du buffer avec les
bons attributs. Je suis ouvert à toute idée :-)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Dans ce cas, je réimplémenterais effectivement tous les
opérateurs <<, mais avec des templates, donc :
class MyStream
{
public :
MyStream( std::ostream& dest ) : myDest( dest ) {}
std::ostream& stream() { return myDest }
private :
std::ostream myDest ;
} ;
template< typename T >
MyStream&
operator<<( MyStream& dest, T const& value )
{
dest.stream() << value ;
}
Manque return dest; je pense
Mais je vois le principe ;-)
Avec l'appartenance, et non l'héritage, et une fonction template,
sans doute avec pas mal de fonctions non template (pour tout les
types speciaux qui t'interessent) en surcharge.
L'avantage, par rapport à d'autres solutions, c'est qu'il y a des
vérifications des types au moment de la compilation -- tes
manipulateurs ne marche que sur des MyStream, jamais sur d'autres
types de flux.
Oui, c'est bien ce qui m'interessent, car une verification en runtime
avec dynamic_cast me gene (moins beau)
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Surtout parce que je n'avait pas régardé en détail, et qu'effectivement,
la nécessité d'une commande « render » provoque des doutes. Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
Même ici, je ne suis pas tout à fait sûr. Quand on considère du texte
formatté, disons comme fait un outil comme TeX, il ne s'agit pas autant
d'une flux, que d'une suite de flux, rassemblés d'une façon
hièrarchique, parfois verticalement, parfois horizontalement. Je n'ai
jamais fait une telle application -- je ne peux donc pas dire ce que je
ferais réelement. Disons que si je n'exclus pas pour l'instance
l'utilisation d'un flux, je ne le vois pas comme allant de soi non plus.
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas surcharger
sync dans ton streambuf pour faire la rendition (et l'appeler dans le
destructeur). Parce qu'en fin de compte, la rendition, c'est bien une
synchronisation du support réel avec le flux, non ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute dans
ta conception.)
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma site. Il
s'occupe du formattage en se servant des operator<< existant, mais sans
considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et bien
embriquées dans le texte, je crois qu'effectivement l'idiome de flux
pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes flux
soient échangeable avec un ostream.
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Surtout parce que je n'avait pas régardé en détail, et qu'effectivement,
la nécessité d'une commande « render » provoque des doutes. Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
Même ici, je ne suis pas tout à fait sûr. Quand on considère du texte
formatté, disons comme fait un outil comme TeX, il ne s'agit pas autant
d'une flux, que d'une suite de flux, rassemblés d'une façon
hièrarchique, parfois verticalement, parfois horizontalement. Je n'ai
jamais fait une telle application -- je ne peux donc pas dire ce que je
ferais réelement. Disons que si je n'exclus pas pour l'instance
l'utilisation d'un flux, je ne le vois pas comme allant de soi non plus.
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas surcharger
sync dans ton streambuf pour faire la rendition (et l'appeler dans le
destructeur). Parce qu'en fin de compte, la rendition, c'est bien une
synchronisation du support réel avec le flux, non ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute dans
ta conception.)
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.
Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma site. Il
s'occupe du formattage en se servant des operator<< existant, mais sans
considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et bien
embriquées dans le texte, je crois qu'effectivement l'idiome de flux
pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes flux
soient échangeable avec un ostream.
Une première remarque -- je ne suis pas sûr que les flux soit le bon
idiome pour ça. Mais passons...
Pourquoi ? A cause du 'render' final ?
Surtout parce que je n'avait pas régardé en détail, et qu'effectivement,
la nécessité d'une commande « render » provoque des doutes. Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
Même ici, je ne suis pas tout à fait sûr. Quand on considère du texte
formatté, disons comme fait un outil comme TeX, il ne s'agit pas autant
d'une flux, que d'une suite de flux, rassemblés d'une façon
hièrarchique, parfois verticalement, parfois horizontalement. Je n'ai
jamais fait une telle application -- je ne peux donc pas dire ce que je
ferais réelement. Disons que si je n'exclus pas pour l'instance
l'utilisation d'un flux, je ne le vois pas comme allant de soi non plus.
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas surcharger
sync dans ton streambuf pour faire la rendition (et l'appeler dans le
destructeur). Parce qu'en fin de compte, la rendition, c'est bien une
synchronisation du support réel avec le flux, non ?
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute dans
ta conception.)
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.Je ne veux pas avoir a modifier ces classes ou ajouter des fonctions
libres en plus qui utiliserais ces operateur derrière (ce que je
trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma site. Il
s'occupe du formattage en se servant des operator<< existant, mais sans
considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et bien
embriquées dans le texte, je crois qu'effectivement l'idiome de flux
pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes flux
soient échangeable avec un ostream.
Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
Alors, la
plupart du temps, quand de telles questions se posent, il s'agit des
étiquettes et des boutons dans une interface graphique ; dans de tels
cas, des attributes comme la couleur ou la police de caractères sont des
propriétés de l'élément graphique, non des propriétés embriquées dans le
flux du texte. Et les éléments graphiques, ça n'a rien à voir avec un
flux.
wrote:Alors, la plupart du temps, quand de telles questions se posent, il
s'agit des étiquettes et des boutons dans une interface graphique ;
dans de tels cas, des attributes comme la couleur ou la police de
caractères sont des propriétés de l'élément graphique, non des
propriétés embriquées dans le flux du texte. Et les éléments
graphiques, ça n'a rien à voir avec un flux.
QT propose une alternative que je trouve sympa : Quand on tape du text
dans un élément d'IHM, il est possible d'entre quelques tags "HTML"
pour mettre en forme une partie du texte. Ca offre plus de flexibilité
que de la mise en forme au niveau de l'élément graphique lui même, et
c'est assez souple à écrire.
kanze@gabi-soft.fr wrote:
Alors, la plupart du temps, quand de telles questions se posent, il
s'agit des étiquettes et des boutons dans une interface graphique ;
dans de tels cas, des attributes comme la couleur ou la police de
caractères sont des propriétés de l'élément graphique, non des
propriétés embriquées dans le flux du texte. Et les éléments
graphiques, ça n'a rien à voir avec un flux.
QT propose une alternative que je trouve sympa : Quand on tape du text
dans un élément d'IHM, il est possible d'entre quelques tags "HTML"
pour mettre en forme une partie du texte. Ca offre plus de flexibilité
que de la mise en forme au niveau de l'élément graphique lui même, et
c'est assez souple à écrire.
wrote:Alors, la plupart du temps, quand de telles questions se posent, il
s'agit des étiquettes et des boutons dans une interface graphique ;
dans de tels cas, des attributes comme la couleur ou la police de
caractères sont des propriétés de l'élément graphique, non des
propriétés embriquées dans le flux du texte. Et les éléments
graphiques, ça n'a rien à voir avec un flux.
QT propose une alternative que je trouve sympa : Quand on tape du text
dans un élément d'IHM, il est possible d'entre quelques tags "HTML"
pour mettre en forme une partie du texte. Ca offre plus de flexibilité
que de la mise en forme au niveau de l'élément graphique lui même, et
c'est assez souple à écrire.
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas
surcharger sync dans ton streambuf pour faire la rendition (et
l'appeler dans le destructeur). Parce qu'en fin de compte, la
rendition, c'est bien une synchronisation du support réel avec le
flux, non ?
Oui, mais ce rendu n'est pas synchrone, et n'a lieu qu'une fois par
'frame'. "render" est plus un "check-point".
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute
dans ta conception.)
flush est appelé par endl. Et je ne veux pas que endl soit percu de
cette facon.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.Je ne veux pas avoir a modifier ces classes ou ajouter des
fonctions libres en plus qui utiliserais ces operateur derrière (ce
que je trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma
site. Il s'occupe du formattage en se servant des operator<<
existant, mais sans considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et
bien embriquées dans le texte, je crois qu'effectivement l'idiome de
flux pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes
flux soient échangeable avec un ostream.
Non, en effet. Et ce n'est pas le but. La composition me convient tres
bien ! Disons que seul l'aspect "flux" est important. En effet,
l'output va servir aussi pour du debug sur l'ecran, avec la même
facilité qu'un cout.
Pour résumer, disons qu'il y a un service de rendu de texte formatté,
qui lit un certain format (ca pourrais etre du XML ou autre ! aucune
importance). Et ce service sert à plusieurs choses. Du debug (type
cout), des infos type HeadUpDisplay (formatté), une console (formattée
aussi) et une interface GUI 2D.
Et je preferes ecrire :
hud << push << bold << "hello" << pop
plutot que
hud.Push().Tag("B").Text("Hello").Pop()
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas
surcharger sync dans ton streambuf pour faire la rendition (et
l'appeler dans le destructeur). Parce qu'en fin de compte, la
rendition, c'est bien une synchronisation du support réel avec le
flux, non ?
Oui, mais ce rendu n'est pas synchrone, et n'a lieu qu'une fois par
'frame'. "render" est plus un "check-point".
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute
dans ta conception.)
flush est appelé par endl. Et je ne veux pas que endl soit percu de
cette facon.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.
Je ne veux pas avoir a modifier ces classes ou ajouter des
fonctions libres en plus qui utiliserais ces operateur derrière (ce
que je trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma
site. Il s'occupe du formattage en se servant des operator<<
existant, mais sans considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et
bien embriquées dans le texte, je crois qu'effectivement l'idiome de
flux pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes
flux soient échangeable avec un ostream.
Non, en effet. Et ce n'est pas le but. La composition me convient tres
bien ! Disons que seul l'aspect "flux" est important. En effet,
l'output va servir aussi pour du debug sur l'ecran, avec la même
facilité qu'un cout.
Pour résumer, disons qu'il y a un service de rendu de texte formatté,
qui lit un certain format (ca pourrais etre du XML ou autre ! aucune
importance). Et ce service sert à plusieurs choses. Du debug (type
cout), des infos type HeadUpDisplay (formatté), une console (formattée
aussi) et une interface GUI 2D.
Et je preferes ecrire :
hud << push << bold << "hello" << pop
plutot que
hud.Push().Tag("B").Text("Hello").Pop()
Mais puisqu'il s'agit d'un flux de texte ici, pourquoi pas
surcharger sync dans ton streambuf pour faire la rendition (et
l'appeler dans le destructeur). Parce qu'en fin de compte, la
rendition, c'est bien une synchronisation du support réel avec le
flux, non ?
Oui, mais ce rendu n'est pas synchrone, et n'a lieu qu'une fois par
'frame'. "render" est plus un "check-point".
Il est facultatif, et puis on peut le voir comme un 'flush' des
streams standards.
Donc, pourquoi pas utiliser flush ? (C'est réelement une question,
motivée par la curiosité, plutôt qu'un désir de trouver une faute
dans ta conception.)
flush est appelé par endl. Et je ne veux pas que endl soit percu de
cette facon.
Et je veux absolument profiter des operator<< pour des types
personnalisés qui ont cet opérateur.
La, je suis tout à fait d'accord.Je ne veux pas avoir a modifier ces classes ou ajouter des
fonctions libres en plus qui utiliserais ces operateur derrière (ce
que je trouve assez lourd !)
Mais sinon, quelle(s) autre(s) idée(s) aurais tu ?
Tu pourrais toujours jeter un coup d'oeil sur GB_Format, à ma
site. Il s'occupe du formattage en se servant des operator<<
existant, mais sans considérer le tout comme un flux.
Mais ce que je voyais plutôt, c'est une séparation éventuelle de la
génération du texte et de la spécification de ces attributes de
renditions. Maintenant que je vois que ces attributes sont bel et
bien embriquées dans le texte, je crois qu'effectivement l'idiome de
flux pourrait convenir.
Sans toutefois une héritage de ostream ; je ne crois pas que tes
flux soient échangeable avec un ostream.
Non, en effet. Et ce n'est pas le but. La composition me convient tres
bien ! Disons que seul l'aspect "flux" est important. En effet,
l'output va servir aussi pour du debug sur l'ecran, avec la même
facilité qu'un cout.
Pour résumer, disons qu'il y a un service de rendu de texte formatté,
qui lit un certain format (ca pourrais etre du XML ou autre ! aucune
importance). Et ce service sert à plusieurs choses. Du debug (type
cout), des infos type HeadUpDisplay (formatté), une console (formattée
aussi) et une interface GUI 2D.
Et je preferes ecrire :
hud << push << bold << "hello" << pop
plutot que
hud.Push().Tag("B").Text("Hello").Pop()
