Simple console input / output framework for teaching beginners

Discussion in 'C++' started by K. Frank, May 26, 2014.

  1. K. Frank

    K. Frank Guest

    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

    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
    K. Frank, May 26, 2014
    1. Advertisements

  2. K. Frank

    Stefan Ram Guest

    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, May 26, 2014
    1. Advertisements

  3. K. Frank

    Stefan Ram Guest

    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
    Stefan Ram, May 26, 2014
  4. K. Frank

    K. Frank Guest

    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 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.
    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.
    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?

    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.


    K. Frank
    K. Frank, May 26, 2014
  5. K. Frank

    Stefan Ram Guest

    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::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
    Stefan Ram, May 26, 2014
  6. K. Frank

    Ian Collins Guest

    Surely you don't teach adding that pretended "::" in your classes? It
    really is superfluous clutter anywhere but the most obscure corner case.
    Ian Collins, May 26, 2014
  7. K. Frank

    Stefan Ram Guest

    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.
    Stefan Ram, May 26, 2014
  8. K. Frank

    Ian Collins Guest

    Not really, one is pretentious, the other probably a typo!
    Ian Collins, May 26, 2014
  9. 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.

    Tobias Müller, May 26, 2014
  10. K. Frank

    Jorgen Grahn Guest

    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.

    Jorgen Grahn, May 26, 2014
  11. K. Frank

    Öö Tiib Guest

    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.
    Öö Tiib, May 26, 2014
  12. K. Frank

    Stefan Ram Guest

    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

    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.)
    Stefan Ram, May 26, 2014
  13. K. Frank

    K. Frank Guest

    Hello All!

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

    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, May 26, 2014
  14. K. Frank

    K. Frank Guest

    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.

    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
    K. Frank, May 26, 2014
  15. K. Frank

    Stefan Ram Guest

    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!«
    Stefan Ram, May 26, 2014
  16. K. Frank

    woodbrian77 Guest

    The command line permits automation more easily than a GUI.

    Ebenezer Enterprises - "Unless the L-RD builds the house,
    they labor in vain that build it." Psalms 127:1
    woodbrian77, May 26, 2014
  17. K. Frank

    DrS Guest

    :) 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

    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, May 26, 2014
  18. K. Frank

    Öö Tiib Guest

    Yes, C arrays and C strings. If there was something like
    I have had impression that C++ is not too easy in general for such
    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.
    Öö Tiib, May 27, 2014
  19. K. Frank

    Jorgen Grahn Guest

    Is that really that common? I associate it with older Unix GUIs ...
    but I must admit that I'm a command line user myself.
    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 Grahn, May 27, 2014
  20. K. Frank

    Stefan Ram Guest

    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.
    Stefan Ram, May 27, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.