3. cout == cerr?

cout == cerr?

  • E

    Hallo,
    ich versteh den Unterschied der beiden nicht...
    ich weiss, dass cerr dazu benutzt wird um eine Fehlermeldung auszugeben - aber da fuehrt cout bei mir zum selben Ergebnis...
    Hab in der Suche nichts passendes gefunden - kann mir das jemand anfaengerfreundlich erklaeren? 😕

    Gruss,
    Cartman

    0
  • V

    den unterschied siehst du, wenn du die ausgabeströme umleitest.
    ohne was zu machen, gehen beide auf den bildschirm.

    mit deinprog.exe 1> test.txt geht cout in die datei test.txt
    mit deinprog.exe 2> test.txt geht cerr in die datei test.txt

    das ist sinnig, wenn man die ausgabe von nem anderen prog weiterverarbeiten lassen will.

    0
  • L

    http://www.cplusplus.com/reference/iostream/cerr.html
    Du kannst somit etwa Fehlermeldungen in eine Datei umleiten, während die normale Ausgabe trotzdem ausgegeben wird. (logfile, pipe, ...)

    Außerdem wird es glaub ich direkter ausgegeben und nicht auf ein flush() gewartet?

    0
  • E

    @volkard koenntest du das etwas erlaeutern? Hab ich nicht so ganz verstanden 😉

    @langeweile auf ein "flush()"?

    Seh ich das jetzt richtig, dass bei einer einfachen Fehlermeldung (z.B. wenn das Oeffnen einer Datei fehlgeschlagen ist) nicht von Belang ist ob man cout oder cerr benutzt?

    0
  • .

    Eric Cartman schrieb:

    @volkard koenntest du das etwas erlaeutern? Hab ich nicht so ganz verstanden 😉

    Guckstu. std::cout ist normalerweise stdout, std::cerr ist normalerweise stderr.

    Eric Cartman schrieb:

    @langeweile auf ein "flush()"?

    cout ist normalerweise gepuffert, das heißt es wird nicht jedes Zeichen, das in den Strom kommt direkt an das Terminal weitergereicht, sondern es wird zunächst ein Puffer gefüllt und dann wenn der voll ist ausgegeben. Du kannst die Ausgabe aber erzwingen, indem du std::cout.flush() aufrufst (das wird zum Beispiel auch bei jedem std::endl gemacht).
    Der Fehlerstrom std::cerr ist dagegen normalerweise ungepuffert, damit sämtliche Fehlerausgaben auf den Bildschirm kommen, da die Information, die während eines möglichen Programmabsturzes noch im Puffer sind verloren gehen.

    Eric Cartman schrieb:

    Seh ich das jetzt richtig, dass bei einer einfachen Fehlermeldung (z.B. wenn das Oeffnen einer Datei fehlgeschlagen ist) nicht von Belang ist ob man cout oder cerr benutzt?

    Fehler, die zu einem Programmabbruch führen könnten oder werden gehören auf jeden Fall in std::cerr.

    0
  • N

    Es gibt auch noch std::clog , das schreibt normalerweise auch nach stderr und ist eher für Logging-Ausgaben gedacht.

    0
  • E

    Vielen Dank fuer die ausfuehrliche Erklaerung und den Link 👍
    Habe es jetzt verstanden, denke ich 😉

    Gruss,
    Cartman

    0
  • V

    Eric Cartman schrieb:

    Habe es jetzt verstanden, denke ich 😉

    gut. die pflicht ist getan.
    wenn du sauber daten lesen kannst, geht die ausgabe nach cout.
    wenn du gar nix lesen kannst, geht eine fehlermeldung nach cerr.
    ist ja klar.
    wenn du nur einen teil lesen kannst, gehen die einigermaßen sinnvollen daten nach cout.
    und die schrottigen nach cerr. ob alles nach dem ersten schrott auch schrott sein soll, oder nur schrottige zeilen schrottig sind und folgezeilen unabhängig davon gut sein können (also später doch nach cout), ergibt sich aus deiner anwendung und du dokumentierst es in der hilfeseite oder manpage.

    und jetzt kommt die kür:
    in welchen stream leitest du die ausgabe von deinDing.exe --help? nach cout oder nach cerr?

    0
  • E

    volkard schrieb:

    Eric Cartman schrieb:

    Habe es jetzt verstanden, denke ich 😉

    gut. die pflicht ist getan.
    wenn du sauber daten lesen kannst, geht die ausgabe nach cout.
    wenn du gar nix lesen kannst, geht eine fehlermeldung nach cerr.
    ist ja klar.
    wenn du nur einen teil lesen kannst, gehen die einigermaßen sinnvollen daten nach cout.
    und die schrottigen nach cerr. ob alles nach dem ersten schrott auch schrott sein soll, oder nur schrottige zeilen schrottig sind und folgezeilen unabhängig davon gut sein können (also später doch nach cout), ergibt sich aus deiner anwendung und du dokumentierst es in der hilfeseite oder manpage.

    Soweit klar 👍 😃

    volkard schrieb:

    und jetzt kommt die kür:
    in welchen stream leitest du die ausgabe von deinDing.exe --help? nach cout oder nach cerr?

    Das versteh ich jetzt nicht 😕
    Soll ' -help ' ein Programmparameter sein? Wenn ja wozu?

    Ich leite meine Ausgaben nach cout , und falls Operationen schief gelaufen sind, nach cerr ...

    Ich habe das jetzt soweit verstanden, dass es diese zwei verschiedenen Ausgabestroeme gibt (Standardausgabe und Fehlerausgabe) und sich diese auch z.B. unterschiedlich umleiten lassen (wie du weiter oben ja schon korrekt beschrieben hast in eine Datei), sodass der Nutzer die Moeglichkeit hat, die Error-Streams in einer Logfile zu speichern.

    Sehe ich das so richtig? 😕

    Gruss,
    Cartman

    0
  • V

    in der linux-welt sind die leute ein wenig sensibler, was das angeht.
    da gibt es einen befehl factor, der sein argment als int interpretiert und faktorisiert.

    factor 35
    gibt ausgabe

    35: 5 7

    (vermutlich nach cout)

    factor asd
    gibt ausgabe

    factor: `asd' is not a valid positive integer

    (vermutlich nach cerr)

    factor --help
    gibt ausgabe

    Usage: factor [NUMBER]...
  or:  factor OPTION
Print the prime factors of each NUMBER.

      --help     display this help and exit
      --version  output version information and exit

Print the prime factors of all specified integer NUMBERs.  If no arguments
are specified on the command line, they are read from standard input.

Report bugs to <bug-coreutils@gnu.org>.

    wohin? was ist sinnvoll?

    0
  • E

    nach cout wuerde ich sagen ...

    Die Help-Ausgabe ist ja vom User beabsichtigt und somit kein wirklicher Fehler (das zweite jedoch schon).

    meine ich zumindest.

    0
  • V

    Jau.
    Du hast es verstanden. 👍

    0
Log in to reply