On May 6, 8:01=A0pm, "Herbert Rosenau" <os2...@[EMAIL PROTECTED]
> wrote:
> unsigned char =A0 =A0 =A0- fits all arithmetic needs for any unsigned
valu=
e
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the range of 0 to
UCHAR_MIN
You mean UCHAR_MAX of course.
Despite that though, you haven't provided any information. Of course
an unsigned char will store anything up to UCHAR_MAX, but what is
UCHAR_MAX? Well the Standard gives it a lower limit of 255u and gives
it no upper limit. This mean's it's at least 8-Bit.
> signed char =A0 =A0 =A0 =A0- fits all arithmetic needs for any signed
valu=
e
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the range of MIN_CHAR to
MAX=
_CHAR
You mean SCHAR_MIN to SCHAR_MAX (which are distinct from CHAR_MIN and
CHAR_MAX).
> unsigned int =A0 =A0 =A0 - same as unsigned char, but at least 16 bit
wide=
> signed int =A0 =A0 =A0 =A0 - same as signed char, but at least 16 bit
wide=
>
> long =A0 =A0 =A0 =A0 =A0 =A0 =A0 - like above but at least 32 bit
>
> long long =A0 =A0 =A0 =A0 =A0- like above but may be wider.
"long long" is at least 64-Bit.
> There is no need to invent other data types.
No need for new intrinsic types, I agree. There is though a great use
for typedef's such as uint_fast8_t.
> A programmer with brain
> for only 1 penny will decide to use the right data type that fits the
> needs for the value it has to fit in. This will be char if the range
> of the value fits in, it will be int, long or long long otherwise.
A common novice mistake. If you use char to store numbers on a PC,
then you'll end up with code that is both slower and consumes more
memory. Slower because more instructions are needed to deal with
integer types that are smaller than the registers. Consume more memory
because you have to store those extra instructions somewhere.
> It
> doesn't matter that the ma****ne has only one single register or 4096
> of them to wor with, it does'nt matter if the natural width of a
> register is =A08, 9, 16, 18, 24, 32, 36, 48, 64, 128 or 256 whatever
> bit.
Prove it to me. Show me some C code and then show me the assembler
that your compiler produced from it. I've already shown the assembler
produced by the 8-Bit PIC C compiler, and it clearly shows the int is
AT LEAST two times slower than char, and other times it's even 4 or 5
times slower. On a PC, you'll see the opposite, you'll see that int is
faster than char.
> Either one owns a compiler that works trusty for the job it has
> to do or assembly is the solution.
Nope buddy, you're wrong there. If you write a function that works
with an "int", then you've no way of telling the compiler that you
won't need to store numbers greater than 255. Because of this, the
compiler can't take the liberty of using a char. Similarly, if you
have a function that works with "char", then you've no way of telling
the compiler that it will never store numbers greater than 255, so it
can't optimise it to "int" if that's the case.
> It is relevant to write standard complilant code whereever it is
> possible, use standard compilant data types, use commononly used code
> constructs because things are changing constantly.
Yes you're right, and it's great to write ****table code. Using
uint_fast8_t instead of int helps to advance the cause.
> - tomorrow the program has to run under another CPU - the standard has
> =A0 foreseen that, so only a new translation cycle has to be done
> =A0 and anything works again without unforseen restrictions
Haven't a bull's notion what you're tryint to say there. Please
elaborate.
> - tomorrow you gets fired because you has written constantly
> =A0 keywords in an unusual order and the new boss dosn't like that
> =A0 because it makes fixing your ****y code more cost intensive.
I would have been fired two weeks already for calling him a thick c*nt
to his face if he can't understand "unsigned char". In fact, I never
would have taken the job if I'd got the slightest inclination that the
boss was borderline retarded.
> There is further really no need to invent other order of calles, type
> as the whole C community uses since BCPL, the predecessor of was
> foundet.
Please re-word that paragraph, I can't make sense of it.
> Except one will blame himself as ignorant and ties to obfuscate his
> ****y code
Some sort of dig at me, I assume, but it's hard to make out through
the language barrier.
> Be sure you'll gets never hired here based on your misbehavior in
> follllowing common practise, unability to write readable code and
> kidding.
comp.lang.c are hiring now?
|
