What is better? char or int?

[LuisC]

What is better for holding small numbers in a program?

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

Luis

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Keith Thompson wrote:

"Dave Hansen" <id**@hotmail.c omwrites:

Never use plain char. For anything. I'm serious.

Strings are arrays of plain char, and are widely used in stdio.

Out of curiosity, should <stdio.htreat strings as arrays of plain
char, or internally read them as arrays of unsigned char? The
difference could be important, because it would mean that snprintf(0,
0, "%s", s) might report a different length than strlen(s), if s
contains negative zeroes.

[Malcolm McLean]

"LuisC" <lu************ *****@gmail.com wrote in message

What is better for holding small numbers in a program?

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

The main advantage of int is that it is clear to everyone that you are
dealing with an integer.

However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

Speed varies and can be hard to calculate. Normally a char will handled
internally in a register which is likely to be the same size as an integer
register. However memory access may well be slower because chars are not
aligned on hardware boundaries. On the other hand it may be faster because
you need to make fewer reads.

[Thad Smith]

Harald van Dijk wrote:

Out of curiosity, should <stdio.htreat strings as arrays of plain
char, or internally read them as arrays of unsigned char?

<stdio.his a header. I assume you are referring to functions defined
in <stdio.h>.

The
difference could be important, because it would mean that snprintf(0,
0, "%s", s) might report a different length than strlen(s), if s
contains negative zeroes.

In both cases, the string is terminated with the terminating null
character, which is defined as the first byte containing all zero bits,
regardless of whether plain char is signed or unsigned and regardless of
the binary representation of negative values.

Would that require C-written functions for systems that have negative
zeros for plain char types to cast the char* to unsigned char* in order
to properly detect the terminating null character? I suspect so. Does
that render unportable the classic string copy loop?

Cross-posted to comp.std.c.

--
Thad

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Thad Smith wrote:

Harald van Dijk wrote:

Out of curiosity, should <stdio.htreat strings as arrays of plain
char, or internally read them as arrays of unsigned char?

<stdio.his a header. I assume you are referring to functions defined
in <stdio.h>.

Yes.

The
difference could be important, because it would mean that snprintf(0,
0, "%s", s) might report a different length than strlen(s), if s
contains negative zeroes.

In both cases, the string is terminated with the terminating null
character, which is defined as the first byte containing all zero bits,
regardless of whether plain char is signed or unsigned and regardless of
the binary representation of negative values.

Thank you, I missed the fact that negative zero cannot ever match the
definition of a null character.

Would that require C-written functions for systems that have negative
zeros for plain char types to cast the char* to unsigned char* in order
to properly detect the terminating null character? I suspect so. Does
that render unportable the classic string copy loop?

It does, that's why for the functions declared in <string.hther e is
an explicit mention that the strings are to be treated as arrays of
unsigned char (in 7.21.1p3). I was wondering about <stdio.hbecau se
that paragraph does not apply to other functions, but I'm glad to see
that it's addressed, even if not explicitly, already.

[Stephen Sprunk]

"Malcolm McLean" <re*******@btin ternet.comwrote in message
news:Re******** *************** *******@bt.com. ..

>
"LuisC" <lu************ *****@gmail.com wrote in message

>What is better for holding small numbers in a program?

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

The main advantage of int is that it is clear to everyone that you are
dealing with an integer.

Exactly. Code so that your intent is clear; if you're dealing with numbers
that can fit in 16 bits or less, use int or unsigned int. Premature
optimization is the root of all evil. Don't play games with using char for
integers until you (a) have a performance problem and (b) can prove char
fixes it.

However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

OT: People still use 24-bit images in memory? Every general-purpose system
I've worked with used 32-bit RGB (with 8 padding bits) or RGBA in memory,
and optionally translated to 24-bit (or 48-bit, for X11) for certain disk or
network formats.

Speed varies and can be hard to calculate. Normally a char will handled
internally in a register which is likely to be the same size as an integer
register. However memory access may well be slower because chars are not
aligned on hardware boundaries. On the other hand it may be faster because
you need to make fewer reads.

char should always be aligned from a C programmer's perspective. If you're
dealing with one of the odd systems (e.g. Cray, early Alphas) that doesn't
have hardware support for 8-bit reads, you'll likely know that and can
introduce suitable alternate code conditionally used with #ifdefs. Most
modern systems have the same performance for char, int, and long -- and many
for long long as well.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Bos]

"Malcolm McLean" <re*******@btin ternet.comwrote :

"LuisC" <lu************ *****@gmail.com wrote in message

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

The main advantage of int is that it is clear to everyone that you are
dealing with an integer.

However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

OTOH, in that case I would never use either int _or_ char, but always
unsigned char (and if I had C99, uint8_t).

Richard

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

"Malcolm McLean" <re*******@btin ternet.comwrote :

"LuisC" <lu************ *****@gmail.com wrote in message

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

The main advantage of int is that it is clear to everyone that you are
dealing with an integer.

However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

OTOH, in that case I would never use either int _or_ char, but always
unsigned char (and if I had C99, uint8_t).

Why uint8_t? What benefits does it provide over unsigned char? If
CHAR_BIT == 8, then unsigned char matches the requirements of uint8_t,
and if CHAR_BIT 8, then an implementation is not allowed to provide
uint8_t anyway.

[Ian Collins]

Harald van Dijk wrote:

Richard Bos wrote:

>>"Malcolm McLean" <re*******@btin ternet.comwrote :

>>>"LuisC" <lu************ *****@gmail.com wrote in message

I know that char uses less memory, but, with 32 or 64 bits systems,
there are advantages (such as processing time) in using int instead of
char for small numbers?

The main advantage of int is that it is clear to everyone that you are
dealing with an integer.

However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

OTOH, in that case I would never use either int _or_ char, but always
unsigned char (and if I had C99, uint8_t).

Why uint8_t? What benefits does it provide over unsigned char?

Less typing?

--
Ian Collins.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Ian Collins wrote:

Harald van Dijk wrote:

Richard Bos wrote:

>"Malcolm McLean" <re*******@btin ternet.comwrote :
However if you have a large array of values, then it is reasonable to use
char to save space. An obvious case is 24-bit colour images. Using ints to
store every channel would just throw memory away.

OTOH, in that case I would never use either int _or_ char, but always
unsigned char (and if I had C99, uint8_t).

Why uint8_t? What benefits does it provide over unsigned char?

Less typing?

typedef unsigned char uchar;

(I'm dealing with some code that does this right now.)

[Ian Collins]

Harald van Dijk wrote:

Ian Collins wrote:

>>Harald van Dijk wrote:

>>>Richard Bos wrote:

"Malcolm McLean" <re*******@btin ternet.comwrote :

>However if you have a large array of values, then it is reasonable to use
>char to save space. An obvious case is 24-bit colour images. Using ints to
>store every channel would just throw memory away.

OTOH, in that case I would never use either int _or_ char, but always
unsigned char (and if I had C99, uint8_t).

Why uint8_t? What benefits does it provide over unsigned char?

Less typing?

typedef unsigned char uchar;

(I'm dealing with some code that does this right now.)

At least uint8_t is standardised.

--
Ian Collins.