- My oldest CCS manual is 2003 and #ELIF is in it.  Also in 2009, 2011.
- Anything to do with printf isn't an issue--at least for me--as I've
avoided it since the earliest days.  I'd think anyone concerned about
efficiency in other parts of the code wouldn't want to use it, either.
Maybe this has changed in the last decade.
- Constructs that force you to use uncomfortable syntax are unfortunate, bu=
t
don't really hurt the program.
- The rest...well, CCS isn't the best you can get, but it is good enough fo=
r
a lot of things.  Encryption algorithms aside, the processors keep getting
faster anyway.

My two cents. Worth at least half that.
Barry



On Wed, Jul 13, 2011 at 6:06 AM, Isaac Marino Bavaresco <
isaacbavaresco@yahoo.com.br> wrote:

> Then as of 2009/08/29 I wrote:
> The main shortcomings I found are:
>
> - No #elif;
> - Passing constant strings to functions first copy them to RAM;
> - Crippled heap functions (maximum block length of 127 bytes);
> - sprintf accepts only one variable (so not exactly a varargs list)
> argument to be printed. Besides, the format specifiers are very
> restricted and it can print 16-bit numeric values only. For 32-bit
> values there is a sprintf32;
> - It is not clear if it has a "printf" function, it has a lprintf which
> prints to an LCD;
> - Variables declared with the rom storage specifier can only be accessed
> through the [] operators;
> - rom variables can be used with char data types only;
> - A rom pointer is internally limited to 8-bits: the constant array size
> is thus limited to 256 elements
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.