Simple console input / output framework for teaching beginners

[K. Frank]

Hello Group!

Could people suggest a simple program that illustrates using
console input with basic error handling that would be suitable
for rank beginners?

Some context and more detail:

The question comes up from time to time as to whether it makes sense
to use C++ to teach programming to new programmers. (I think the
answer is yes, but this particular issue is not really my question.)

If you want to do so, you need to teach them basic programming
concepts, good programming habits, and good C++ programming
habits before you teach them all, or most, a lot, or even some
of the intricacies of C++.

Imagine that you are teaching a beginning programming class that
uses C++, and that the students have written their "hello world"
program, have a text editor or ide, and have made their peace with
whatever compile / build process they are using. Now you want them
to start writing simple programs that perform various simple tasks
on input data, and you want them to be able to read in data from the
console (cin), and write the results to the console (cout). (For the
sake of argument, let's stick to using cin rather than argc / argv
for input.)

But you want your students to be able to input their data in some
reasonably convenient way, and not have their program exit (or crash)
every time they mis-type some input data on the console (and you also
want your students to start facing the reality that the outside world
is not so accommodating as to make programming trivial, and you need to
have some kind of validation and error checking for input data, and,
ideally, need to give your users some support with thier data input).

So "cin >> var1 >> var2 >> var3; do_computation (var1, var2, var2);"
is out.

One approach might be to write a message to cout such as "enter var1,
var2, and var3", enter a loop in which you read in the data, verify,
and either print out a "try-again" message or accept it. You might do
this a couple of times if there were a couple of different chunks of
data you needed to read in. (But maybe there are other good approaches.)

What sample program would you suggest to give your students a basic
framework for this kind of simple data input? They wouldn't necessarily
be able to use the code unchanged from program to program, but it should
be suitable for use in similar, but distinct applications, if only through
copy-paste-modify.

Ideally, you should be able to walk the students through the sample in
one class period, and they should be able to understand the code and the
basic logic, even if they don't understand all of the nuances.

(For example, you would probably use std:string. If so, the students
presumably won't know (yet) that std::string is a specialized template,
or even that std::string is a library class, rather than a primitive type.
But they should know -- after you tell them -- that std::string is a type
that holds the value of a string, and is a good first choice for working
with strings.)

The idea is to give the students something that -- within the context of
being one of the earliest programs they encounter, and subsequently write
on their own -- starts them on the path of using modern C++ idioms (specifically
C++11), and good C++ habits.

There is clearly a trade-off between truly good code and code simple enough
for rank beginners. But within the constraint of the necessary simplicity
we want to start illustrating good programming habits.


Any comments and suggestions would be very welcome.


K. Frank

 

[Stefan Ram]

It this is so »simple«, then why do you have to ask?

One can just now (2014-05-26T00:00:00+00:00) go to
»comp.lang.c« and read the ten most-recent posts of the
thread »Why does my simple while loop printf 2x?«.

There, one can observe how difficult it seems to be
even for a supposedly non-beginning C programmer to
write a reasonable function to just read a »Y/N« answer!

 

[Stefan Ram]

There, one can observe how difficult it seems to be
even for a supposedly non-beginning C programmer to
write a reasonable function to just read a »Y/N« answer!

And, if you do not believe me or your own eyes,
you might believe Bjarne Stroustrup and Jon Pearce:

"Reading input is often the messiest part of a program."

Bjarne Stroustrup

"Output is easy, but input is filled with pitfalls that
await the unwary due to the gap between the actual and
the expected types of incoming data."

Jon Pearce

 

[K. Frank]

Hi Stefan!

Thank you for your response. I'm glad you commented,
because from some of your other posts I know you have
been teaching, and I was hoping you might bring some
of your real-world experience to the discussion.

(Technically I am replying to your third post, but I
will take the liberty of quoting from and commenting
on your first two posts, as well.)

First off, I agree very much with your general comments
that processing input is (sometimes unexpectedly) hard.
That's part of why I asked the question.

I refrain from using console input in my beginner's C++ course,
because I deem this to be too difficult for my beginner's C++
course, which has about 18 hours (including exercises in the
classroom) and addresses students who have never programmed
before.

I would be willing to agree that console input is too difficult
for rank beginners. (My concerns about the difficulty are part
of the motivation for my post.) But I would still like to ask
the question. So perhaps we could dial forward to intermediate
students (or whatever level you think they would need to be at),
and ask how you would present simple, yet practical console input
to students seeing it (in a substantive way) for the first time.

Why teach the teacher's /additional/ I/O library, which is
not part of standard C++, instead of directly teaching the
language C++ with its standard library?

