Compact rio not being able to use C

[Pat Fairbank]

Originally Posted by slavik262

I realize the base code will compile in C++ if you can compile in C. However, I'm looking forward to using the features presented in C++ that aren't in C such as being able to use Object-Oriented Programming techniques and templates. My question is: will we be able to write/compile code in C++? I thought that this was the case.

If the base code will compile and run in C++, I don't see why you wouldn't be able to use OOP and templates; it all just crunches down to machine code in the end.

If I were to speculate, I would guess is that the base functionality provided by FIRST will all be in C, but teams will be free to write their extraneous code in C++ and just interface it with the C base code.

[Greg McKaskle]

Originally Posted by Michael Hill

I haven't done much work with Compact RIO, but can you not use Code Interface Nodes with them?

CINs are ancient, and new platforms like cRIO do support the Call Library Function node, which will call vxworks .out files.

Greg McKaskle

[Greg McKaskle]

Originally Posted by slavik262

I realize the base code will compile in C++ if you can compile in C. However, I'm looking forward to using the features presented in C++ that aren't in C such as being able to use Object-Oriented Programming techniques and templates. My question is: will we be able to write/compile code in C++? I thought that this was the case.

Some of the cutting edge C++ stuff may be a bit rough, but the LabVIEW code base contains plenty of C++, and it runs there. As usual, bringing in arbitrary C++ code can run into rough spots when deciding whose STL implementation to use, or doing lots static initializer stuff, etc. But the short answer is, that it is a C and C++ platform via Wind River tools, and a LabVIEW platform via NI tools.

Greg McKaskle

[Michael Hill]

There's nothing wrong with the CINs being ancient. They still work...and allow you to access compiled C and C++ code. I haven't used a Call Library Node. Most of the code I use at work was already written for use with CINs.

[Greg McKaskle]

Originally Posted by Michael Hill

There's nothing wrong with the CINs being ancient. They still work...and allow you to access compiled C and C++ code. I haven't used a Call Library Node. Most of the code I use at work was already written for use with CINs.

Correct. There isn't anything wrong with being ancient, but being ancient is one of the reasons they aren't supported on new platforms. To give a bit of history, CINs were invented when LV was still on the Mac, and there wasn't a good choice for dynamically called binary code -- no DLL-like entity. Since they were being constructed, a number of other bells and whistles were added to them.

Around six years later, when CodeFragments on Mac, and DLLs on Windows existed, the CallLibrary node was added. In some ways it is superior to CINs, in other ways, it was a bit lacking since it was defined industry-wide, and not inside the LV team. In the fifteen years or so that have passed since then, both have been maintained and reworked. In the next release, NI will no longer ship any VIs containing CINs. Over the year, as code is touched for some other reason, it has been moved to CallLib nodes, but we still support them because customers have written them, and don't necessarily want to spend the time taking their C code to a new library format. If it works, why change it.

On the other hand, new platforms, like cRIO can't use existing CINs. They require the C code to be recompiled for a new OS anyway. This will require reworking the make file, the header includes, dealing with little nit picky C stuff that was marginally compatible. So while doing that, we think it is better to move from CIN libs to .outs, .DLLs, .frameworks, .libs, or whatever the platform preference is for shared binary code.

And that is the state the cRIO is in. It supports external binary code written by you, by the OS vendor, by third parties, etc. It does so in a standard way rather than the twenty-x year old proprietary way that LV invented.

That was why I called them ancient, and that is why the cRIO doesn't support CINs. Ancient doesn't necessarily mean bad, but ancient things do fall out of use, otherwise I'd be tapping this out in morse code or writing it in Latin.

Greg McKaskle

[ttldomination]

I attended the seminar that they had at World, and the people in the seminar said that we would hav a chance to program in either C, C++, or Labview. So there are 3 programming options.

[slavik262]

Originally Posted by Greg McKaskle

Some of the cutting edge C++ stuff may be a bit rough, but the LabVIEW code base contains plenty of C++, and it runs there. As usual, bringing in arbitrary C++ code can run into rough spots when deciding whose STL implementation to use, or doing lots static initializer stuff, etc. But the short answer is, that it is a C and C++ platform via Wind River tools, and a LabVIEW platform via NI tools.

Greg McKaskle

I don't use STL all that much anyways. I prefer to write my own data structures and such. That way I can fix my own compatibility problems. I'm just excited to be able to play with dynamic memory allocation and OOP.

[BradAMiller]

Originally Posted by Pat Fairbank

If the base code will compile and run in C++, I don't see why you wouldn't be able to use OOP and templates; it all just crunches down to machine code in the end.

If I were to speculate, I would guess is that the base functionality provided by FIRST will all be in C, but teams will be free to write their extraneous code in C++ and just interface it with the C base code.

