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

  2. K. Frank

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >>What sample program would you suggest to give your students a basic
    >>framework for this kind of simple data input?

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

  3. K. Frank

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >-berlin.de (Stefan Ram) writes:
    >>>What sample program would you suggest to give your students a basic
    >>>framework for this kind of simple data input?

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

    >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
     
    Stefan Ram, May 26, 2014
    #3
  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.

    > "K. Frank" <> writes:
    > >Could people suggest a simple program that illustrates using
    > >console input with basic error handling that would be suitable
    > >for rank beginners?

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

    On Sunday, May 25, 2014 8:53:51 PM UTC-4, Stefan Ram wrote:
    > -bar.de (Stefan Ram) writes:
    > >-bar.de (Stefan Ram) writes:

    >
    > >>>What sample program would you suggest to give your students a basic
    > >>>framework for this kind of simple data input?

    >
    > >>It this is so �simple�, then why do you have to ask?

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


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

    Stefan Ram Guest

    "K. Frank" <> writes:
    >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.)
     
    Stefan Ram, May 26, 2014
    #5
  6. K. Frank

    Ian Collins Guest

    Stefan Ram wrote:
    > "K. Frank" <> writes:
    >> 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.

    --
    Ian Collins
     
    Ian Collins, May 26, 2014
    #6
  7. K. Frank

    Stefan Ram Guest

    Ian Collins <> writes:
    >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.
     
    Stefan Ram, May 26, 2014
    #7
  8. K. Frank

    Ian Collins Guest

    Stefan Ram wrote:
    > Ian Collins <> writes:
    >> 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.


    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.

    --
    Ian Collins
     
    Ian Collins, May 26, 2014
    #8
  9. Stefan Ram <-berlin.de> wrote:
    > 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
     
    Tobias Müller, May 26, 2014
    #9
  10. K. Frank

    Jorgen Grahn Guest

    On Sun, 2014-05-25, K. Frank wrote:
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 26, 2014
    #10
  11. K. Frank

    Öö Tiib Guest

    On Monday, 26 May 2014 02:48:52 UTC+3, K. Frank wrote:
    >
    > 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.
     
    Öö Tiib, May 26, 2014
    #11
  12. K. Frank

    Stefan Ram Guest

    Öö Tiib <> writes:
    >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.)
     
    Stefan Ram, May 26, 2014
    #12
  13. K. Frank

    K. Frank Guest

    Hello All!

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

    On Monday, May 26, 2014 6:39:23 AM UTC-4, Öö Tiib wrote:
    > On Monday, 26 May 2014 02:48:52 UTC+3, K. Frank wrote:
    > >
    > > 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.


    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
    #13
  14. K. Frank

    K. Frank Guest

    Hi Stefan!

    On Monday, May 26, 2014 9:22:27 AM UTC-4, Stefan Ram wrote:
    > �� Tiib <> writes:
    > >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.

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

    Stefan Ram Guest

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

    Guest

    On Monday, May 26, 2014 8:43:48 AM UTC-5, K. Frank wrote:
    > Hi Stefan!
    >
    > On Monday, May 26, 2014 9:22:27 AM UTC-4, Stefan Ram wrote:
    > > �� Tiib <> writes:
    > > >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.

    > >
    > > ...

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


    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
     
    , May 26, 2014
    #16
  17. K. Frank

    DrS Guest

    On 5/26/2014 1:30 PM, Christian Gollwitzer wrote:
    >
    > 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
     
    DrS, May 26, 2014
    #17
  18. K. Frank

    Öö Tiib Guest

    On Monday, 26 May 2014 16:22:27 UTC+3, Stefan Ram wrote:
    > Öö Tiib <> writes:
    > >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.


    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?

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

    > (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.)
     
    Öö Tiib, May 27, 2014
    #18
  19. K. Frank

    Jorgen Grahn Guest

    On Tue, 2014-05-27, Öö Tiib wrote:
    > On Monday, 26 May 2014 16:22:27 UTC+3, Stefan Ram wrote:

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


    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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 27, 2014
    #19
  20. K. Frank

    Stefan Ram Guest

    Öö Tiib <> writes:
    >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.
     
    Stefan Ram, May 27, 2014
    #20
    1. Advertisements

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.
Similar Threads
  1. W. D. Allen Sr.

    Simple HTML User Input and Process Output

    W. D. Allen Sr., Sep 12, 2005, in forum: HTML
    Replies:
    2
    Views:
    732
    Toby Inkster
    Sep 12, 2005
  2. Ben Finney
    Replies:
    2
    Views:
    1,265
    Egor Bolonev
    Jun 30, 2003
  3. Miktor
    Replies:
    7
    Views:
    12,833
    Joe Bacigalupa
    Aug 9, 2005
  4. pratap
    Replies:
    3
    Views:
    738
    James Kanze
    Jul 19, 2007
  5. Replies:
    5
    Views:
    3,797
    James Kanze
    Mar 4, 2008
  6. Replies:
    42
    Views:
    3,690
    Richard Bos
    Aug 31, 2009
  7. Kris Rudin

    console app w/o seeing console?

    Kris Rudin, Nov 11, 2003, in forum: ASP .Net Datagrid Control
    Replies:
    1
    Views:
    340
    Randy Charles Morin
    Nov 11, 2003
  8. Stefan Ram

    Teaching Java, teaching what?

    Stefan Ram, Dec 8, 2013, in forum: Java
    Replies:
    57
    Views:
    1,145
    Ali Sh
    Dec 18, 2013
Loading...