So our team has decided to switch from LabView to C++ this year. As a programmer, I wanted to know if there was any advice people had to give me on major differences in the two languages that may throw us off when programming a robot (other than the fact that one uses VIs and the other uses text).
Many thanks,
E Dawg
The biggest difference is that C++ is a very sequential procedural language. To do things in parallel is certainly possible, but is a bit more effort and a bit more dangerous.
Arrays in LV are autosizing, arrays in C++ aren’t, but you can use vectors or other types that are more like LV arrays.
The debugging tools in LV and C++ are quite different.
The NI Vision libraries have both C and LV entry points, but the C++ WPILib doesn’t do a very good job of bridging to the vision libraries. It seems to be a bit of work to get the camera image into an object that you can easily send to the CVI Vision functions.
And of course the obvious text is keyboard and graphics is mouse.
Greg McKaskle
All of these are very superficial differences,
To get through the parallelism issue you can easily use the Command-Based Template that WPI provide and you’ll be good to go.
I would say one major thing in the decision is whether you have prior experience with C++ or Java, and if you’re comfortable with it…
One of the things that really amazed me was the code deploying time difference between Java/C++ and LabView!
Besides, I really liked the organised OOP approach that WPI took with the Command-Based Template, and it’s one of the thing that got me hooked, besides the fact that IMO LabView’s messy and non-organised events order really took slowed down our work this year…
I was trying to list out some differences in the languages. I wouldn’t call them superficial.
Build time is not a language difference, but a valid tool difference. And there were indeed bugs in last year’s LV deployment tools that in some cases caused embarrassingly long deployments. Those have been corrected, at least the worst of them were.
On the parallelism topic, command-based code is I believe always cooperatively scheduled. I was referring to threads as a relative comparison. And it is true that preemptive parallelism can cause race conditions, or worse if the data objects aren’t protected.
I’m not trying to argue which is better. I was hoping to assist them in discovering the topics they should study in order to learn C++ once they know LV. I’d like to see more teams learn multiple languages, and knowing the differences is a key aspect of that.
Greg McKaskle
How do you mean?
I see many C++ teams doing debugging using only print statements. But if you can get the debugging protocols running, you can have some pretty nice tools.
The basics – breakpoints and pause/resume – are present in both. The C++ equivalent to a probe is a watchpoint. C++ doesn’t have panels that you can open, but you can use watchpoints or print statements. If you get fancy, you can instrument the code to place some important values to SmartDashboard.
Fancier tools such as profiler are not as commonly used, and I believe you have it in the WindRiver tools that come with FRC. Even fancier tools such as tracing are again available in both, but I’m not sure if FRC WindRiver contains it.
Greg McKaskle
Wind River hasn’t given us remote debugging licenses for the past couple years 
Why not?
They probably forgot (or have some other reason not to) to package it when the cRIO FRC-II came out. The licenses are per-CPU type and the cRIOs have different CPUs. I think the license for the old cRIO is still included.
Although your probably right that most C++ teams just use print statements, that is more of a problem with the teams than the language. If you take the little amount of time to time to learn how to do it, the smartdashboard can be easily used for debugging and displaying values. In fact, if you use robotbuilder, a lot of these debugging tools can be included in your code with just the click of a checkbox. The problem is that teams just don’t usually realize its that easy, while with LabVIEW those tools are pretty hard to miss.
Thanks guys.
Also, what is the most challenging problem that you have encountered with C++? It would be good to know now so that we can address it before build season starts.
Setting up the environment. That was our biggest struggle. If you follow the steps outlined here (word for word), it should be all good 
It took us about half the build season to find that. Once you’re set up and the cRio has the C++ image, the template code in WindRiver is more than good enough to get you started. One other problem we had was keeping up to date with the updates throughout the season. You don’t get much (if any) warning, so check FirstForge every so often and make sure you didn’t miss anything. If you get to the competition and forget to get the updates, there’s usually someone with all the updates on a flashdrive willing to share with you 
[edit] also, it can get pretty frustrating if you don’t specify module numbers when initializing stuff. If you’re sure everything is set up right (the driverstation says the cRIO and robot radio are GOOD), try switching the module numbers. It defaults to the first module available, but that’s not always the one you’re using (like many cases when using an 8 slot cRIO). Normally you don’t need to specify.
something=new thing(module_number, port_number);
Not sure how much experience you have with C/C++ outside of FRC, but understanding pointers and how they work will be essential for all members of your programming team 
The whole programming team has at least some experience with C++. I have a basic understanding of pointers, so that is good. Is there anything about them that I should know specifically for FRC programming?