On the quality and complexity of software within FRC

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

Interesting. The C++ version always gave me the impression that it was written by someone who really wanted to be writing Java.

That's funny, because I always get the impression that the Java libraries were written by a C++ developer.

[wireties]

Originally Posted by notmattlythgoe

That's funny, because I always get the impression that the Java libraries were written by a C++ developer.

Pretty common in embedded environments.

[SoftwareBug2.0]

Originally Posted by notmattlythgoe

That's funny, because I always get the impression that the Java libraries were written by a C++ developer.

It could be both . For best results, assign someone good at Java to do the Java version and a C++ expert to do the C++ version. For "interesting" results asssign the Java guy to do the C++ and a C++ guy to Java.

Anyway, here are a few of the reasons that the C++ looks like somebody wanted to write Java:
-Pointers to stuff passed around without specific notes about ownership
-Abstract base classes used like Java's interfaces in places where templates might be more appropirate
-Virtual fuctions overused
-Types that can't be used like normal C++ variables because they don't have copy or assignment operators the rule rather than the exception

What C++isms do you see in the Java version?

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

It could be both . For best results, assign someone good at Java to do the Java version and a C++ expert to do the C++ version. For "interesting" results asssign the Java guy to do the C++ and a C++ guy to Java.

Anyway, here are a few of the reasons that the C++ looks like somebody wanted to write Java:
-Pointers to stuff passed around without specific notes about ownership
-Abstract base classes used like Java's interfaces in places where templates might be more appropirate
-Virtual fuctions overused
-Types that can't be used like normal C++ variables because they don't have copy or assignment operators the rule rather than the exception

What C++isms do you see in the Java version?

Underscores, underscores everywhere.

[Thad House]

Whats also great about the WPILib is that whenever you initialize a digital port, delete it, and create a new one, the HAL leaks 6 bytes. Now since many teams don't do this, its not a big deal, but still, its a little odd that an official program has a memory leak, even if it is such a small rare one.

[faust1706]

Originally Posted by Thad House

Whats also great about the WPILib is that whenever you initialize a digital port, delete it, and create a new one, the HAL leaks 6 bytes. Now since many teams don't do this, its not a big deal, but still, its a little odd that an official program has a memory leak, even if it is such a small rare one.

Has anyone run valgrind, or something similar, on as much of the WPILib as they could?

[SoftwareBug2.0]

Originally Posted by faust1706

Has anyone run valgrind, or something similar, on as much of the WPILib as they could?

I don't how much people have tried it but the version from here has a static assert that's basically sizeof(void*)==sizeof(int32_t).

[Peter Johnson]

Originally Posted by Thad House

Whats also great about the WPILib is that whenever you initialize a digital port, delete it, and create a new one, the HAL leaks 6 bytes. Now since many teams don't do this, its not a big deal, but still, its a little odd that an official program has a memory leak, even if it is such a small rare one.

Note that at the HAL level, freeDIO() is the opposite of allocateDIO(), and not the opposite of initializeDigitalPort(). The initializeDigitalPort function allocates the memory you're talking about, and was only intended to be called once (ever) per port, with the caller being responsible for saving the resulting pointer across multiple uses. The lack of an uninit function to free the memory in question is admittedly poor API design, but it's worth noting that the higher level WPILib classes use the HAL consistent with the above (call init once, then just use allocate/free), and thus have no memory leaks in this case even if you create/destroy multiple times per port.

I've found that the WPI folks are very welcoming of patches... I'm sure a patch to add appropriate uninit functions to the HAL would be accepted in short order.

[Thad House]

Originally Posted by Peter Johnson

Note that at the HAL level, freeDIO() is the opposite of allocateDIO(), and not the opposite of initializeDigitalPort(). The initializeDigitalPort function allocates the memory you're talking about, and was only intended to be called once (ever) per port, with the caller being responsible for saving the resulting pointer across multiple uses. The lack of an uninit function to free the memory in question is admittedly poor API design, but it's worth noting that the higher level WPILib classes use the HAL consistent with the above (call init once, then just use allocate/free), and thus have no memory leaks in this case even if you create/destroy multiple times per port.

I've found that the WPI folks are very welcoming of patches... I'm sure a patch to add appropriate uninit functions to the HAL would be accepted in short order.

However, if you don't keep the same digital input, and instead go new, it does initialize a new digital port. So calling
Talon t = new Talon(0);
t.free();
t = new Talon(0);

Leaks the memory. Because InitDigitalPort always returns a new digital port, instead of reusing an old one. At least on the java side. And t.free() does not actually release the digital port structure.

I have a few bugs I plan on submitting to WPI that I have found.


I do want to say thank you for doing the python port. I have been able to use that for some help as well, and am implementing the DotNet simulator to use a dictionary similar to the python one, and it should be directly compatible with the websim api.