Je me demandais tout simplement si il y a une différence entre les flux
de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes
pratiquement de la même manière et d'après ce que j'ai vue il n'y a
aucune différence au niveau de la sortie sur l'écran.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe Lephay
"Karl St-Jacques" a écrit dans le message de news:
Je me demandais tout simplement si il y a une différence entre les flux de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes pratiquement de la même manière et d'après ce que j'ai vue il n'y a aucune différence au niveau de la sortie sur l'écran.
Merci de m'éclairer sur le sujet.
Comme tu le sais déjà, cerr envoie vers le périphérique d'erreur. Au niveau du langage, cin et cerr ne sont pas la même chose. Par contre, le périphérique d'erreur standard est généralement dirigé vers l'écran *au niveau du système*. Ceci dit, tu verras la différence si tu le rediriges vers une imprimante ou, pourquoi pas, un système de mail pour t'informer à distance que ton programme a une erreur...
Chris
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message de
news:pan.2003.08.05.01.23.02.240957@hotmail.com...
Je me demandais tout simplement si il y a une différence entre les flux
de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes
pratiquement de la même manière et d'après ce que j'ai vue il n'y a
aucune différence au niveau de la sortie sur l'écran.
Merci de m'éclairer sur le sujet.
Comme tu le sais déjà, cerr envoie vers le périphérique d'erreur. Au niveau
du langage, cin et cerr ne sont pas la même chose. Par contre, le
périphérique d'erreur standard est généralement dirigé vers l'écran *au
niveau du système*. Ceci dit, tu verras la différence si tu le rediriges
vers une imprimante ou, pourquoi pas, un système de mail pour t'informer à
distance que ton programme a une erreur...
"Karl St-Jacques" a écrit dans le message de news:
Je me demandais tout simplement si il y a une différence entre les flux de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes pratiquement de la même manière et d'après ce que j'ai vue il n'y a aucune différence au niveau de la sortie sur l'écran.
Merci de m'éclairer sur le sujet.
Comme tu le sais déjà, cerr envoie vers le périphérique d'erreur. Au niveau du langage, cin et cerr ne sont pas la même chose. Par contre, le périphérique d'erreur standard est généralement dirigé vers l'écran *au niveau du système*. Ceci dit, tu verras la différence si tu le rediriges vers une imprimante ou, pourquoi pas, un système de mail pour t'informer à distance que ton programme a une erreur...
Chris
Christophe Lephay
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Chris
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message de
news:pan.2003.08.05.01.49.04.218570@hotmail.com...
Mais mis à par le périphérique de sortit, il n'y a aucun changement
majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement)
différents. Quelle autre différence majeure attendais-tu ?
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Chris
drkm
Karl St-Jacques writes:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Ils sont tous deux de même type, mais de destination théoriquement différente. Donc à part le « périphérique de sortie », il n'y a aucun changement majeur entre les deux ;-).
Il est par exemple possible, sous la plupart des shells Unix (je ne sais pas pour command.com), de rediriger l'un ou l'autre. Par exemple, la commande suivante redirige l'erreur standard vers un fichier et la sortie standard vers un autre (respectivement « err » et « out ») :
prog > out 2> err
Cela est très intéressant pour l'utilisateur final, qui peut n'en avoir rien à faire des erreurs, ou justement sur une erreur, n'en avoir rien à faire de la sortie standard, et rediriger l'un et/ou l'autre comme bon lui semble.
Cela est le moins que l'on puisse faire : découpler la sortie standard, le résultat escompté, des erreurs imprévues. Mais bien souvent, il est intéressant d'introduire des niveaux intermédiaires. Les systèmes de logage permettent de définir ces niveaux intermédiaires, et de choisir à la compilation et/ou au run-time les sorties à effectuer, et où les effectuer.
Cfr. par exemple <URL:http//log4cplus.sf.net/>.
--drkm
Karl St-Jacques <sadness203@hotmail.com> writes:
Mais mis à par le périphérique de sortit, il n'y a aucun changement
majeure entre les 2 ?
Ils sont tous deux de même type, mais de destination théoriquement
différente. Donc à part le « périphérique de sortie », il n'y a aucun
changement majeur entre les deux ;-).
Il est par exemple possible, sous la plupart des shells Unix (je ne
sais pas pour command.com), de rediriger l'un ou l'autre. Par
exemple, la commande suivante redirige l'erreur standard vers un
fichier et la sortie standard vers un autre (respectivement « err » et
« out ») :
prog > out 2> err
Cela est très intéressant pour l'utilisateur final, qui peut n'en
avoir rien à faire des erreurs, ou justement sur une erreur, n'en
avoir rien à faire de la sortie standard, et rediriger l'un et/ou
l'autre comme bon lui semble.
Cela est le moins que l'on puisse faire : découpler la sortie
standard, le résultat escompté, des erreurs imprévues. Mais bien
souvent, il est intéressant d'introduire des niveaux intermédiaires.
Les systèmes de logage permettent de définir ces niveaux
intermédiaires, et de choisir à la compilation et/ou au run-time les
sorties à effectuer, et où les effectuer.
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Ils sont tous deux de même type, mais de destination théoriquement différente. Donc à part le « périphérique de sortie », il n'y a aucun changement majeur entre les deux ;-).
Il est par exemple possible, sous la plupart des shells Unix (je ne sais pas pour command.com), de rediriger l'un ou l'autre. Par exemple, la commande suivante redirige l'erreur standard vers un fichier et la sortie standard vers un autre (respectivement « err » et « out ») :
prog > out 2> err
Cela est très intéressant pour l'utilisateur final, qui peut n'en avoir rien à faire des erreurs, ou justement sur une erreur, n'en avoir rien à faire de la sortie standard, et rediriger l'un et/ou l'autre comme bon lui semble.
Cela est le moins que l'on puisse faire : découpler la sortie standard, le résultat escompté, des erreurs imprévues. Mais bien souvent, il est intéressant d'introduire des niveaux intermédiaires. Les systèmes de logage permettent de définir ces niveaux intermédiaires, et de choisir à la compilation et/ou au run-time les sorties à effectuer, et où les effectuer.
Cfr. par exemple <URL:http//log4cplus.sf.net/>.
--drkm
Patrick Mézard
Je me demandais tout simplement si il y a une différence entre les flux de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes pratiquement de la même manière et d'après ce que j'ai vue il n'y a aucune différence au niveau de la sortie sur l'écran.
En plus du fait qu'ils ne sont pas liés aux mêmes périphériques de sortie, il y a une autre différence mineure : par défault "cerr" est non bufferisé alors que "cout" l'est (ainsi que "clog").
Patrick Mézard
Je me demandais tout simplement si il y a une différence entre les flux
de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes
pratiquement de la même manière et d'après ce que j'ai vue il n'y a
aucune différence au niveau de la sortie sur l'écran.
En plus du fait qu'ils ne sont pas liés aux mêmes périphériques de sortie,
il y a une autre différence mineure : par défault "cerr" est non bufferisé
alors que "cout" l'est (ainsi que "clog").
Je me demandais tout simplement si il y a une différence entre les flux de sortie cerr et cout. De ce que je peu voir les 2 fonctionnes pratiquement de la même manière et d'après ce que j'ai vue il n'y a aucune différence au niveau de la sortie sur l'écran.
En plus du fait qu'ils ne sont pas liés aux mêmes périphériques de sortie, il y a une autre différence mineure : par défault "cerr" est non bufferisé alors que "cout" l'est (ainsi que "clog").
Patrick Mézard
Frédéri MIAILLE
Question : on peut redéfinir le périphérique de sortie de cout ? Et on fait comment pour redéfinir le périphérique de sortie de cerr ? C'est au niveau de l'environnement/OS que ça se fait, donc rien à voir avec le programme.
Question :
on peut redéfinir le périphérique de sortie de cout ?
Et on fait comment pour redéfinir le périphérique de sortie de cerr ? C'est
au niveau de l'environnement/OS que ça se fait, donc rien à voir avec le
programme.
Question : on peut redéfinir le périphérique de sortie de cout ? Et on fait comment pour redéfinir le périphérique de sortie de cerr ? C'est au niveau de l'environnement/OS que ça se fait, donc rien à voir avec le programme.
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Chris
Justement j'en sais rien:) Le c++ est souvent très surprenant après tout ;)
Merci bien pour les réponses claires.
Karl.
Alain Naigeon
"Karl St-Jacques" a écrit dans le message news:
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Chris
Justement j'en sais rien:) Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont assignés au niveau du système d'exploitation, donc ça permet, si on veut, d'envoyer les erreurs ailleurs. La plupart du temps le réglage par défaut pour un OS c'est que cout et cerr sont le même périph = écran, mais on peut changer ça ... si on le juge utile (mail aux pompiers, au chef, au père fouettard :-) )
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message news:
pan.2003.08.05.10.45.52.296414@hotmail.com...
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message de
news:pan.2003.08.05.01.49.04.218570@hotmail.com...
Mais mis à par le périphérique de sortit, il n'y a aucun changement
majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie
(potentiellement) différents. Quelle autre différence majeure
attendais-tu ?
Chris
Justement j'en sais rien:)
Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont assignés
au niveau du système d'exploitation, donc ça permet, si on veut,
d'envoyer les erreurs ailleurs. La plupart du temps le réglage par défaut
pour un OS c'est que cout et cerr sont le même périph = écran, mais on
peut changer ça ... si on le juge utile (mail aux pompiers, au chef, au
père fouettard :-) )
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Chris
Justement j'en sais rien:) Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont assignés au niveau du système d'exploitation, donc ça permet, si on veut, d'envoyer les erreurs ailleurs. La plupart du temps le réglage par défaut pour un OS c'est que cout et cerr sont le même périph = écran, mais on peut changer ça ... si on le juge utile (mail aux pompiers, au chef, au père fouettard :-) )
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
kanze
"Alain Naigeon" wrote in message news:<3f2fa1cf$0$27839$...
"Karl St-Jacques" a écrit dans le message news:
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Justement j'en sais rien:) Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont assignés au niveau du système d'exploitation, donc ça permet, si on veut, d'envoyer les erreurs ailleurs. La plupart du temps le réglage par défaut pour un OS c'est que cout et cerr sont le même périph > écran, mais on peut changer ça ... si on le juge utile (mail aux pompiers, au chef, au père fouettard :-) )
Je crois que le défaut dépend beaucoup du contexte. Dans un contexte intéractif, le défaut est l'écran de l'intéraction. Dans d'autres contextes, en revanche...
La règle qu'utilise Unix, c'est que les cin, cout et cerr sont hérités du processus qui nous a lancé (mais ce processus peut les changer avant le lancement). Donc, si on est lancé d'un interpréteur de commande, ils correspondent par défaut aux flux de l'interpréteur de commande.
Dans la pratique, à part des programmes d'expériementation, c'est assez rare de lancer un programme avec tous les flux intéractifs. Historiquement, d'ailleurs, la raison d'être de cerr, c'est de permettre les erreurs d'apparaître sur l'écran même quand les sorties standards se perdent dans une pipe.
-- 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
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f2fa1cf$0$27839$626a54ce@news.free.fr>...
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message news:
pan.2003.08.05.10.45.52.296414@hotmail.com...
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" <sadness203@hotmail.com> a écrit dans le message de
news:pan.2003.08.05.01.49.04.218570@hotmail.com...
Mais mis à par le périphérique de sortit, il n'y a aucun
changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie
(potentiellement) différents. Quelle autre différence majeure
attendais-tu ?
Justement j'en sais rien:)
Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont
assignés au niveau du système d'exploitation, donc ça permet, si on
veut, d'envoyer les erreurs ailleurs. La plupart du temps le réglage
par défaut pour un OS c'est que cout et cerr sont le même périph > écran, mais on peut changer ça ... si on le juge utile (mail aux
pompiers, au chef, au père fouettard :-) )
Je crois que le défaut dépend beaucoup du contexte. Dans un contexte
intéractif, le défaut est l'écran de l'intéraction. Dans d'autres
contextes, en revanche...
La règle qu'utilise Unix, c'est que les cin, cout et cerr sont hérités
du processus qui nous a lancé (mais ce processus peut les changer avant
le lancement). Donc, si on est lancé d'un interpréteur de commande, ils
correspondent par défaut aux flux de l'interpréteur de commande.
Dans la pratique, à part des programmes d'expériementation, c'est assez
rare de lancer un programme avec tous les flux intéractifs.
Historiquement, d'ailleurs, la raison d'être de cerr, c'est de permettre
les erreurs d'apparaître sur l'écran même quand les sorties standards se
perdent dans une pipe.
--
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
"Alain Naigeon" wrote in message news:<3f2fa1cf$0$27839$...
"Karl St-Jacques" a écrit dans le message news:
On Tue, 05 Aug 2003 06:37:17 +0200, Christophe Lephay wrote:
"Karl St-Jacques" a écrit dans le message de news:
Mais mis à par le périphérique de sortit, il n'y a aucun changement majeure entre les 2 ?
Mais cout et cerr désignent deux périphériques de sortie (potentiellement) différents. Quelle autre différence majeure attendais-tu ?
Justement j'en sais rien:) Le c++ est souvent très surprenant après tout ;)
Vu du langage, il n'y a pas de différence. Les périphs réels sont assignés au niveau du système d'exploitation, donc ça permet, si on veut, d'envoyer les erreurs ailleurs. La plupart du temps le réglage par défaut pour un OS c'est que cout et cerr sont le même périph > écran, mais on peut changer ça ... si on le juge utile (mail aux pompiers, au chef, au père fouettard :-) )
Je crois que le défaut dépend beaucoup du contexte. Dans un contexte intéractif, le défaut est l'écran de l'intéraction. Dans d'autres contextes, en revanche...
La règle qu'utilise Unix, c'est que les cin, cout et cerr sont hérités du processus qui nous a lancé (mais ce processus peut les changer avant le lancement). Donc, si on est lancé d'un interpréteur de commande, ils correspondent par défaut aux flux de l'interpréteur de commande.
Dans la pratique, à part des programmes d'expériementation, c'est assez rare de lancer un programme avec tous les flux intéractifs. Historiquement, d'ailleurs, la raison d'être de cerr, c'est de permettre les erreurs d'apparaître sur l'écran même quand les sorties standards se perdent dans une pipe.
-- 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
Arnaud Debaene
wrote:
(Arnaud Debaene) wrote in message news:...
"Frédéri MIAILLE" wrote in message news:<bgnoa0$va6$...
Question : on peut redéfinir le périphérique de sortie de cout ? Et on fait comment pour redéfinir le périphérique de sortie de cerr ?
Dans les 2 cas, c'est dépendant de l'OS, mais il est fort probable que tu peux faire pour l'un ce que tu peux faire pour l'autre.
J'attendrais de n'importe quel OS digne de ce nom qu'il me permette de faire cette redirection aussi bien par programmation que par l'extérieur (via le shell). J'attendrais même de pouvoir rediriger dynamiquement un flux durant l'exécution du programme.
Au moins sous Unix (et je crois Windows aussi), ça ne dépend absolument pas de l'OS, mais plutôt du programme qui a lancé ton programme. Oui, le programme père spécifie les flux initiaux (par défaut, on hérite de
ceux du père), mais on peut le changer. Ce que je veux dire, c'est que les moyens pour (re)définir les flux sont spécifiques à l'OS
Et je ne suis pas sûr ce que tu entends par « rédiriger dynamiquement un flux durant l'exécution du programme ». Au cours de son exécution, le programme décide de changer la
destination/source physique de ces flux standards.
La seule façon de changer un flux, c'est de le fermer et de le réouvrir sur un autre fichier. Et ça ne marche, évidemment que sur des fstream. Pas question de le faire avec les flux prédéfinis. Selon la norme ok, mais certains OS permettent de le faire. Voir
SetStdHandle sous Windows par exemple (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba se/setstdhandle.asp)
Arnaud
kanze@gabi-soft.fr wrote:
adebaene@club-internet.fr (Arnaud Debaene) wrote in message
news:<16a4a8c7.0308050735.4d92ad3c@posting.google.com>...
"Frédéri MIAILLE" <bobranger_no_spam@wanadoo.fr> wrote in message
news:<bgnoa0$va6$1@biggoron.nerim.net>...
Question :
on peut redéfinir le périphérique de sortie de cout ? Et on fait
comment pour redéfinir le périphérique de sortie de cerr ?
Dans les 2 cas, c'est dépendant de l'OS, mais il est fort probable
que tu peux faire pour l'un ce que tu peux faire pour l'autre.
J'attendrais de n'importe quel OS digne de ce nom qu'il me permette
de faire cette redirection aussi bien par programmation que par
l'extérieur (via le shell). J'attendrais même de pouvoir rediriger
dynamiquement un flux durant l'exécution du programme.
Au moins sous Unix (et je crois Windows aussi), ça ne dépend
absolument pas de l'OS, mais plutôt du programme qui a lancé ton
programme.
Oui, le programme père spécifie les flux initiaux (par défaut, on hérite de
ceux du père), mais on peut le changer. Ce que je veux dire, c'est que les
moyens pour (re)définir les flux sont spécifiques à l'OS
Et je ne suis pas sûr ce que tu entends par « rédiriger dynamiquement
un flux durant l'exécution du programme ».
Au cours de son exécution, le programme décide de changer la
destination/source physique de ces flux standards.
La seule façon de changer
un flux, c'est de le fermer et de le réouvrir sur un autre fichier.
Et ça ne marche, évidemment que sur des fstream. Pas question de le
faire avec les flux prédéfinis.
Selon la norme ok, mais certains OS permettent de le faire. Voir
SetStdHandle sous Windows par exemple
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
se/setstdhandle.asp)
"Frédéri MIAILLE" wrote in message news:<bgnoa0$va6$...
Question : on peut redéfinir le périphérique de sortie de cout ? Et on fait comment pour redéfinir le périphérique de sortie de cerr ?
Dans les 2 cas, c'est dépendant de l'OS, mais il est fort probable que tu peux faire pour l'un ce que tu peux faire pour l'autre.
J'attendrais de n'importe quel OS digne de ce nom qu'il me permette de faire cette redirection aussi bien par programmation que par l'extérieur (via le shell). J'attendrais même de pouvoir rediriger dynamiquement un flux durant l'exécution du programme.
Au moins sous Unix (et je crois Windows aussi), ça ne dépend absolument pas de l'OS, mais plutôt du programme qui a lancé ton programme. Oui, le programme père spécifie les flux initiaux (par défaut, on hérite de
ceux du père), mais on peut le changer. Ce que je veux dire, c'est que les moyens pour (re)définir les flux sont spécifiques à l'OS
Et je ne suis pas sûr ce que tu entends par « rédiriger dynamiquement un flux durant l'exécution du programme ». Au cours de son exécution, le programme décide de changer la
destination/source physique de ces flux standards.
La seule façon de changer un flux, c'est de le fermer et de le réouvrir sur un autre fichier. Et ça ne marche, évidemment que sur des fstream. Pas question de le faire avec les flux prédéfinis. Selon la norme ok, mais certains OS permettent de le faire. Voir
SetStdHandle sous Windows par exemple (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba se/setstdhandle.asp)
Arnaud
James Kanze
"Arnaud Debaene" writes:
|> wrote: |> > (Arnaud Debaene) wrote in message |> > news:...
|> >> "Frédéri MIAILLE" wrote in message |> >> news:<bgnoa0$va6$... |> >>> Question : |> >>> on peut redéfinir le périphérique de sortie de cout ? |> >>> Et on fait comment pour redéfinir le périphérique de |> >>> sortie de cerr ?
|> >> Dans les 2 cas, c'est dépendant de l'OS, mais il est fort |> >> probable que tu peux faire pour l'un ce que tu peux faire pour |> >> l'autre.
|> >> J'attendrais de n'importe quel OS digne de ce nom qu'il me |> >> permette de faire cette redirection aussi bien par |> >> programmation que par l'extérieur (via le shell). |> >> J'attendrais même de pouvoir rediriger dynamiquement un flux |> >> durant l'exécution du programme.
|> > Au moins sous Unix (et je crois Windows aussi), ça ne |> > dépend absolument pas de l'OS, mais plutôt du programme |> > qui a lancé ton programme.
|> Oui, le programme père spécifie les flux initiaux (par |> défaut, on hérite de ceux du père), mais on peut le |> changer. Ce que je veux dire, c'est que les moyens pour |> (re)définir les flux sont spécifiques à l'OS
Je crois qu'on parle d'à côté. Normalement, tu ne peux PAS changer un flux standard, une fois que ton programme a démarrer. Ce qui dépend de l'OS, c'est comment changer les flux que le programme lanceur passe à ces fils.
|> > Et je ne suis pas sûr ce que tu entends par « rédiriger |> > dynamiquement un flux durant l'exécution du programme ».
|> Au cours de son exécution, le programme décide de changer la |> destination/source physique de ces flux standards.
|> > La seule façon de changer |> > un flux, c'est de le fermer et de le réouvrir sur un autre fichier. |> > Et ça ne marche, évidemment que sur des fstream. Pas question de le |> > faire avec les flux prédéfinis.
|> Selon la norme ok, mais certains OS permettent de le faire. Voir |> SetStdHandle sous Windows par exemple |> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setstdhandle.asp)
Certains OS, peut-être. Sous Unix, on peut faire joujou avec close et dup. Mais du coup, on ne sait plus ce qui se passe avec cin, cout et cerr. Parce qu'il ne suffit pas de changer ce que le système considère le flux standard -- il faut que cin, cout et cerr en soit informé, et qu'ils font des mise à jour nécessaire de leurs buffers, etc.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> kanze@gabi-soft.fr wrote:
|> > adebaene@club-internet.fr (Arnaud Debaene) wrote in message
|> > news:<16a4a8c7.0308050735.4d92ad3c@posting.google.com>...
|> >> "Frédéri MIAILLE" <bobranger_no_spam@wanadoo.fr> wrote in message
|> >> news:<bgnoa0$va6$1@biggoron.nerim.net>...
|> >>> Question :
|> >>> on peut redéfinir le périphérique de sortie de cout ?
|> >>> Et on fait comment pour redéfinir le périphérique de
|> >>> sortie de cerr ?
|> >> Dans les 2 cas, c'est dépendant de l'OS, mais il est fort
|> >> probable que tu peux faire pour l'un ce que tu peux faire pour
|> >> l'autre.
|> >> J'attendrais de n'importe quel OS digne de ce nom qu'il me
|> >> permette de faire cette redirection aussi bien par
|> >> programmation que par l'extérieur (via le shell).
|> >> J'attendrais même de pouvoir rediriger dynamiquement un flux
|> >> durant l'exécution du programme.
|> > Au moins sous Unix (et je crois Windows aussi), ça ne
|> > dépend absolument pas de l'OS, mais plutôt du programme
|> > qui a lancé ton programme.
|> Oui, le programme père spécifie les flux initiaux (par
|> défaut, on hérite de ceux du père), mais on peut le
|> changer. Ce que je veux dire, c'est que les moyens pour
|> (re)définir les flux sont spécifiques à l'OS
Je crois qu'on parle d'à côté. Normalement, tu ne peux PAS
changer un flux standard, une fois que ton programme a démarrer. Ce
qui dépend de l'OS, c'est comment changer les flux que le programme
lanceur passe à ces fils.
|> > Et je ne suis pas sûr ce que tu entends par « rédiriger
|> > dynamiquement un flux durant l'exécution du programme ».
|> Au cours de son exécution, le programme décide de changer la
|> destination/source physique de ces flux standards.
|> > La seule façon de changer
|> > un flux, c'est de le fermer et de le réouvrir sur un autre fichier.
|> > Et ça ne marche, évidemment que sur des fstream. Pas question de le
|> > faire avec les flux prédéfinis.
|> Selon la norme ok, mais certains OS permettent de le faire. Voir
|> SetStdHandle sous Windows par exemple
|> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setstdhandle.asp)
Certains OS, peut-être. Sous Unix, on peut faire joujou avec close
et dup. Mais du coup, on ne sait plus ce qui se passe avec cin, cout
et cerr. Parce qu'il ne suffit pas de changer ce que le système
considère le flux standard -- il faut que cin, cout et cerr en soit
informé, et qu'ils font des mise à jour nécessaire de leurs
buffers, etc.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> wrote: |> > (Arnaud Debaene) wrote in message |> > news:...
|> >> "Frédéri MIAILLE" wrote in message |> >> news:<bgnoa0$va6$... |> >>> Question : |> >>> on peut redéfinir le périphérique de sortie de cout ? |> >>> Et on fait comment pour redéfinir le périphérique de |> >>> sortie de cerr ?
|> >> Dans les 2 cas, c'est dépendant de l'OS, mais il est fort |> >> probable que tu peux faire pour l'un ce que tu peux faire pour |> >> l'autre.
|> >> J'attendrais de n'importe quel OS digne de ce nom qu'il me |> >> permette de faire cette redirection aussi bien par |> >> programmation que par l'extérieur (via le shell). |> >> J'attendrais même de pouvoir rediriger dynamiquement un flux |> >> durant l'exécution du programme.
|> > Au moins sous Unix (et je crois Windows aussi), ça ne |> > dépend absolument pas de l'OS, mais plutôt du programme |> > qui a lancé ton programme.
|> Oui, le programme père spécifie les flux initiaux (par |> défaut, on hérite de ceux du père), mais on peut le |> changer. Ce que je veux dire, c'est que les moyens pour |> (re)définir les flux sont spécifiques à l'OS
Je crois qu'on parle d'à côté. Normalement, tu ne peux PAS changer un flux standard, une fois que ton programme a démarrer. Ce qui dépend de l'OS, c'est comment changer les flux que le programme lanceur passe à ces fils.
|> > Et je ne suis pas sûr ce que tu entends par « rédiriger |> > dynamiquement un flux durant l'exécution du programme ».
|> Au cours de son exécution, le programme décide de changer la |> destination/source physique de ces flux standards.
|> > La seule façon de changer |> > un flux, c'est de le fermer et de le réouvrir sur un autre fichier. |> > Et ça ne marche, évidemment que sur des fstream. Pas question de le |> > faire avec les flux prédéfinis.
|> Selon la norme ok, mais certains OS permettent de le faire. Voir |> SetStdHandle sous Windows par exemple |> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setstdhandle.asp)
Certains OS, peut-être. Sous Unix, on peut faire joujou avec close et dup. Mais du coup, on ne sait plus ce qui se passe avec cin, cout et cerr. Parce qu'il ne suffit pas de changer ce que le système considère le flux standard -- il faut que cin, cout et cerr en soit informé, et qu'ils font des mise à jour nécessaire de leurs buffers, etc.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