I hope my phrasing didn't leave the wrong impression. I was
not suggesting giving the students the teacher's I/O library.
What I meant was to present to the students some simple, yet
practical input-processing idioms that are accessible to
input-processing beginners (if not complete C++ beginners,
and that, within the constraints of their simplicity, represent
good C++ practices), and walk them through setting up their own
framework -- for lack of a better word -- for processing input.
And I would expect and hope that these recommended idioms used
the relevant (simple) parts of the standard library.

One can just now (2014-05-26T00:00:00+00:00) go to
�comp.lang.c� and read the ten most-recent posts of the
thread �Why does my simple while loop printf 2x?�.

There, one can observe how difficult it seems to be
even for a supposedly non-beginning C programmer to
write a reasonable function to just read a �Y/N� answer!

Indeed. Over the years there have been several posts of this
kind. This is part of the reason for my question. Whether they
are deemed to be beginning, intermediate, or advanced students,
what should we be teaching them -- in concrete terms -- so that
they not end up needing to post these kinds of questions?

And, if you do not believe me or your own eyes,
you might believe Bjarne Stroustrup and Jon Pearce:

"Reading input is often the messiest part of a program."

Bjarne Stroustrup

"Output is easy, but input is filled with pitfalls that
await the unwary due to the gap between the actual and
the expected types of incoming data."

Jon Pearce

Absolutely true. But again, how should we help what I'll call
input-processing novices (whether or not we deem them programming
or C++ novices) master these challenges?

Again, I appreciate that you've been in the real world trying to
teach this stuff -- or deciding not to teach it -- to beginners,
so I very much value your further comments.


Thanks.


K. Frank

 

[Stefan Ram]

students (or whatever level you think they would need to be at),
and ask how you would present simple, yet practical console input
to students seeing it (in a substantive way) for the first time.

Indeed, I am teaching reading from the console in my »advanced«
course that is the continuation of the beginner's course.

I have an example program that is following. In Germany, the
usual grade is a number from 1 to 6. The program is supposed
to accept a grade, i.e., an integral number of the range [1, 6]:

#include <iostream>
#include <ostream>
#include <istream>
#include <string>
#include <initializer_list>
#include <limits>

int main()
{ int grade{ 0 };
while( grade < 1 || grade > 6 )
{ ::std::cout << "Grade (" << grade << "): "; /* prompt */
if( !( ::std::cin >> grade ))
{ ::std::cin.clear();
::std::cin.ignore
( ::std::numeric_limits< ::std::streamsize >::max(), '\n' ); }}
::std::cout << "The grade is: " << grade << ".\n"; }

But this is given near the end of the advanced course,
where they already have learned about user-defined type
conversions, user-defined operator overloading, template
arguments and type traits before, so that now they can
actually understand all of the above program.

If you really insist on using console input earlier, the
following approach might be feasible: You explain to the
class that you will read input, but as a simplification
for some time you will ignore the possibility of erroneuous
input, so that the programs can and will assume that the
user will always give an expected input.

In this case, the above program can be simplified to

#include <iostream>
#include <ostream>
#include <istream>
#include <string>
#include <initializer_list>

int main()
{ int grade{ 0 };
::std::cin >> grade;
::std::cout << "The grade is: " << grade << ".\n"; }

I think it is alright to make some simplifications as long
as this is the result of a conscious and informed decision,
and is clearly communicated to the students.

(Disclaimer: Some of the »#include«s above might not be
necessary.)

 

[Ian Collins]

students (or whatever level you think they would need to be at),
and ask how you would present simple, yet practical console input
to students seeing it (in a substantive way) for the first time.

Indeed, I am teaching reading from the console in my »advanced«
course that is the continuation of the beginner's course.

I have an example program that is following. In Germany, the
usual grade is a number from 1 to 6. The program is supposed
to accept a grade, i.e., an integral number of the range [1, 6]:

#include <iostream>
#include <ostream>
#include <istream>
#include <string>
#include <initializer_list>
#include <limits>

