An Object-Oriented Model

Recalling that input/output in C++ is visualized with an object-oriented model sort-of like this:

    Screen/Monitor
    +============+
    |$ blah.out  |~,
    | your prog  |  ~,  cout      Your Program
    |            |    ~,         +------------+
    |displays    |~,    ~,       |            |
    |here [user] |  ~, |-\~~~~~~~|            |
    |            |    ~,\_\  |===|  [codes]   |
    |prog again  |      ~~~~~~~~~|            |
    +============+  insertion    |            |
                       <<        |------------|
                                 |            |
                               ,~|            |
                          cin,~  |  [vari-    |
    +====================+ ,~/|,~|   ables]   |
    |                    |~ |/~  |            |
    |    [user types]    |=|~    +------------+
    |                    |~ extraction
    +====================+     >>
           Keyboard

The Normal Display Route

Note how cout mans the boat (buffer) that hauls the information your program wanted to print from the CPU to the monitor for display. The insertion operator (<<) acts as the loading crew taking the data, calculation results, literal strings, and commands you ask to the dock to be loaded onto the boat. (Along the way, it takes the binary data and calculation results and reformats them into plain character text for display.) Normally cout heads for the screen when the boat gets full. These 'days' are spent lazily snoozing on the dock as <<s deliver byte after byte of cargo (cout has a fairly large boat -- about 2048 characters worth, typically). And when a delivery needs to be done, cout can count on the speed of the electricity in the stream to make the trip timely -- it just sits back with a slack hand on the rudder, watching the ion clouds float by.

But it may also deliver its load of information at other times. When the program ends, cout delivers whatever is left on the boat as its final load. This trip is a bit hurried, but not terribly taxing. When cin is reading, it tells cout to display its cargo so that any waiting prompts are seen before the user types. Although this might seem a critical situation, cout knows it can take its time seeing as the speed at which its and cin's boats travel lays waste the speed at which the average...nah...even the fastest user can read/type.

When endl comes along, however, things aren't so calm and leisurely. endl not only places its '\n' on the manifest, but also kicks the stool cout was snoozing in out from under the poor boat-man and pushes the boat away from the dock out toward to the monitor ready-or-not! (And the language endl uses! Such a foul temper on that command... You'd almost think he'd been sent as a prophet of the electronic gods or something... *shrug* That's probably how he sees it -- the programmer being his electronic gods and him their lowly servant to whip the peons into shape. What a weirdo!)

When Bad Things Happen to Good Programs...

There's only one other being on the screen docks that's quite as jumpy: cerr. But, at least his panicy jitteriness doesn't come from some distorted sense of piety and righteous might. Rather it comes from the knowledge that when he's called upon, there is a serious crisis at hand! He is the error handling stream, after all! If he's being used, something must be terribly wrong. Luckily, he doesn't bother cout to take him. He doesn't even rely on the speed of the river of electricity that acts as his conduit. He has some sort of caffeine/metabolism problem. Normally, he can be sitting on the dock just twitching -- kinda like Tweak (from South Park). But when the call comes down from the program, he's off with the screen message like the Flash (Marvel Comics; Justice League, etc.)!

(Truthfully, cerr's performance is more like Fry after his 100th cup of coffee -- Futurama -- or Kim and Rufus in Wade's cool sneakers -- Kim Possible. He is just moving so much faster than the rest of the crew, it's like he wasn't even gone! Especially when you consider that, without a boat, he's only carrying a single character at a time!)

The Normal Route of Input

But cin's dock is a little ...well... littler. He's got room on his boat for only 15 characters when the computer is first turned on. Luckily, most modern operating systems upgrade his boat to a few hundred characters capacity (or more) when they load into the CPU. But he's also got a crew of 'un'loaders working to translate the incoming keystrokes into the binary data the program has actually requested. You know these guys as extraction operators (>>). (They love it when you ask for character or even string data -- less work for them!)

Every time the user types a single keystroke, the character is loaded onto cin's little boat and when he sees the Enter (represented by a '\n') land in the cargo hold, he's off! The crew starts translating in a desperate attempt to be done by the time they reach the program's unloading station so appropriately formatted data can be taken by CPU transport workers to the designated memory locations.

When Bad Typing Happens to Good Users...

explain that cin has tendencies toward depression

    user input handling example

we can treat cin well and keep her/him as stable as possible or we can let him/her cycle in and out of depression with bits of drug/therapy between the traumas to pull her/him out

???always stable???

classify input as numeric or non before use!

    sample code of read then test

interlude: if/else:

if _this boolean condition is true_ then { body }

otherwise [else] { body }

A visual interpretation:

        /~~~~~~~~~~~~~~~~\
       `  what happened   '
        `   before this  '
         `    in the    '
          `  program  .'
           `----------
                |
                |
               `.'
                ^
               / \
              / ? \
       true  / is  \  false
     +------< cond  >------+
     |       \ true/       |
     | t      \ ? /     f  |
     | r       \ /      a  |
     | u        '       l  |
     | e                s  |
     |                  e  |
    `.'                   `.'
+---------+           +---------+
|   do    |           |   do    |
|  this   |           |  this   |
|  when   |           |  when   |
|  cond   |           |  cond   |
|   is    |           |   is    |
|  true   |           |  false  |
+---------+           +---------+
     |                     |
     |                     |
     +----------+----------+
                |
                |
               `.'
           ,----------
         .' what will `.
       .'  happen after `.
      '.     this in     `,
        \  the program   /
         ~~~~~~~~~~~~~~~~

A code instance:

    // what happened before this in the program
    if ( ?is cond true? )
    {
        // do this when cond is true
    }
    else
    {
        // do this when cond is false
    }
    // what will happen after this in the program

either exec and then jump off or jump down and then exec (and fall out)


back to input: okay, so it is a number, but it lost a digit! how do we re-attach it? 123... 103!

may we see your cargo? are you buying? no! then be careful! take my helper here with you! ...peek...

    sample code of peek to test

but what if there is nothing to see? a) '\n' b) empty bad libraries don't prompt unless you've truly read from the stream!

bring in the glutton: ws now we'll read any/all white-space in our way ('\n', '\t', ' ', ...) and by reading, prompt will display and buffer will fill!

what about the 'else'?

... and so on ...