RobotC/Convex/EasyC pushed to the limits

I didn’t want to derail the “Robot C wishlist thread”

Some of the posts want faster VMs, better code creation, less memory use, etc.

Some are asking for full C++ extensions

I’ve done microcontroller programming for years (some on processors older than most of you). Once I got tasks from RobotC, I’ve not come across things that the language implementation couldn’t do that I wanted it to do. I look at these CPU’s as being elegant little engines, capable of doing lots. I see them as controllers, not as things that need to be able to produce a full 4K graphics stream out to an attached monitor.

I can see wanting “objects”, but I can do that with structs and some code. So I’ll give you that one.

So, other than things that the programming languages are limited by the Cortex ability (speed, memory) what have you wanted the programming languages available to do that you were not able to do?

RobotC simply hides many lower level codes and provides you with some interfaces, it only enables you to program in abstract logic and calculation, and exceptions like memory leak will be handled by the VM. It is safe and stable, and prevents many serious error. On the other side, not all the interfaces are open to users, and the vm slows down the performance which is already poor as a microcontroller.
Now I want to the access flash memory in the cortex, it will be useful to save data, but unfortunately for some reason the file IO is not available in robotc. This is not limited by the cortex ability, but the language itself. (I know jpearman made a rcfs lib, but the lib still can’t delete files)

@lpieroni Umm, how does Win10IOT factor in to the question I asked?

That was a question about the RobotC compiler’s OS compatibility. I think I meant to post that in the other thread, but I wasn’t paying attention to where I was posting.

If people are looking to use C++ with the cortex, I know ConVEX is capable, maybe even PROS too. For the past two years my team has been using C++ with ConVEX. Things like namespaces, auto variables, and references have been nice to have handy, and we’ve also used things like classes and templates as well, with no significant effect on performance.

any sensible makefile for small embedded systems (this includes PROS) will disable rtti and exceptions for C++
this makes it equivalent in performance and code size to C, even when enabled the difference in performance is marginal, and if you want exceptions and still care about performance then use noexcept

Multidimensional arrays don’t seem to work past 2D. Having 3D and 4D arrays would be nice.
I guess a series of arrays of pointers to arrays (and repeat to add dimensions) would work, but that’s not nearly as clean.

Ok, so I’ve used 2d arrays on a bot, tell us how you wanted to use 3d and 4d arrays and RobotC stopped you.

I tried to use 3D and 4D arrays with a series of target values for a PID controller. I was writing code for a robot I had designed but never ended up building with a catapult and a rubber band tensioner. I implemented a lookup table for the distance the rubber bands would be stretched with different values based on the number of cubes and stars as well as the distance and angle to the opposite far zone. Each of those values was one dimension in the array.

It’s not a problem 99% of the time, and there are alternatives for the other 1%, but it would be nice to have the support for multidimensional arrays.