I’ve been coding in Java for 3 years, but I am interested in C++
I was wondering how difficult it is to learn for someone who has never touched the language.
And mostly if it is even realistic to expect to know it well enough to code the robot with it, given the limited time until the season
So, from teams who have used it
How hard is it to learn and use C++?
What are the main compromises when using C++?
Is AdvantageKit supported?
Cheers
It is not that difficult to learn if you’ve already been programming mindfully for multiple years.
The primary difference from Java is that you will be expected to think about object lifespans. The language offers you tools to manage memory, but those tools are standard library functions that you still have to think about and use. This means you must understand the heap and the stack.
Certainly going to look into these topics, thanks!
Are there any resources you’d recommend for c++ in general and wpilib specifically?
Just so you know, AdvantageKit only works with Java for now, AFAIK. Something to note about switching to C++ is even if you personally are fine with it, and ready, is your team ready? That is, ready to train students more and to rely on online resources less?
When I used to mentor 3512, we taught students C++ in the span of two months. It consisted of reading chapters from a textbook, solving selected exercises (ones that looked reasonably interesting), then doing rounds of code review until their code worked and was clean. Their solutions were submitted through Git.
The important language features to learn are variables, control flow, and functions. We typically left classes for in-season because it’s not used that much in robot code, and students could just pattern-match on our previous code when writing new code.
General curriculum: Curriculum and instruction - FRC Team 3512
Intro C++ curriculum: Intro to C++ - FRC Team 3512
In my experience, students do fine with C++, even as a first language, as long as they learn modern best practices from the start. The main thing that avoids memory issues is using value types wherever you can instead of pointers, and avoiding the new keyword like the plague.
We didn’t focus on that concept much at all, actually. Basically everything we wrote used value types, so everything was on the stack and had strictly nested scope. Everything executed on the main robot thread except for our 2020 vision subsystem (NT event listener with thread-safe circular buffer to send data to the main robot thread; WPILib has a thread-safe queue now).
We used address, UB, and thread sanitizers in CI, of course, but I don’t think they ever caught any bugs. Keeping the code structure simple helped.
The main downsides are due to Java being much more popular. Java and C++ are at 90% and 5% marketshare respectively.
It is not. AdvantageKit is a library written by 6328 for 6328, and they use Java.
Check out this post by Tyler in the Photonvision thread, it’s interesting: PhotonVision Offseason Development 2024 - #14 by calcmogul
We were C++ in 2023 and switched to Python in 2024 to try a language that both mentors were very familiar with and students could pick up quickly, but the vendor support isn’t as good as Java, so there were a number of things where we either had to reach out to others for support or figure out ourselves. So we’re switching to Java like most other teams are using in 2025.
Not that C++ isn’t great to know and learn, but Java seems to be the least-friction language for FRC teams to use right now for your main season.
I’m not a programming guy, but what language you use really boils down to your team’s resources and goals. Go for it if your team has the programming resources to use a different language and maybe develop some libraries, and has a goal of using something that’s more common in an industry or doing something different than most teams. Otherwise I would say stick with Java and become more proficient with it.
If teams don’t have the resources to support something different than the norm, there is a better chance of struggling and not gaining as much experience from FRC than just sticking to the tried and true methods.
I would strongly recommend this video series
Why do you want to move from Java?
Learning C++ isn’t hard. Writing C++ without shooting yourself in the foot all the time is hard. I admit I have a personal dislike for C++ and I’d rather just write plain old elegant C. Rust has become popular for very good reasons.
This is a major change, but every team is unique and must make their own decisions. Personally, I’d at least want the following to be true:
Keep in mind that your code will become a reference for future students. How likely is the team to keep using C++ after you leave?
This is pretty much why we choose to use C++ despite Java’s dominance in the teams in our region.
Basically everyone who comes in to our team with programming experience learned Java first (whether through FRC or APCSA at their previous high school). As a result, incoming students often ask why we use C++ since their old teams all used Java, and I give basically the same response of thats what our school/university teaches. This does mean that most will spend their first semester learning C++ before really being able to write substantial code for the robot, but since they’re going to be constantly writing C++ code for class, it doesn’t really make sense for us to continue teaching a different language especially for those who don’t have prior experience with programming.
We even apparently switched over from Java sometime between 2018 and 2022. I really doubt our team had a software mentor at any point of its history, so it probably was the singular person assigned to programming just choosing what they’re familiar with.
There’s always going to be an entropy-like force pulling your team toward C++. It’s a perfectly reasonable choice to go with it.
“There are only two kinds of languages: the ones people complain about and the ones nobody uses”
~Bjarne Stroustrup (inventor of C++)
If you’re working from outdated teaching materials, sure. Modern (C++11 and later) materials avoid error-prone C-isms like manual memory management, raw array indexing, pointers, and pointer arithmetic.
Depends on what you’re implementing, because there’s some things C is bad at (linear algebra, string parsing/manipulation). For linear algebra on real-time embedded systems (where VLAs, alloca(), and malloc() are disallowed after startup), your options are:
// Option 1: void*, type punning shenanigans, and in/out pointer args
#define DEF_MATRIX(R, C) \
typedef struct matrix ## R ## x ## C ## d { \
uint32_t rows; \
uint32_t cols; \
double data[R * C]; \
} matrix ## R ## x ## C ## d;
#define DEF_VECTOR(R) \
DEF_MATRIX(R, 1); \
typedef matrix ## R ## x1d vector ## R ## d;
DEF_MATRIX(2, 2);
DEF_VECTOR(2);
void matrix_plus(void* out, const void* in1, const void* in2) {
uint32_t* rows = (uint32_t*) out;
uint32_t* cols = (uint32_t*) ((char*) out + sizeof(uint32_t));
double* out_data = (double*) ((char*) out + 2 * sizeof(uint32_t));
// ...
}
void matrix_mult(void* out, const void* in1, const void* in2) {
// ...
}
int main() {
matrix2x2d A = {2, 2, {}};
matrix2x2d B = {2, 2, {}};
vector2d x = {2, 1, {}};
vector2d u = {2, 1, {}};
// xₖ₊₁ = Axₖ + Buₖ
vector2d temp1 = {2, 1, {}};
vector2d temp2 = {2, 1, {}};
matrix_mult(&temp1, &A, &x);
matrix_mult(&temp2, &B, &u);
matrix_plus(&x, &temp1, &temp2);
}
// Option 2: Separate functions for every dimension combo
// (makes extra copies, which isn't ideal)
#define DEF_MATRIX(R, C) \
typedef struct matrix ## R ## x ## C ## d { \
double data[R * C]; \
} matrix ## R ## x ## C ## d;
#define DEF_VECTOR(R) \
DEF_MATRIX(R, 1); \
typedef matrix ## R ## x1d vector ## R ## d;
DEF_MATRIX(2, 2);
DEF_VECTOR(2);
matrix2x1d matrix_plus_2x1_2x1(matrix2x1d in1, matrix2x1d in2) {
matrix2x1d result = {};
return result;
}
matrix2x1d matrix_mult_2x2_2x1(matrix2x2d in1, matrix2x1d in2) {
matrix2x1d result = {};
return result;
}
int main() {
matrix2x2d A = {};
matrix2x2d B = {};
vector2d x = {};
vector2d u = {};
// xₖ₊₁ = Axₖ + Buₖ
x = matrix_plus_2x1_2x1(
matrix_mult_2x2_2x1(A, x),
matrix_mult_2x2_2x1(B, u)
);
}
Neither of these approaches scale well, and it’s hard to verify the correctness of equation transcriptions compared to C++.
#include <Eigen/Core>
int main() {
Eigen::Matrix<double, 2, 2> A;
Eigen::Matrix<double, 2, 2> B;
Eigen::Vector<double, 2> x;
Eigen::Vector<double, 2> u;
// xₖ₊₁ = Axₖ + Buₖ
x = A * x + B * u;
}
C11 got generics, but they don’t support non-type parameters.
While we of course use AdvantageKit on 6328, it is absolutely designed to be used by other teams (this is in sharp contrast to some of our other projects). We don’t support C++ because we have limited development resources, and right now it isn’t practical for us to spend a significant portion of our time on languages used by a small minority of our potential users.
if you’re already experienced in Java I don’t think C++ will be that hard. Personally I went from Java → C → C++, but you’ll be fine.
C++ lacks foot guards languages like Java feature, such as garbage collection, so you must learn to manage things like memory, object lifespans, dangling pointers etc… by yourself.
there are some tradeoffs:
Downside to C++: you have to manage your own memory
Upside to Java: you don’t have to manage your own memory!
Except, garbage collection causes performance issues in a realtime environment especially on a processor as low-powered as the RoboRIO.
You can work very hard (as WPILib and vendorlibs have) to minimize allocations in Java and optimize memory to alleviate garbage collection overhead, but it’s finicky and you’re working around the language.
…and now you actually are just managing memory again, and to do this correctly you need to understand how memory works.
And once you’re at that point it’s honestly easier to just use C++.
Personally I think the toughest thing about (modern) C++ for new users is that there’s like 4 ways to spell the same idioms and we get new ones every 3 years.
I actually enjoy this in FIRST robotics where I can teach students the most up to date stuff, but when people are self-teaching or reading legacy code, it can be overwhelming.
For two main reasons
I have also wanted to learn a lower level language for a while and have been putting it off, and this is a great opportunity to finally do so
After considering it for a bit, I’ve decided that the best course of action is to learn C++ for the next couple of months on the side, and see how it goes. If it goes well then my team will be taught C++.
In the meantime we’re going to continue to use Java, which means we will probably not be using C++ until next year. So they’ll be fine.
First of all, thanks for the resources. will definitely use them.
From my research it seems like only one library (akit 
) we’re using is not supported in C++, so it’s manageable.
I’ve come to learn that C and C++ are very different.
From an Economics viewpoint, every choice to spend resources (time, money, space, etc) on “Thing X” comes with an implicit choice to not spend them on any other Thing.
So, is switching programming languages a better Thing than all the other, to be left undone, Things you might alternatively do with your (limited) resources?
Hopefully your team has done goal-setting to help guide them in this decision.
These are good reasons.
C++ isn’t that much different than java. It’s certainly easier to transistion from Java to C++ than from Python to C++
Keep us updated on how it goes!
Side note - are you running into performance limitations? I wonder what you’re doing that’s causing those limitations. Maybe I should look at our memory/CPU usage…