I am in the process of porting our FTC library to use RobotC 3.5 and found the following bug:

work around if you haven't tried it


writeDebugStream always expects a format string;

A format string is still a string even though there is no substitution parameters in it. In true ANSI-C, this is acceptable. Besides, this code was working in the previous RobotC version.

yeah, but even though they say 'ansi-C' I don't think anyone really expected it. I hope they never do go pure ansi-c. I'd hate to lose the C++ features they snuck in.

I'll make a note of this one, thank you both very much.

I wouldn't want to give up the C++ extension either but there is a difference. In general (i.e. not in this particular case), having extensions compliant to standard C++ is fine but having an existing C feature that is not compliant to ANSI syntax may not be a good idea especially for beginners because they will learn it wrong. When I teach our students RobotC, I always mention the departure of RobotC to ANSI-C so that they understand what to expect when using standard ANSI-C out there in the future. So explaining to them a certain features are C++ extension is not a problem since they will probably learn C++ too. But explaining a certain syntax that is non ANSI compliant is something I want to avoid.

PS. I wouldn't mind if they go full bloom C++ either. That will make our library one and the same for both FTC and FRC

true, and agree.

writeDebugStream is not in ansi-c. I think the hope that robotC remain backward compatible is more of a justification. But with changes as major as new pointers, and a very easy work around, I can see how this could receive a low priority, maybe even be in a 'dropped' category, although john indicated they would look at it.

There are many elements missing from ansi-c, so I didn't take the statement 'ansi-c' literary, more of a marketing spin of 'more ansi-c like'. I think that's fair, no?

If we REALLY wanted to be 100% ANSI-C, I guess we should get rid of the "bool" type since that wasn't in original C...

Anyways, we've actually fixed this issue. We're striving for ANSI-C is the goal, so if you find other things like this, we'll be happy to take a look and address it if at all possible.

We feel that the 3.5 update isn't 100% ANSI-C, but it's the direction we're headed and we feel we're making good progress.

Fair enough. We really appreciate you guys put in the effort of making it as ANSI-C compliant as possible. It would really help the kids to learn the language. Can't wait to see how it goes when I try passing function pointers to a function

Yeah... that one feature might still be a while away.

Oh, are you saying function pointer is still not supported in RobotC 3.50? Hmm, that means I can't do event notification callbacks! It also means I can't do a true task manager that allows multi-task registration. Please confirm so I won't start porting the code in that direction only to find it not supported.

Thanks.

I tried compiling my old robot code using the FTC library with RobotC v3.50 tonight. It seems my library is totally broken
The brick is hung during initialization. The first time I started RobotC v3.50 that automatically loads the last project, it always crash the first time, but then when started it again, it will say detected RobotC not properly shutdown and will recover, then it started fine. It looks like it will be long nights in the coming weeks.

There is no way to have a pointer to a function with ROBOTC 3.50 - Nor is one currently planned.

The external explanation might be something like “This is a problem with all systems that use a Harvard architecture where programs are stored in a separate memory space than RAM.” NOTE; both Microchip PIC and Atmel AVR are Harvard architectures and have language extensions to support “pointers” to flash memory space.

The real reason is that it’s a lot of work and won’t make it into this release pool (3.5x). A lot of work means the current symbol type has many sub-classes of symbol type entries – variables, typedef, … -- and pointers to procedures is not something that it can handle easily. Yet.

If you can isolate the issue, we can look into why it is locking up the brick.

As for the registry toggles, you could go into regedit and take out the following key:
HKEY_CURRENT_USER\Software\Robotics Academy

When 3.50 came out, I was planning to fix 3 things in the FTC library:
1. Currently, all event callbacks are hard coded function calls in various object modules. So even if the caller of the module does not need event callbacks, it still have to provide a stub callback function doing nothing. With function pointer support, I thought I could pass the callback function pointer to the object's initialization function so that if the function pointer is NULL, then there is no callback. If there is, then it will do an indirect function call through the function pointer when the event occurs.
2. Currently, for all object modules in the library that require periodic callback (e.g. the gyro module needs periodic callback to do the integration for the robot heading), the module must provide a "xxxTask" function and the caller of the object module is required to call this xxxTask function in its main loop. If the caller forgot to do this, the gyro wouldn't integrate, for example. It's a subtle mistake that trips the students. With function pointer support, I could have a TaskManager providing a "task registration" API. The object module that requires periodic callback will register the callback function as a periodic task during its initialization. The main task template will have a single call to the task manager dispatcher in the main robot loop. The dispatcher will sequentially call each registered task. This will free the students from having to remember which object module has a periodic task and must be called in the main robot loop.
3. Currently, if an object is embedded within another object (e.g. the PIDDrive object contains two PID controller objects), there is no way to pass the pointers of the two PID controller objects to the PIDDrive object. So a global array of PID controller objects are created and the indexes to the array are passed to the PIDDrive object instead. With pointer support, this ugliness will go away.

So on the bright side, since function pointer is not supported, I can't do 1 and 2 so it is much less work now.