Teaching C++ to first time high school students: Where to draw the line?

Question

I will be mentoring a team of high school students for the FIRST Robotics Competition, most teams here develop[ their robot software using C++. For many of the students on the team this will be their first introduction to programming. I wouldn't have chosen C++ for teaching programming to high schoolers (e.g. Python or Javascript would have been easier I think) but the choice is set.

I want to teach them proper C++ (i.e. avoid a mixed C/C++ dialect, i.e. C+) but I don't want to scare them either with needless complexity. For that matter:

• Should I start using STL from day one, esp. vector or just stick with standard arrays? Arrays are easier to introduce but the pointer errors may be harder to catch.
• For I/O, should I stick to cout, etc. or do you think printf would be easier to learn?
• Are there any online resources for C++ that are suitable to use for such young learners?

Thanks!

EDIT: Thanks for so many excellent answers. In addition to Accelerated C++, which is suggested by many people, I have found that C++ For Everyone is an excellent text.

Answer 1

I think you should start with the data types that the language has built in like arrays and pointers, and when your students comprehend those, move on to classes and OO, then the STL.

The reason is that you can teach people to understand arrays without understanding much else besides variables and the underlying computer architecture, but you can't teach them to understand vector without teaching them classes first. If you use the STL from the get go, your students will have to just live with not having a clue about how vector works exactly. And then when you get to that point, they won't have a good enough grasp of pointers and arrays and things that you get from doing stuff like writing your own vector class, writing your own linked list class, etc. that will be necessary to appreciate and exploit its features. It annoys me when students say "what's that?" and teachers say "just ignore it, you'll learn it later."

And as Demian pointed out in the comments, deciphering the relatively cryptic messages you get from template errors is significantly harder than understanding the errors you may get from arrays/non-template constructs.

I do not feel the same way about cout and printf. Neither is any lower-level than the other, except that cout uses operator overloading.

This may seem stupid, but I am absolutely fanatic about having people understand the very basic building blocks of everything before moving on to the abstractions. You shouldn't use smart pointers until you're proficient with raw pointers, no vectors before arrays, that sort of thing.

I often say this, but I'll say it again: it's better to teach students long division first and then let them use a calculator than to let them use a calculator then teach them long division afterwards.

As for books to teach beginners, see the master list of good C++ books.

Answer 2

This is my own experience. Take it for whatever it's worth.

Looking back to when I started programming, I really wish I would have learned about memory first. No, it's not exciting. It'll make you glaze over. But it's a ridiculously easy concept to teach. Just show a 1-D table and make them go through a few mental exercises:

Lesson 1:
This is 10 bytes of memory. This is the letter "a" being put into cell number 3. "a" is the value, and 3 is the address. OK? This is the number 3 being put into cell 5. Its value is 3 and it's address is 5. Now what can the number 3 mean? Well it could be just a number 3 -or- it could be a reference to address 3. Just like 1 might be a number or might be a country code. It's just a number, it all depends on how we treat it.

Lesson 2:
Let's learn to count in binary. Let's count to 10 using binary finger counting. Interesting no? See how that only needed 4 fingers? So we say that only 4 bits are needed (1/2 cell). What's the highest you can count to on one hand (answer is 31). How about 2 hands (answer is 1023). Explain how more bits means higher number ranges. Remind them that a memory cell is 8 bits. Ask what happens when a number needs more than 8 bits. How would they put a multi-byte number into memory (in a logical way)? Introduce them to chars, shorts, integers, and longs.

Lesson 3:
Here's a program I wrote in C++. It uses 32-bit integers. And this here is also a number. But this is a number used for pointing. By using this little asterisk thingie we're making a promise that the number is going to be used for pointing. And here's how we point it at the first number. The little ampersand fills the value in for us. Neat huh?

etcetera. Once you get basic memory down, everything else is cake. It's the poor students who assume the compiler is doing something magical (or that they never have to think about memory management) who tend to struggle the most. And C++ muddies the waters because some things get automatically cleaned up (i.e. a normal vector) while other things don't (i.e. a vector allocated using "new"). And don't even get me started on strings (char* vs. std::string -- try explaining that without pointer knowledge).

I don't know what platform your robot competition will be targeting, but if it's a limited-memory environment, memory mangement skills are crucial.

EDIT

Once you've taught them the fundamentals, then yes I say go C++ all the way. Technically they're just different libraries, but yeah there's no point in confusing them with more than one paradigm. Give them C++ tools (which includes pointers and arrays).

Answer 3

Should I start using STL from day one, esp. vector or just stick with standard arrays? Arrays are easier to introduce but the pointer errors may be harder to catch.

definitely go right into using standard library types. a std::string or std::vector is what they should often use and (the vast majority of the implementations of) these types offer some form of error detection and error handling, while abstracting many of the complexities from the students.

you can spend a good chunk of time teaching students how memory is structured and how to manage memory (C style), or you can get straight to work using the idiomatic types of the language then explain implementation details if needed (and when they have a better understanding of what an array is and where they are used).

the syntax of std::vector (create/read/write) is not much more complicated than a C array's. in comparison, manual memory management and all the common errors new learners make with C arrays are far more difficult to learn, teach, and use.

For I/O, should I stick to cout, etc. or do you think printf would be easier to learn?

cout. personally, i think cout's a easier to learn. perhaps more importantly, you should choose cout because it is more safe, versatile, and allows you to define how an object prints, which means you already have builtin functionalities and typesafety using the some standard library types. finally, you'll just end up with mixed programs when you realize they may also need to learn cout in addition to printf.

in fact, i think you should read Accelerated C++, by Koenig and Moo and possibly use it for instruction (answering question 3 indirectly). in the book, they introduce std::cout just before return (page 3), and save pointers and arrays until chapter 10. if i could copy and paste the preface of that book as an answer to your question, i would. (note: i recommend you read it for the perspective of teaching c++).

Edit Here is the Preface

Are there any online resources for C++ that are suitable to use for such young learners?

if you don't want to use Accelerated C++ (which does assume some background with programming in general), then maybe you would like Eckel's Thinking in C++. I have not read it, but it is a freely distributed C++ intro text.

Answer 4

One thing to consider is that in typical FIRST code data structures of any form (structs, classes, arrays, vectors, lists) play a very small role. You typically deal with a very small amount of sensor data, and use it to decide a very small amount of actuator motions.

But what does play a huge role, and can be very hard to understand are all the different forms of control that go on.

So I'd put a lot of emphasis on control. Start with basics: if, for, while. Have them practice those a lot. Get them to know those well....

... but then it gets harder. Any robot code of moderate size eventually gets to some trickier control patterns:

• Big "main" loop, that calls everything

• State machines (these show up a lot)

• Saving previous values / running counter (like for PID)

These are hard for beginners to understand. Thinking about how a program moves through code like this is confusing, you might not realize it now, but it is. It's going to give your students a lot more trouble than the language itself.

Also, good luck! Hope the season goes well.

Answer 5

• Should I start using STL from day one, esp. vector or just stick with standard arrays? Arrays are easier to introduce but the pointer errors may be harder to catch.

The problem with arrays is that anything except simple textbook examples will require dynamically sized arrays, and the moment you need dynamically sized arrays, std::vector is so much more easier. Also, the only way to safely handle dynamically sized arrays is to wrap them in your own class, which would be a poor std::vector rip-off.
Contrary to inexplicably popular belief, students can use features that require complex mechanics to be implemented without knowing how to implement such beasts themselves. As I have said in a comment: You wouldn't even think of considering not teaching strings in other languages, just because their implementation is complex, would you?

• For I/O, should I stick to cout, etc. or do you think printf would be easier to learn?

Why would a set of archaic format string conventions that make your program blow up through the roof the moment you get something wrong (which happens the moment you change a typedef in some seemingly unrelated header) be preferable to the type safety of std::cout?

• Are there any online resources for C++ that are suitable to use for such young learners?

Most C++ resources, online or not, are bad. And I'm not talking about using hard-to-read fonts or language. I'm talking glaringly obvious factual errors. There's very few good C++ resources, mostly one or two dozen books. The only one I know is online is Bruce Eckel's Thinking in C++.

---

For a decade, I have taught C++ to students with very different background using Koenig/Moo's Accelerated C++ as a base. My course has changed a lot in that decade, is is now nowhere near the book, except for the underlying principle: Use the modern, correct, safe idioms from the very beginning. Do not teach your students how to manually manipulate memory, just to have them later unlearn that in favor of safer idioms. As you can see at some of the answeres provided here, this does not work: Those once taught the manual ways first will rarely ever understand the advantage of using modern, safe idioms.

Answer 6

If you want to teach C++, I would start directly with C++ constructs as vector and cout, instead of the C subset like printf.

Answer 7

Should I start using STL from day one ...?

Yes. Using native arrays in C++ is error prone and simply bad practice 99% of the time.

For I/O, should I stick to cout, etc... ?

Yes.

Are there any online resources for C++ that are suitable to use for such young learners?

They aren't so young. Learning to program does not require wisdom, just motivation and an open mind. I can't think of anything taught in the last two years of high school that would better prepare a student to learn to program. Have you looked at Bruce Eckel's Thinking in C++? It's available for free download and very well reviewed. Please avoid the popular but horrible C++: How to Program and all the Sam's Teach Yourself C++ ... books.

Answer 8

I was taught C++ in high school as a first programming language, although it was more like "C+", now that you mention it; we used cout for writing text to the console and files, but also quite a few C functions (getch() was my favourite).

I think the most effective (and possibly fun) way of teaching the basics is using a goal-oriented curriculum: start with showing how to output stuff, then keyboard input, then simple file I/O, etc. Progress to a simple text-based game (or the robotics equivalent). Then when they ask, "How do I do X?", you can break down X in terms of examples they've already seen, e.g. "First you'll need to get the input from the user like we did in Z, then..." (obviously it isn't this easy in practice since X will likely be something that they need additional knowledge in order to do, e.g. "3D graphics", but you could still explain how it would work in a high-level way).

Examples you show them will start out as black-box copy-pasted magic, whose mysteries get unravelled as pieces of the programming puzzle are slowly figured out. For example, your students will learn the basics of ifs quite quickly, but they probably won't realize that a boolean expression is not exclusively limited to use within an if's condition (leading to classic if (blah) return true; else return false; code).

The subtleties of whether you choose an array or vector as a container will seem irrelevant to the students at first. A vector/array will simply be a way of having lots of variables as one variable, accessible via an index. Stick to one where you can. Pointers won't be understood until later either. That's not to say that you shouldn't explain things; just that you can't explain everything at once, and the stuff you do explain won't be completely absorbed. Humans learn organically, not linearly. I'd been using cout for a couple years before I properly understood what operator overloading was!

Oh, and don't be afraid of repetition. "This is like the Hello World program we did -- remember how we wrote text to the console?" (no...) "Let's go through it again just to make sure." ... And ask questions! Keep the students engaged with fun examples and lots of interaction.

C++ is a complex language, and no matter what you do, a significant amount of that complexity (and that of the craft of programming in general) will be lost on your students. Everything you show them will be new to them; most of it won't sink in at a deep level of understanding (at least, not right away). How memory works, how the components of a PC interact, what the stack and heap are, pointers, classes, even loops and if-else chains won't be properly understood by the majority. This is OK! They don't have to be understood to be used -- an amazing amount of cool programs can be written with super-ugly 1000-line functions with quintuple-nested redundant ifs and 43 variables named things like x_2r. The important thing is that the students are constantly learning and improving. Black boxes are fine as long as they become transparent (or at least translucent grey) in the long run. By the end of the course, they might not know what design patters are, but they should be able to look back at the programs they wrote in the first few weeks and cringe at their code. They should understand at a significant level of detail how the first program they wrote actually works (whereas when they wrote it they had no idea). But they won't know everything -- yet.

Answer 9

I have taken a bunch of programming classes in my life from high school to College. I can say that I really didn't learn too much from my first c++ class other than how to print things to a stream.

My advice, as a young student, who has only for the past few years had any real work being a developer, is to not dumb things down on them. Tell them what they are doing and how it works down to the operating system level (No need to get into comp eng IMO).

I think teaching them C is a better way to go about it (it will still almost always compile as C++ as you know). Teaching them what the terminal really is, how their program interacts with it, that a string is an array of chars ended with a \0 in memory, what malloc is and how C++ abstracts it, how a char and an int are stored in memory, ect... These things are what makes someone actually know how to solve a problem when they come across it in development.

I can not stress the importance of letting the kids program and being there mainly to answer questions. In my experience, you learn a language by using it. Books and lessons can be helpful and are necessary to get started, but in the end, I say give them a C/C++ file and say: This is an example of X, I'd like you to do Y(which can be done by hacking X). Show them how to use man pages(if they are using *NIX) or show them cplusplus.com and let them explore the std libs to figure out things on their own.

TL;DR Let the kids teach themselves. Be there to provide structure and answer questions.

Also: Linked lists are the truth!

Answer 10

You're not teaching them programming in a general way, you're teaching them a kind of embedded programming using Robots and such. If I understood correctly.

First, I think you should check what libraries you're going to use and what you need.

If you happen to have a C library to use or C-like with a lot of pointers and C-arrays, then I guess you'd need a way to teach them how to use it or why you use it.

But, you can show them some simple codes to get them started with strings and vectors, that's how C++ works. That does not mean you can't teach them pointers.

Maybe you should make it clear of the differences between low level C++ ( which resembles C) and high level C++ with the STL. One of the most difficult thing in C++ for beginners is to see what is C, what is C++ and what are the different system APIs.

As the goal here isn't to learn general programming but to enter a Robot competition, I'd oriented the teaching this way.

Answer 11

I started teaching students C++ late last year and this summer also for our FIRST Robotics Team.

We are using Stroustrup's Programming -- Principles and Practice Using C++. I have found the book to be approachable, readable, and well organized. We have had about 6 students read through the chapters on their own. I am there to help them with terminology and questions. They do all of the exercises in the book.

I had the students work through chapter 14. Skipping the chapters on streams (not useful for FRC programming). Through chapter 14 is useful because they get an introduction to subclasses. However, they probably need to go farther in the book in order to better understand constructors and destructors related to subclasses.

Do not underestimate your students. The students are happy to have the book, read, learn and do the exercises; and this was during the summer on their own time! There are many students that won't understand. They should move on to something else; not everyone understands programming.

The largest barrier isn't the language or the book; it's the development environment. Visual Studio Express can be daunting to first time users. You can be valuable in helping the students focus on the programming rather than the environment. However, learning the environment is valuable as programmers spend a good deal of time adapting to new development systems.

Good Luck.

Answer 12

You say you want to teach them C++ but not teach them any C constructs, but most of the programming constructs they'll need to know first are common to all languages and the C++ versions are rooted in C:

1. This is how you make a program [int main (..) { return 0; }]. Give a basic overview of the programming environment you want them to try out too. They'll need to know how to make a project and actually compile/run it.

2. This is a variable. Variables can store data (int, char, float, etc).

3. Strings (C++ ones are easier to use with cin).

4. This is how you read and write data (cin, cout). "Hello, %s!"

5. Conditionals (computers need to make decisions).

6. Loops (computers are good at doing the same thing over and over). Show while and for loops.

That should take about two lessons of an hour each. Make sure to prepare a concise set of notes that they can refer to in the practical component. You're not trying to make them brilliant programmers so give examples of how to read from the console, create structures, and everything else they'd need to do. Only use language-supported features, not custom utility libraries. You'll only confuse them more.

From the get-go, lead by example and show them examples of well laid out code. Indents should be correct, bracing and parentheses consistent in the style you are most comfortable with. Variable names should be meaningful. If you show slop as an example then they'll learn that slop is acceptable. It's a bad starting point. Stress the importance of getting indenting correct - I found that when the lot I taught indented their code consistently they were more easily able to see where they were going wrong. That was because most of their errors were incorrect scope for operations (putting operations in loops/conditionals that weren't meant to be, or the inverse).

Then move onto practical work. The best way to learn something is to break it and work out why. You'll want to make sure they have an easy to use environment to compile their code. Document it with screen shots in your hand outs.

A good example that helped me grok some of the concepts was build a Coke machine:

• Output a menu of items and prices (storing the menu was an array of a user-defined structure. Could be a class in C++). Outputting it required a loop.
• Read in the user's selection.
• Ask the user for money. They could just enter coin denomination in cents (1, 5, 10, 20, 50, 100, 200 in Aus). Ignore unknown denominations. While the user hasn't put in enough money, keep asking (loops).
• Calculate the change required (modulo division), giving the least number of coins. Print the output to the screen.
• Wait for next user.

After that you can move onto C++ constructs; you don't want to dive in too far before they can at least make a basic program.

And above all, have lots of spare time and patience to devote to questions. There will be many, and most of them will make you cringe because they are so trivial that the answer is obvious to you.

Answer 13

I think you should not teach things from C++ point of view ("C++ hello world"), but from the problem domain - in this case, robotics - point of view. So, your hello world would be blinking a led or driving a motor.

Of course you could/should decompose each tiny robotics task in a subset of increasing conceptually meaningful C++ actions, involving types, functions and IO operations.

As for myself, I am not a professional programmer, and tried to learn Java, C++ and Python. I really started to achieve something (Python) when I had real (simple) problems to solve. That took me right to the point, avoiding excessive attention to incidental implementation details of the language itself.

So I would advice: don't read a language's manual, but instead learn to do things with your language of choice. That's what keep people motivated, I think.

Answer 14

I would teach strict C++. You know how when you write printf and give it to little params or the wrong type something strange happens? and if you use invalid pointers bad things may occur? DON'T TEACH THAT

From day one i would teach how to use references, STL and say you LOSE MARKS for using pointers. Don't teach smart pointers either. The only time i notice i use pointers are when i do GUI and objects (like an image box) must exist and be a valid image or null. For console programming i haven't use pointers (smart or raw) in a long time.

So in short dont teach them anything that can give them trouble. Teach iostreams, structs, tell them they lose marks on typecast too and dont try to teach design. You dont want anyone becoming a Seasoned professional

Answer 15

It's not a C++ lecture series, but Richard Buckland's COMP1917 is an excellently-done lecture series on programming in C (followed with COMP1927, data structures).

In my own opinion, C++ is too much complexity for new students, but C is worlds simpler and provides a good foundation in systems programming that new C++ programmers all too often lack.

Answer 16

I would start out with significant chunks of boilerplate code, help them "do something cool" with the programming right away and refine their understanding of how things work over time. They don't need to appreciate or understand all the intricacies of C++ to make an LED blink. They just need to know "if you put this code there, it will make the LED blink." And then "hey, lets talk about what a loop is now, if you write a loop, you can make the LED blink 50 times without having to write 50 lines of code, isn't that cool?" Now lets talk about conditionals, when the user presses button A on the control box, we want to activate the pneumatics to raise a flag, here's how we'd add code to do that. Or if switch 2 on our control box is flipped to on, we run the drill motor in reverse instead of forward. Here's what a conditional statement looks like and how we tell the drill motor which direction to run....

If you keep things focused on teaching them "just enough" to solve the problems they're interested in, it will make things a lot less overwhelming and more approachable. If they're really interested, and want to understand the intricacies, they'll probably go back and read a comprehensive book on programming or taking a summer school course at the local JC.

Make a list of the "things they want to be able to control" on their robot and turn each one into a lesson...what is the least they need to know to... ?

• do something "cool looking" if a switch is in a particular setting?
• tell a pneumatic valve to open or close (eg: a grabber attachment)?
• turn drill motors on and off (for the drivetrain)?
• make the robot change directions if an obstacle detection sensor is activated?
• make the robot switch between 2 wheel vs 4 wheel drive modes?
• adjust the sensitivity of the joystick?
• etc.

I would stick to teaching the contructs that are most foolproof, like I would teach cout over printf, because format specifiers are very easy to mix up and an incorrect specifier is often an automatic recipe to crash your program. Likewise, vector obfuscates some of the memory management complexities. Don't worry about every detail about how things work, or what the STL library is, just the least they need to know to accomplish X (which might require using an STL library datastructure, for example)

Answer 17

Use How to Program C++ by Deitel and Deitel. EXCELLENT textbook in my opinion.

Sounds like you're trying to teach novices how to program and then have them program at some advanced level at the same time. If you hope to give them some monkey see monkey do coding snippets w/o an understanding you're doomed to failure.

Stay away from STL for a beginner class.

If you already have a coding solution for your robot - or a VERY GOOD IDEA of what it will look like then perhaps you can "map" the lessons in the textbook to the coding tasks for the robot. But let the textbook drive the learning.

If you force-feed coding, giving the students very narrow lessons and exposure to the language then I think as the ocean of code you write gets bigger and bigger, it will be like having just learned to dog paddle and you will drown because REAL swimming is required.

It's not a question of "should they learn cout or printf?" It's a question of learning enough to have insight on how to write code for given robot programming tasks to solve.

If this were a reading assignment, what would the results be if all they knew were simple subject-verb sentences and only half the vocabulary you KNOW will be required.