This is starting to be a Hitech-CCS(or ANSI-nonANSI) comparision and please don't get me wrong 'bluex' I just express my opinions about both and thank you for your contribution.
Ok let's see:
What I like in (Hitec or other compilers writers) Compilers in searching to be ANSI compatible is that the rules that manage the name, and the variable sizes are the same. When you use an "int" it's always the 2 times the size of the minimum data unit, in the case of PIC it"s a byte then INT=2 bytes... in 68000 it's 16Bits so INT=32 bits ...
The ANSI standart says that "each compiler is free to choose appropriate sizes for its own hardware, subject only to the restriction that SHORTs and INTs are at least 16 bits, LONGs are at least 32 bits, and SHORT is no longer than INT, which is no longer than LONG". You can check the book "The C Programming Language" by K&R. In my point of view ANSI is not a good standart here because of the hardware it is standartised for. Most of the time I use "int"s for counting registers which are mostly enough to be represented by a byte. Also most optimized code size is the case with 1 byte int for a 8-bit uC's as it should be for other cases(16,32 bit cores). When I had to use an ANSI compiler I use the
typedef unsigned char int8;
directive to not to get confused. Also the "int8, int16, int32" are the non-ANSI keywords for the CCS compiler which declare an integer number for corresponding bits.
The problem with CCS, is that they FULLY DO NOT conform to any standard ... their compiler is even the only "C" compiler I have seen that is not Case sensitive ... they added a directive to let you force it to be case sensitive, but the problem is that their manual says that not ALL HEADER FILES AND EXAMPLES are written with case sensitivity in mind ... witch can be very very dangeourous ...
Yes they DO NOT conform to any standart but I think being non-ANSI is enough to be out of standarts as there aren't many more standarts other than ANSI. And they don't claim to be ANSI. Compiler can be made case sensitive with the "#case" preprocessor command but not case sensitive by default as you say. But the keywords are always case sensitive that's a fact. Also I always build my projects with the "#case" command and didn't get into any trouble with their "HEADER FILES AND EXAMPLES" even they say that they may not be case sensitive. Only a problem with the IO PORT "C" mixing with the carry flag "C" in the case sensitive mode but that was not a big problem for me.
Another thing I like in Hitec compilers is Pointers to Functions ... this makes it easy to develop Real Time Operating Systems.
I agree with you but I can multitask many programs by using interrupts and never had the need to multitask so far but if it is needed CCS has a RTOS embedded in the compiler. And last but not least CCS DO SUPPORT "function pointers".
For numbering versions it's only a commercial strategy, HITEC will have been in version 5.xxx if it has continued using its old numbering scheme. they only tried to do quick in order the make all their C compilers for the same family of mcu's at the same level, for example for PIC/dsPIC/PIC24... version is 9.5xxx
Then let's the two when CCS comes out with version 5!
ALL the compilers have bugs ... when using them in commercial environment you have to make a manual check of the generated ASM code. This is mandatory for a good product QA strategy .
You have to check not only the generated ASM code also the uC with the generated hex file on the system real time if you want a good product QA because you can not depend only on the compiler.
Even HITEC Compiler has bugs ... but :
The problem is that we must differentiate : having bugs and being FULLY BUGGY is not the same.
When a compiler have very tricky bug in extreme conditions (like in HITEC C) this is not an issue ... it can be problematic but the compiler is very handfull compared to ASM manual coding. But when the compiler is BUGGY... when you do not event trust it in nested loops, in indirect variable accessing ... this becomes very ugly, especially if you know that you have to pay for getting corrections to a buggy product ...
I don't know what you refer to as "being FULLY BUGGY" but the compiler isn't "FULLY BUGGY" it have some bugs but not that much to be referred to as "being FULLY BUGGY". If we're talking about the IDE it isn't also "FULLY BUGGY" it is "COMPLETELY BUGGY". I don't know of any bugs with the nested loops or indirect variable accessing or some other low-level code case because if there was a bug I would find it as I always use these. And I would pay them if they corrected the bugs i find!;) I found a structure bug a few weeks ago and it isn't corrected yet. They don't even respond to bug reports and yes this is very UGLY!
I do not hate CCS, and have nothing against them, but I'll never buy their products because I'll never trust them for commercial products.
I also do not hate CCS or HiTech or IAR or some other vendor nor a supporter of any of them. I just like to get the most from a compiler as it reserves me time.
Regards...
