The SLAR on System.Console

More from the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 here is an annotation from the System.Console attribute.

Brad Abrams:

Notice the heavy use of method overloading in this class. We special-case each

of the primitive types in order to avoid boxing overhead. We could have gotten away

with just having the overload that takes the object, but then calls such as these would

cause an extra allocation for the coercion to object:

Console.WriteLine (42);

and

Console.WriteLine ('c');

In general this kind of special casing is not necessary, but for a class that is likely to be

used in a tight loop it can be very helpful.

This class is a classic example of “design in reverse.” Before we designed this class we

knew what we wanted the Hello World example to look like:

Console.WriteLine ("Hello World");

We then created this class to make that sample code a reality. Even in the face of the

full complexity of a well-factored I/O system, we kept the simple things simple.

Anders Hejlsberg:

It is interesting to note that all of the Console.WriteXxx() methods are just

shorthand for Console.Out.WriteXxx(). Likewise, Console.ReadXxx() is

shorthand for Console.In.ReadXxx(). This design enables the In and Out

streams to be available directly in the rare cases where they are needed but does not

complicate the simple usage with them.

Brian Grunkemeyer

The OpenStandardXxx methods that take an integer for the buffer size are

really rather useless. We eventually decided that supporting buffering on the streams

used for Console is a silly notion, especially since classes like StreamReader and

StreamWriter may internally do their own buffering.

Kit George

Note that there is no easy way for a user to get a single key press: Return has to

be pressed before Read or ReadLine complete. This did not seem like a critical scenario

when we designed this class originally, but it is interesting to note that this has

been one of our top requests for the Console class since Version 1 was released.

Comments

• Anonymous
  January 17, 2005
  looks like something got cut off. "but it is interesting to note that this has..." has what?
• Anonymous
  January 17, 2005
  Ahh -- that is the bit you have to buy the book to find out what it says.. ;-)
  No really, my mistake, I will fix it.
• Anonymous
  January 17, 2005
  The comment has been removed
• Anonymous
  January 17, 2005
  >>Notice the heavy use of method overloading in this class. We special-case each of the primitive types in order to avoid boxing overhead.
  
  Sadly the savings are only at the first level. All of these functions end up merging in a general helper that does the formatting later in the call sequence. This is kind of too bad because we end up boxing where we could have avoided but all is not lost. By doing it the way we did we left the door open to fixing this in later versions. The IL in the code you write is doing it the good way and any boxing was moved into our libarary.
  
  Read Performance Quiz #1 at http://blogs.msdn.com/ricom/archive/2004/03/12/88715.aspx for more detais on this.
• Anonymous
  January 17, 2005
  Also note that KitG's comments are no longer valid for Whidbey. As most are probably aware, Console's received a great facelift with 2.0... Part of that (aside from color support :) ) is Console.ReadKey(), which returns a ConsoleKeyInfo struct. This has pretty much all the info you'd ever need, like the key pressed, any modifiers (Alt, Control, Shift), and so on.
• Anonymous
  January 18, 2005
  >> it's often useful to know whether reading from the inputstream will block
  
  It's also interesting to note that calling BeginRead on the standard input stream the Console class gives you will block, contrary to what you'd expect. As far as I can tell, it's effectively impossible to do asynchronous I/O to the console without having to dedicate a whole thread to it.