Beginners Programming in C++

My team (FRC 1257) uses C++ to program the robot and I’d like to learn it. I’ve never really written code in anything except basic Python. Are there any good resources you know of to learning C++? Or how did you guys learn?

Any assistance would be amazing!

I’ve heard good things about Code Academy. Personally, I learned at a summer camp and subsequently took the C++ Intro class in college. You could look into a local community college and see if they offer a summer course or something.

As well, the WPI Library is a good place to start once you have a good handle on the basics of coding and want to know more about FRC specific applications. has super comprehensive tutorials. Heavy on the text, but if you bear with it you’ll learn a lot.

As a new C++ programmer, I encourage you to look at RobotBuilder and the Command-based robot template provided in the FRC tools. RobotBuilder is a graphical interface that will provide a set of C++ template files that are easy to work in. Even with only basic C++ skills, you can get a drivetrain defined and implemented very quickly. It will let you focus on how to make your robot work using C++ since it sets up all the files and syntax for an organized project.

I’ve been working on a C++ guide on my team website
its not completely done but the only thing im still working on is the fancier auton verson. It uses Iterative as opposed to command based like most.

I’ve found the most important part of learning C++ to be understanding how memory management works (that might just be because I came from a Java background though :slight_smile: )

Once you have a somewhat firm grasp on C++, I highly recommend writing a basic robot program from scratch. Run it on a test bot if your team has one, or use the WPILib simulator.

Or you could always switch to RobotPy :wink:

My team uses C++. The way I teach it is pretty tightly integrated with the software engineering principles I try to impart and the actual applications in FRC. I do that because it’s a lot easier to get students through the syntactic gotchas of C++ if they have interesting applications to work on. I think how you use the language at hand to solve FRC problems is more important than just learning a new language, so having context for how the learning resources fit into the overall pedagogy is important.

Note that a lot of the feedback portions require a dedicated software mentor, so this regimen may not work for everyone.


To teach my students C++, I use the book Programming: Principles and Practice Using C++ (2nd edition) by Bjarne Stroustrup. I like it because it’s designed for independent learning, works well for teaching students programming from scratch, and covers modern C++ idioms. A lot of the C++ resources I see online don’t follow best practices. By the way, those best practices are here:

With regard to memory management, try to think about ownership in terms of “who cleans this up when I’m done with it?”. The short version is don’t use the new and delete keywords for anything; prefer stack variables; if you need something on the heap, use std::unique_ptr for sole ownership; and use std::shared_ptr for shared ownership. I rarely use std::shared_ptr in my experience because a lot of ownership scenarios don’t represent true shared ownership. They are either a stack variable with only one object looking at it or a std::unique_ptr with a non-owning pointer to it somewhere else.

The online resources I put together for my students are here: I usually walk them through a chapter per week, then they do the exercises and I provide implementation and style feedback on their solutions. They make any corrections, and then we move on. This introduces them to the concept of code review.


At the same time, I give them a lecture on Git (the HTML slides I use on at, and I have my students submit the solutions mentioned earlier via Git. I try to emphasize how Git is basically an application of graph theory, because having that deeper understanding has saved our butts a couple times at competition when my students start doing hairy things to the branches and history.

One of my students even dug into the reflog at one point to get back some old commits because he wasn’t following good branching hygeine, but the fact he was able to recover himself is a testament to how flexible Git is when you really understand it. I try to teach my students enough to avoid at all costs, because you should never need to abort and do a fresh clone.

We use Gerrit for code review because I like the rebase workflow better than the merge workflow of GitHub (and we enforce rebases through the admin interface). I cover more of how to do that stuff in the presentation at I still need to go through those and expand on the lecture notes.

As far as branch hygeine, you keep master as the working version and give branches descriptive names and commit messages (no "Fixes " branch and also “Fixes the issue for real, I promise” with no indication as to which is the real “working” branch). A big part of in code review contexts is maintaining a clean commit history. I despise merge commits for this reason; they are just noise (last I checked, Brad was tied for most commits in wpilibc/wpilibj if you include the huge number of merge commits). Just rebase against master since you’re doing that merging work either way and you get cleaner history with a rebase. Rebasing a PR on GitHub or a changeset on Gerrit is technically modifying public history, but we treat those branches as private so the author can rebase it to produce a branch that is easier to review.


After we cover most of the C++ material, we move into doing state machines, starting with a lecture on what that is ( and then designing an auto-stacking state machine for our 2015 robot together Once we finish the state machine diagram, the students fill in the template provided with their state machine logic. I review it and test it against my working copy. I’ll probably integrate Google Test into this at some point, because unit testing is a skill I want to start teaching in FRC as well.

Basically, the idea is the students work on mini-projects to learn skills, then they put it all together during competition season. We spend probably a month during offseason teaching new members. Things go faster if the student does the assignments on their own time because the software team usually gets pulled away during the offseason build sessions for FLL things.

We usually don’t get to until build season, which teaches common design patterns using WPILib classes. I try to provide project templates with stuff like a .clang-format file so they can start off with good practices by default. We use the first part of build season to do more robot-specific training with C++ like drive code, subsystem abstraction design, incorporating feedback controllers, and tuning them.