I wrote to the WPIlib team concerning the features available to both Labview and C/C++. It seems as though they are fully committed to offering an almost identical layer of abstraction in Labview/C/C++. With windriver's supposed debugger, it seems as if the only advantage of using Labview would be the Graphcial programming (which is not that much of an advantage to some people):
Quote:
LabVIEW has an extensive library of code included with it. We are trying to get all the relevant stuff ported to C/C++ so it will be accessible to both languages. For example, selected parts of the Image Processing library is being ported as we speak. That will give teams access to most of the vision code in either language.
C++ will be well supported with classes for each type of device, sensor, and robot abstraction (like driving). Each of those classes will also be on the LabVIEW palette.
The C/C++ default code will be through the library. Since most of the heavy lifting is being done by hardware, the library provides a pretty thin framework. Most of the complex stuff is around driver station – field - robot communications like support competitions, i.e. autonomous/teleop, enable/disable and Driver Station. So the philosophy is that you write programs “from scratch” for the most part, except that there is a rich set of classes (and functions in C) to handle device support.
Since the source code will be available, you’re free to modify it if you feel that is required. But we’re trying to make the programming interface pretty non-intrusive. The goal is for it to never get in your way from doing what you need to.
|
Between the Open Sourceness, Windriver Workbench, the chance to learn C++, and the ability to continue using Subversion (our versioning system of choice), It's fair to say we will be using C++.