Hi,

It seems to me that robotc is developed as a safe subset of ANSI like the ones used for the development of embedded applications.

Am I right?

If yes where could I found which commands and funcitons are not available?

This is not a topic for myself only, I assume that as I am using robotc afor my dissertation, there will be more students or programmers that need to know that, so it would be great to have a topic which list all the omitted commands (like malloc which is omitted from robotc).

Regards,
Giannis

Good question. Hope you find the following clarifcation useful.

Yes. The general intent was to develop a safe and nearly complete subset. The result of this was the initial exclusion of anything related to 'pointer' types from the language. Hence no pointers and no memory allocation functions. The primary market for ROBOTC is educational use and the primary users are generally novice to intermediate level users. This is a difficult topic to teach and very difficult to protect against software errors.

A corollary of the lack of pointers is that ROBOTC naturally has difficulty with function arguments of type "void *".

A limited subset of pointer functionality has recently been added to ROBOTC for those platforms -- including the NXT -- with adequate processing resources (primarily memory) to support the larger firmware file involved. Dynamic memory allocation (i.e. a heap) is not available. [Note: on the NXT platform, ROBOTC is built upon the open source code released by LEGO which does not include a heap].

Another (currently) unsupported "unsafe" feature is the "..." operator -- i.e. variable length argument lists is not supported.

A few other minor differences from the strict C standard.

A small difference from C is that all variables in ROBOTC are "signed". The "unsigned" keyword is accepted in programs but the compiler will generate a warning indicating that "unsigned" keyword is ignored.

ROBOTC is an interpretative language. This means that an end user program is compiled into an intermediate object file which is incrementally downloaded to the robot controller. The main firmware is downloaded once to the robot controller and contains an interpreter for the intermediate object code. The implication of this is that all "standard library" functions are included in the main firmware; as such ROBOTC supports a popular subset of the standard library functions because of the memory limitations of the controller. Including the complete library in the main firmware would increase the main firmware size and reduce the available memory that holds user programs. If there are useful library functions that you'd like to add, please post a message. Previously several library functions have been added to ROBOTC based on user requests.

ROBOTC utilizes the flash memory "file system" included in the LEGO open source firmware. The interfaces to this provide similar file access functionality but are not totally compliant with the standard C library. For example, on the NXT, there is no equivalent to the "stdin" and "stdout" files.

The size of an "int" variable is implementation dependent in the ANSI C standard. In ROBOTC "int" are16-bits whereas in most large systems (Windows, mainframes, ...) it is usually 32-bits. Many embedded systems , and not just ROBOTC, use 16-bit as same of 'int'. A few users have experienced arithmetic overflow in calculations where the use of a 32-bit 'long' variable is more appropriate precision.
ROBOTC has some useful language extensiions found in C++. Most notably these include:
1. The ability to declare function "overloads". I.E. several functions declared with the same name where the ROBOTC compiler finds the best fit when function is called.
2. The addition of a "string" type to the language.
3. Allowing "const int nValue = 5;" as an alternative to "#define nValue 5".
4. Stronger type checking validation.
5. As an alternative to use of pointers for function parameters, ROBOTC allows for call by reference parameters denoted with the "&" keyword in the function declaration.

There are some standard language "limits" that are smaller in ROBOTC. A couple of examples. The standard allows for up to 12-dimensional array, ROBOTC currently supports only 2-dimensional. The standard allows for up to 127 parameters per function which is more than the ROBOTC limit. In practice these have not found to be significant limitations.

The ANSI C standard (see for example http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm) is over 600 pages long and has several versions. I'm sure a close read will find other minor discrepancies.


All available commands/functions in ROBOTC are found in the leftmost pane in the main ROBOTC window. You only get a subset of these commands if the "user menu level" is set to "basic" so be sure to set it to "expert" level.

Dick,
I don't think that this is correct.
1.) What is "educational use"? Is it use by 10 years old pupils or by 25 years old informatic students?
2.) for use at highschools or universities: why shouldn't those maybe 17 to 25 years old pupils or students learn to handle with pointers?
3.) compared to Java (LeJos, NXJ) a C-based language should have the same abilities
4.) if someone decides to develop a software he wants to sell, this software has to be designed to more professional needs than a freeware does (e.g. NQC or NXC, which are also good for educational use)
5.) no real novice will decide to BUY any C-like software if any freeware is available with nearly the same programming features. Your customers never have been novices and never will be!