short&int in kdevelop 2.0???

Iztok Kobal iztok.kobal at sysen.si
Wed Apr 24 07:05:56 BST 2002



Tarjei Knapstad wrote:

>On Tue, 23 Apr 2002, oak_hj wrote:
>
>>hi:
>>During our project,i find a strange problem:
>>it seems that short = 2 bytes 
>>while int = 4 bytes,
>>and long = 4 bytes???
>>but in the standard c,they should be equal!
>>it is a bug?
>>
>The length of built in types is OS/Compiler dependent. To my knowledge, no 
>standard dictates the length of these types (where did you hear/read 
>this?).
>
Oak_HJ has obviously read some non R&K C user manual probably customly 
made for 8/16 bit embedded architecture and now he has basically mess in 
his software which is difficult to port to 32/64 bits. I know this from 
my past and even M$ had (reportedly) to do some stupid type presumptions 
to avoid bigger problems. But Tarjei has basically right. You should 
check every line of your code and replace standard types with custom 
ones. It would be much easier task for you if it wasn't C - it does not 
differentiate types by their names but by their contents. Anyway, the 
right way of programming is (sadly) through the use of custom types - 
when it comes to the platform change you will make changes in one place 
only.

>
>When I use short, it's not because I "really need an integer type that can 
>hold only a short range of values", it's because I "only need a short 
>ranged integer and want to save some memory".
>
Here I must disaggree with Tarjei. His argument for short type usage is 
little obsolete nowadays since memory is no more problem. However, the 
right use of smaller type would be the first one - intentionally 
limiting the type range by declaring enumeration or subrange type for 
dedicated use. But, unfortunatelly, neither C neither C++ neither C# 
have possibilities to do that for restricted/safe use (the Cwhatever 
compiler treats enumerations as integers, anyway) - you should use 
Modula-2/3/Oberon for such programming - these languages have much more 
developed idea of type checking. I must tell you - it is very useful and 
I am very dissappointed because nobody in the world supports these 
languages anymore - I have to port plenty of code from M2 to C++ because 
of that and I am constantly pissed-off because of C-unflexibility. The 
SW developing would be a lot faster and much more elegant if there was 
no C ...

>
>In any case, this has absolutely nothing to do with KDevelop.
>
Correct. Look into the /usr/include/linux/types.h for more information.

-- 
Iztok Kobal




-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop mailing list