behaviour of Debug.AutoFlush on ConsoleTraceListener

  • Thread starter Thread starter ambidexterous
  • Start date Start date
A

ambidexterous

public class Program

{

static void Main(string[] args)

{

Debug.Listeners.Add(new ConsoleTraceListener());

Debug.AutoFlush = false;



Debug.WriteLine("Some debug info");



Console.WriteLine("There is no impact! Nothing is going to be
terminated/cancelled");

Console.WriteLine("Debug data:");

Console.WriteLine();

Debug.Flush();

}

}

Why are program above producing this output:



[Console output:]

Some debug info

There is no impact! Nothing is going to be terminated/cancelled

Debug data:



Instead of this output:



[Console output:]

There is no impact! Nothing is going to be terminated/cancelled

Debug data:



Some debug info



I don't get it. I expected that AutoFlush = false, means that data from
memory buffer is going to be written to the trace listener only on call of
Flush(), why then i get it before Flush is called?
 
I don't get it. I expected that AutoFlush = false, means that data from
memory buffer is going to be written to the trace listener only on call of
Flush(), why then i get it before Flush is called?
Click to expand...

IMO the listerner is just not buffered... Using Reflector would allow to
check this.
 
Using Reflector would allow to check this.

This is a DefaultTraceListener. Flush is empty and under the hood "write"
writes immediately to the debugger using OutputDebugString in kernel32...
 
ambidexterous said:
[...]
I don't get it. I expected that AutoFlush = false, means that data from
memory buffer is going to be written to the trace listener only on call of
Flush(), why then i get it before Flush is called?
Click to expand...

The Flush() method will force data to be written out. But the converse
is not true: failing to call Flush() doesn't mean that data won't be
written out, even for a buffered stream. Eventually, the stream will
have to write data out, either because its internal buffer is full, or
some other condition has been satisfied (e.g. an end-of-line might be
sufficient for certain streams or writers).

Pete
 
As a side note and unless this is just to do some testing to see how a
buffered stream works, you may want to explain what you are trying to do.

In particular buffering is just an optimization that is your code should IMO
always produce the same result regardless of wether or not something is
buffered...
 
Thanks Patrice, i was using this for testing, so i don 't think it's worth
trying to understand how this stuff works internally

I wondered though is there some other listener that registers everythinh in
memory and you can then read it on demand

like

var listener = new MemoryListener()
Debug.Listerenrs.Add(listener)

then goes some stuff that adds debug messages

then you get the info out of the listener variable...

smmth of that nature ?
 
Back
Top