int main()
{ int grade{ 0 };
while( grade < 1 || grade > 6 )
{ ::std::cout << "Grade (" << grade << "): "; /* prompt */
if( !( ::std::cin >> grade ))

Surely you don't teach adding that pretended "::" in your classes? It
really is superfluous clutter anywhere but the most obscure corner case.

 

[Stefan Ram]

Surely you don't teach adding that pretended "::" in your classes? It
really is superfluous clutter anywhere but the most obscure corner case.

Maybe you meant »pretentious«?

The difference between »::std« and »std« is just like the
difference between »\tmp« and »tmp« under Un*x.

I my class I explain early to the students that most programmers
omit that »::« and that they are free to follow suit.

 

[Ian Collins]

Maybe you meant »pretentious«?


The difference between »::std« and »std« is just like the
difference between »\tmp« and »tmp« under Un*x.

Not really, one is pretentious, the other probably a typo!

I my class I explain early to the students that most programmers
omit that »::« and that they are free to follow suit.

Good.

 

[Tobias Müller]

The difference between »::std« and »std« is just like the
difference between »\tmp« and »tmp« under Un*x.

C++ name lookup and file system path resolving work quite differently.
Relative file system paths are only resolved against the current directory.
You cannot just use tmp/myfile.bin from anywhere, even if tmp is not a
local directory.

Tobi

 

[Jorgen Grahn]

Hello Group!

Could people suggest a simple program that illustrates using
console input with basic error handling that would be suitable
for rank beginners?

Some context and more detail:

The question comes up from time to time as to whether it makes sense
to use C++ to teach programming to new programmers. (I think the
answer is yes, but this particular issue is not really my question.)

If you want to do so, you need to teach them basic programming
concepts, good programming habits, and good C++ programming
habits before you teach them all, or most, a lot, or even some
of the intricacies of C++.

Imagine that you are teaching a beginning programming class that
uses C++, and that the students have written their "hello world"
program, have a text editor or ide, and have made their peace with
whatever compile / build process they are using. Now you want them
to start writing simple programs that perform various simple tasks
on input data, and you want them to be able to read in data from the
console (cin), and write the results to the console (cout). (For the
sake of argument, let's stick to using cin rather than argc / argv
for input.)

I'd go with argv/argc input if at all possible, and more specifically
getopt() if on Unix, or maybe something similar-yet-different from
Boost. It's more realistic than those "please enter a number" you see
in so many exercises, and easier to handle.

Or perhaps try to avoid exercises which need input? It's a boring and
difficult subject -- if you mix it with some more "interesting" task,
the I/O aspect will steal a lot of the focus.

Or you could write the I/O part yourself and hand it to them as a
class/function to use: that would teach them to deal with multiple
source files and multiple authors.

But you want your students to be able to input their data in some
reasonably convenient way, and not have their program exit (or crash)
every time they mis-type some input data on the console (and you also
want your students to start facing the reality that the outside world
is not so accommodating as to make programming trivial, and you need to
have some kind of validation and error checking for input data, and,
ideally, need to give your users some support with thier data input).

....

/Jorgen

 

[Öö Tiib]

Any comments and suggestions would be very welcome.

It feels best idea to teach as first thing how command line tools actually
work. In sense that most command line tools actually use *only* command
line arguments as user input.

Fewer command line tools use standard input (and other files/streams) as
additional source of input and rather few use standard input in interactive
cycle. So ... teach such as optional extension if at all.

 

[Stefan Ram]

It feels best idea to teach as first thing how command line tools actually
work. In sense that most command line tools actually use *only* command
line arguments as user input.

This means that the students are confronted with »char **
argv«, that is, pointers and C strings. To analyze input,
control structures might also be needed. And conversions
from a string to a number often are needed when numerals are
given. This might not be appropriate at the very start of a
course, when teaching to beginners with no prior programming
experience.

In the case of the people I teach, they usually do not have
any command line experience at all. They often seem to have
used only GUI software so far and deem command-line tools
»old fashioned« and cumbersome to use. So, it is not that
they always have used command lines like »cat tmp.txt | egrep
-o '\w+' | sort | uniq -c | sort -nr | head -9« and for all
their live they've been waiting to learn how that cat command
reads its command-line arguments so that they finally can
write their own!

(And by the way, in the case of my example command-line
above, every tool also uses stdin/stdout I/O, just not in
an interactive manner.)

 

[K. Frank]

Hello All!

This is a general reply to several comments, not just to
what Öö posted.

It feels best idea to teach as first thing how command line tools actually
work. In sense that most command line tools actually use *only* command
line arguments as user input.

Fewer command line tools use standard input (and other files/streams) as
additional source of input and rather few use standard input in interactive
cycle. So ... teach such as optional extension if at all.

Several replies have been along the lines of processing
console input is too hard or too boring or not useful
enough, so don't teach it, or use argc/argv, or give the
students a pre-packaged solution.

That's all very legitimate.

But I would like to press on with the original question.
Assuming we do want to teach some basic techniques for
processing console input, what should we do?

Stefan has posted one example (with the qualification
that it isn't really for beginners). What do you think
about his suggestion? Does it encourage good, modern
C++ idioms? Assuming that we do teach console input,
would you do something similar to what Stefan posted,
or would you suggest something rather different?


Thank you for your thoughts.


K. Frank

 

[K. Frank]

Hi Stefan!

...
In the case of the people I teach, they usually do not have
any command line experience at all. They often seem to have
used only GUI software so far and deem command-line tools
�old fashioned� and cumbersome to use.
...

I do agree that GUI software is largely replacing command-line
tools, and that students are very likely to have much more
experience using GUI software, and are likely to think in
those terms.

I've considered the possibility of teaching beginners to build
very simple GUI programs and learn how to accept input from the
GUI instead of dealing with cin. In the long run, it makes a
lot of sense to teach people how to build GUI applications.

But for beginners (or intermediate students, or whatever level
we think first processing input is appropriate), introducing
a GUI framework seems like too much, too early. (There is also
the fact it wouldn't be part of standard C++ and would have
reduced portability.)

But perhaps I'm overly conservative here -- maybe this would
be a good alternative: skip cin, and go straight to some gui
framework. Would this make sense?


Thanks for your feedback.


K. Frank

 

[Stefan Ram]

But perhaps I'm overly conservative here -- maybe this would
be a good alternative: skip cin, and go straight to some gui
framework. Would this make sense?

I am doing this in my Java SE course. But Java SE contains
three different GUI toolkits (AWT, Swing, and the new Java
FX) as part of the standard library!

The first 18 hours of my Java course only use output, but no
input. (This is the beginner's course.)

The next 12 hours (sometimes: 18) teach OOP and gradually
show some Swing examples. The culmination of it all, at the
very end of the course, is a Swing GUI program that increments
a visible counter whenever the users presses a button!

In C++, however, I do not show a GUI, as it is not part
of the standard library.

And I tell all my students: »If you just want to get to GUI
programming as fast as possible, go into the VBA course!«

 

[woodbrian77]

Hi Stefan!



I do agree that GUI software is largely replacing command-line
tools, and that students are very likely to have much more
experience using GUI software, and are likely to think in
those terms.

The command line permits automation more easily than a GUI.


Brian
Ebenezer Enterprises - "Unless the L-RD builds the house,
they labor in vain that build it." Psalms 127:1
http://webEbenezer.net

 

[DrS]

Wow, if this is the end of a programming course, then Java really sucks
at GUI much more than I thought. Here is your program in Tcl/Tk:

#!/bin/wish
package require Tk
pack [ttk::label .counter -textvariable c]
pack [ttk::button .button -text "Press me" -command {incr c}]
set c 0

Christian

Years ago, a VB developer was holding up a large and highly
compartmentalized project because a screen required a "control" that was
not yet available. We waited 3-4 months for the next release of the MS
libraries he was using. When it was finally released, he said that the
"control" still was not a good fit and would require more time and
searching.

Not knowing what a "control" meant, I approached him and asked what the
"control" was and what it did. It turns out it was essentially a simple
combo widget. I was fumed. It literally took an hour or so to do it in Tk.


DrS

 

[Öö Tiib]

This means that the students are confronted with 'char **
argv', that is, pointers and C strings. To analyze input,
control structures might also be needed. And conversions
from a string to a number often are needed when numerals are
given.

Yes, C arrays and C strings. If there was something like

This might not be appropriate at the very start of a
course, when teaching to beginners with no prior programming
experience.

I have had impression that C++ is not too easy in general for such
people.

In the case of the people I teach, they usually do not have
any command line experience at all. They often seem to have
used only GUI software so far and deem command-line tools
"old fashioned" and cumbersome to use. So, it is not that
they always have used command lines like "cat tmp.txt | egrep
-o '\w+' | sort | uniq -c | sort -nr | head -9" and for all
their live they've been waiting to learn how that cat command
reads its command-line arguments so that they finally can
write their own!

In real world the GUI apps are often tightly integrated with command
line programs or scripts (often "app" being only thin wrapper).
What is the point to keep that as secret for wannabe programmer?
It still feels good idea to explain *how* *software* *is* *made* to
students who want to learn that. When their prior impression is
naive then there is simply more to teach.

 

[Jorgen Grahn]

In real world the GUI apps are often tightly integrated with command
line programs or scripts (often "app" being only thin wrapper).

Is that really that common? I associate it with older Unix GUIs ...
but I must admit that I'm a command line user myself.

What is the point to keep that as secret for wannabe programmer?
It still feels good idea to explain *how* *software* *is* *made* to
students who want to learn that. When their prior impression is
naive then there is simply more to teach.

One thing is, if you "buy" the command line way of working, it's much
easier to write C++ programs to get things done. And it's easier to
play with and test those programs. Especially if you buy into the
Unix pipelone philosophy. Many of my best programs are just building
blocks which integrate with grep, sort et cetera.

The other side of the coin is, I think with the rise of the GUI
it suddenly became much harder to become a hobby programmer.

Perhaps web programming is a third route which is easier, quicker and
more useful, but C++ is not strong in that environment.

/Jorgen

 

[Stefan Ram]

Yes, C arrays and C strings. If there was something like
'int main(std::vector<std::string> const& args)' ... would it
be simpler to teach?

I am already teaching ::std:string and ::std::vector<T>, so
if C strings and C arrays were not needed anywhere anymore,
I'd not have to teach C strings and C arrays in addition.