2010-03-08 9 views
10

¿Alguien puede explicar la diferencia entre cerr cout y clog y por qué se proponen diferentes objetos?La pregunta sobre cerr cout y clog

sé las diferencias son las siguientes:

1) cout puede redirigir, pero no puede cerr

2) obstruyen puede utilizar búfer.

Estoy confundido acerca del punto 2, estoy agradecido si alguien puede elaborarlo más.

+17

¿Quién dice que no se puede redirigir a cerr? ¡Lo hago todo el tiempo! –

Respuesta

3

La salida en búfer es típicamente mucho más rápida que la memoria sin búfer. Por lo tanto, si quisiera escribir una gran cantidad de datos rápidamente en un registro (pero no le importó si realmente terminaron allí), usaría clog en lugar de cerr.

Y todas las transmisiones normalmente se pueden redirigir, asumiendo un sistema operativo vagamente competente, pero esto está por fuera del estándar C++, que no tiene un concepto como "redirección".

+3

Es posible que desee elaborar un poco sobre el lado positivo del lado positivo de cerr/no-buffer-i, es decir, la secuencia se escribe incluso si ocurre algo incorrecto inmediatamente después de la operación de escritura. –

+0

@RaphaelSP Eso es lo que quise decir con "(pero no le importó si realmente terminó allí)" –

+1

@Neil: aparentemente el OP está confundido acerca de qué es el almacenamiento en búfer, creo que la formulación podría ser más clara :) –

2

Ambas pueden ser redirigidas.
En la mayoría de las implementaciones cerr no se almacenará en búfer, no estoy seguro si este es un requisito oficial de POSIX, pero es una locura tener un flujo de error almacenado.

La razón para tener transmisiones separadas es de la filosofía de Unix que la salida de un programa es la entrada a la siguiente. Si 'ls' va directo a 'ordenar', es más fácil que aparezcan errores en la consola que escribir para entender si una entrada es un mensaje de error o parte del texto que desea ordenar.

16

La salida puede almacenarse en búfer o sin búfer. Con la salida en búfer, la implementación guarda todo el resultado hasta que sea conveniente escribirlo en el disco (o donde sea). Esto es agradable y eficiente, pero si el programa falla, es muy probable que se pierda algo de producción. La implementación tiene que escribir una salida sin búfer en el disco a medida que ocurre, lo que puede ralentizar las cosas con muchas grabaciones en el disco, pero a menos que se cuelgue un programa mientras se está escribiendo, se escribirá en el disco.

No existe una diferencia funcional real entre la salida estándar y el error estándar; son solo dos flujos de salida diferentes que se pueden redirigir por separado. La filosofía de Unix de encadenar herramientas en conjunto es que la salida estándar tendrá el resultado adecuado para entrar en la entrada de la siguiente herramienta, y esto requiere que haya una secuencia separada para los mensajes de error.

Por lo tanto, cout escribe a la salida estándar, y se almacena en el búfer. Use esto para salida normal. cerr escribe en la secuencia de error estándar y no se almacena. Use esto para mensajes de error. clog escribe en la secuencia de error estándar, pero se almacena en el búfer. Esto es útil para el registro de ejecución, ya que no interfiere con la salida estándar, pero es eficiente (a costa de que el final del registro se pierda si el programa falla).

1
cout-Screen output(stdout) 
clog-Buffered output of standard error(stderr) 
cerr-Standard error device output (stderr) 
0

Una de las principales razones detrás de usar el buffer de salida y sin memoria intermedia se puede observar mediante la adopción de caída del programa como un ejemplo.

Considere un programa que está produciendo algo en un archivo de registro. Y de repente el programa se bloqueó. Puede que en este momento le interese saber qué error hizo que se bloquee, pero si utilizó clog (buffer) para todos los registros y errores, es posible que no vea toda esta información, ya que aún podría estar en el búfer cuando el programa se bloqueó, por lo tanto la información buffer también se pierde.

Por lo tanto, en caso de errores, cerr se usa principalmente ya que no está búfer y no puede haber ninguna situación ahora cuando se pierde un error importante durante un bloqueo de programa simplemente porque estaba en búfer.