Actually it's the opposite. To make C++ work really well, the libraries have been developed as a series of classes that implement all the sensors, motors, etc. Then the idea is to add C wrappers around the class methods (functions). We're currently trying to decide if the wrappers are really necessary since one could write the entire robot program using only C code except when calling the methods for those sensors and motors. And even that looks a lot like C. The upside for not doing the wrappers is that it allows the C++ code to be much more flexible and easy to use.

Any thoughts?

Brad Miller
WPI Robotics Resource Center

[AustinSchuh]

Originally Posted by BradAMiller

We're currently trying to decide if the wrappers are really necessary since one could write the entire robot program using only C code except when calling the methods for those sensors and motors. And even that looks a lot like C.

My reaction is that if you would be wrapping C around C++, why even bother? I am sure teams can adapt, or write their own wrappers around what they use if they feel so inclined. In short, I think wrappers aren't necessary and the time spent writing them could be better used in other places, like documentation.

Just wondering, but if you did write wrappers, would you then still use the C++ compiler, or would you use a C compiler instead? How would wrappers work in this case? I typically see wrappers used the other way, wrapping C code up to use in C++, which is why I am curious.

[Pat Fairbank]

Originally Posted by BradAMiller

Actually it's the opposite. To make C++ work really well, the libraries have been developed as a series of classes that implement all the sensors, motors, etc.

Even better, then. Will these classes expose virtual functions so that teams can subclass them to extend their functionality?

Originally Posted by BradAMiller

We're currently trying to decide if the wrappers are really necessary since one could write the entire robot program using only C code except when calling the methods for those sensors and motors. And even that looks a lot like C. The upside for not doing the wrappers is that it allows the C++ code to be much more flexible and easy to use.

I don't really see the point in wrapping the method calls in C. Since writing code for the new controller is going to involve learning a new interface for I/O in any case, there's no argument to be made for preserving familiarity. Since C and C++ code will be compiled automatically by the same compiler, there won't be any build issues for those who choose to program in C.

I guess what is boils down to is whether there are teams who will choose to program exclusively in C and who would be confused by the C++ syntax. I can't answer for others, but my team may or may not decide to use C++, depending on how comfortable our students are with C. In either case, we'll already be taking advantage of having a C++ compiler to eliminate some of the shortcomings of C, so calling methods on a class for motors and sensors won't bother us.

[BradAMiller]

The question was, as you noticed, one of familiarity with C++. One could write the entire program using C syntax except for creating and invoking methods on objects. The syntax isn't a huge stretch from what a C programmer would know, but we're trying to be very sensitive about forcing people to learn a whole bunch of new stuff in this transition year. I was trying to get a feel if the community would be up in arms over being forced to use those few pieces of C++ syntax.

Brad Miller

[slavik262]

Originally Posted by BradAMiller

The question was, as you noticed, one of familiarity with C++. One could write the entire program using C syntax except for creating and invoking methods on objects. The syntax isn't a huge stretch from what a C programmer would know, but we're trying to be very sensitive about forcing people to learn a whole bunch of new stuff in this transition year. I was trying to get a feel if the community would be up in arms over being forced to use those few pieces of C++ syntax.

Brad Miller

Not at all. I personally think that anybody fairly well-versed in C could pick up the C++ syntax quickly.

[Nibbles]

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.

[Greg McKaskle]

I really don't want to get sucked into a language discussion, but let me throw in a clarification.

NI has never supported anything besides LabView on it's hardware, until now.

The cRIO is a relatively new HW platform for NI, and to this point, it has indeed been exclusively a LV platform. But, NI sells a number of other HW platforms such as PXI, as well as supporting third party HW from PC vendors, embedded platforms, even handheld devices.

Greg McKaskle

[Mike Mahar]

Originally Posted by BradAMiller

Actually it's the opposite. To make C++ work really well, the libraries have been developed as a series of classes that implement all the sensors, motors, etc. Then the idea is to add C wrappers around the class methods (functions). We're currently trying to decide if the wrappers are really necessary since one could write the entire robot program using only C code except when calling the methods for those sensors and motors. And even that looks a lot like C. The upside for not doing the wrappers is that it allows the C++ code to be much more flexible and easy to use.

Any thoughts?

Brad Miller
WPI Robotics Resource Center

I program in C using a C++ compiler every day. Sometimes we use a C++ feature and we're doing it more every day but often our code looks just like a standard C program. I wouldn't bother putting C wrappers around your classes. If the only issue is calling the class's member functions, Almost anyone can learn how to do that. Provided it is described in the WPILib documentation.

How close is the new library to existing WPILib? I want to get my team up and running as soon as possible and I was wondering if it is worth it to learn the old WPILib on the old controller?