NI has never supported anything besides LabView on it's hardware, until now.
<ins>Hm, I can't find my source for where I saw this, I think it is more accurate - better to be conservative - to say NI has not extensively supported this type of programming on this type of hardware before FIRST, at the very least. I was aware there
were articles published on calling shared/dynamic object code from LabView, though I am not sure to what extent it is used in reality. In addition, NI is merely supporting the C/C++ effort, it is
WPI doing the development of the library.
In addition, I completely forgot about interrupts writing this post, and how that will be handled (it shouldn't matter as far as C vs C++ is concerned, however, LabView changes it up because it supports interrupts seamlessly and natively, so LabView could be appealing for teams who want to take advantage of those features and not spend hours in front of a C or C++ debugger which probably won't even work well in a real time environment.</ins>
On the topic of C versus C++, I think this post by Linus Torvalds to the linux-kernel mailing list is entirely relevant:
http://kerneltrap.org/node/2067 His full post is about halfway down the page.
He talks about using C++ to write operating system kernels (FRC programming is for embedded systems, roughly equivalent), and how it is a "BLOODY STUPID IDEA". That isn't the point I will jest at though and I am not supporting one over the other (frankly I don't like the NI-RIO at all, even if it does improve on some things, like floating point math), rather, I point out the fact that they are more or less the same, difference being that C++ has made things much more easier (or as Linus points out, worse for some areas of programming where even moderately high level programming is bad, e.g. operating system kernels).
C has most all of the stuff C++ does, most coders don't realize it though. Structs are the same thing as classes, and can (with work) be inherited, and polymorphism is (roughly) supported with function pointers. C has functions that operate on structures (function(object, arg)), C++ has methods that operate on structures (object.function(arg)).
C++ just has member visibility, operator overloading, and extended function names (so you can define multiple functions with the same name but different arguments).
It is hard but entirely possible to create byte code that has both a struct-and-function interface for C and (formal) OO interface for C++.
There is no reason not to use the OO interface using C++, it is simpler, memory management becomes easier, and error handling with Exceptions improves code cleanliness. Unfortunately, if we go all out on C++ (as opposed to using OO and Exceptions sparingly), it makes it difficult to write plain old C if you are intent on doing your own memory management and error handling.
We aren't working with kernels or doing data mining or multi-threading, and are working on a UNIX-like OS (thankfully), so C++ imo is perfectly adequate. I am more worried about people not being able to deal with malloc and free, say, in C more then I am the OO features of C++. OO is pretty simple to grasp if you are only using it.