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?=]

Ian Collins wrote:

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.

It wasn't a completely serious reply. I don't think code should use
such typedefs.

[William Ahern]

On Fri, 16 Feb 2007 14:12:03 -0800, Ben Pfaff wrote:

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

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

What do you make your strings out of?

Either (const char) or (unsigned char), depending on whether they're there
to sit pretty or be parsed.

The endless threads on the behavior of passing signed types to isalnum()
and the other ctype routines eventually convinced me to just use (unsigned
char) in the vast majority of circumstances. Similarly, I now typically
use unsigned types more often than not, since that's typically
more appropriate. Rare is the circumstance that I blithely toss an
(int) anywhere; closest I usually get are enum types.

I suspect Dave's harsh proscription was hyperbole. Still, instructive.

[Richard Bos]

"=?utf-8?B?SGFyYWxkIHZ hbiBExLNr?=" <tr*****@gmail. comwrote:

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? 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.

To document that it's the eight-bittedness that I want, not the
character-holdingness (if you'll allow me to coin two nonce-words).

Richard

[Flash Gordon]

Harald van Dijk wrote, On 19/02/07 08:29:

Ian Collins wrote:

>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.

It wasn't a completely serious reply. I don't think code should use
such typedefs.

There are times when you want a type of a specific size and, if you
don't have it, you will have to do recoding (I've come across it with 18
bit times). In such cases what better than a time that is guaranteed to
either meet your requirements or not exist?

One example of such a situation is what are called "wrap angles" where I
used to work. An angle would come in on an interface (how does not
matter) presented as a 16 bit number scaled to represent exactly 1
complete circle. I.e. 0x4000 is 90 degrees, 0x8000 is 180 degrees. This
gives you a few very good reasons for using an exact width type.
1) That is how the number comes in and you will have to deal with it as
such on the interface
2) It simplifies doing some geometry since you can just let the numbers
wrap (using unsigned types of course)
3) You can use tables of a sensible size (still leave enough space in
ROM for the program) to implement very fast trig operations.

An example for wanting an 8 bit unsigned integer type is if you are
dealing with an 8 bit greyscale image. Yes, even in this day and age
people deal with 8 bit greyscale images. If that is how your data comes
in then that is what you want to use.
--
Flash Gordon

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

Richard Bos wrote:

"=?utf-8?B?SGFyYWxkIHZ hbiBExLNr?=" <tr*****@gmail. comwrote:

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? 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.

To document that it's the eight-bittedness that I want, not the
character-holdingness (if you'll allow me to coin two nonce-words).

Fair enough. "unsigned char" has pretty much become synonymous with
"byte" to me, so to me it would make more sense.

<OTAdditionally , I forgot, but uint8_t can be provided on C90
systems even when CHAR_BIT 8, if it includes padding bits. POSIX
required implementations to provide uint8_t even when it was not
limited to 8-bit systems. </OT>

[Richard Bos]

"=?utf-8?B?SGFyYWxkIHZ hbiBExLNr?=" <tr*****@gmail. comwrote:

Richard Bos wrote:

"=?utf-8?B?SGFyYWxkIHZ hbiBExLNr?=" <tr*****@gmail. comwrote:

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? 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.

To document that it's the eight-bittedness that I want, not the
character-holdingness (if you'll allow me to coin two nonce-words).

Fair enough. "unsigned char" has pretty much become synonymous with
"byte" to me, so to me it would make more sense.

It is in C, but byte is not synonymous with octet. Most image formats
are described in octets, not in system bytes, for obvious reasons.

Richard

[Kenneth Brody]

LuisC wrote:

>
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?

It is possible that, on some hardware, it is slower to write a char
than an int.

Consider a platform with a 32-bit bus, 8-bit chars, and 32-bit ints.
All memory access is done in 32-bit "words". To read an 8-bit char,
the 32-bit value is read, and 24 bits are discarded. However, in
order to write an 8-bit char, the system must first read the entire
32-bit value, modify the appropriate bits, and write the new 32-bit
value back to memory.

Such a platform would, if it permitted such operations, require two
reads to get an unaligned 32-bit value, and two reads plus two
writes to write an unaligned 32-bit value.

However, such matters are beyond the scope of the C language itself.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Dave Hansen]

On Feb 16, 4:12 pm, Ben Pfaff <[e-mail] rd.eduwrote:

"Dave Hansen" <i...@hotmail.c omwrites:

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

What do you make your strings out of?

uint8_t unless a wider type is required.

Regards,
-=Dave

[Dave Hansen]

On Feb 16, 6:18 pm, Keith Thompson <[e-mail] ote:

"Dave Hansen" <i...@hotmail.c omwrites:

On Feb 16, 1:41 pm, "LuisC" <luiscardozocar [e-mail] wrote:

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?

Depends what you want. All of the following assumes you want a signed
integer type to hold values in the range of +/-127:

If you want the fastest type, use int_fast8_t.

If you want the smallest type, use int_least8_t.

If you want a type that is exactly 8 bits wide, use int8_t.

The above are available only if you have the <stdint.hhead er (i.e.,
either you have a C99 implementation, or a non-C99 implementation that
provides it). Note that if your implementation doesn't have
<stdint.h>, it's not too difficult to roll your own.

Valid point. But, it's harder to roll your own if you don't know
whether int is faster than signed char, for example.

>

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

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

Not all strings...

The problem with plain char is that you don't really know what it is.
It's a Heisentype.

Well, I suppose you could write an introspective function, like

int is_plain_char_s igned(void)
{
char test = -1;

return test == -1;
}

But then you'd have to know when to use it, and what to do with the
result.

Regards,
-=Dave

[Dave Hansen]

On Feb 19, 2:45 am, William Ahern <will...@25than dClement.comwro te:

On Fri, 16 Feb 2007 14:12:03 -0800, Ben Pfaff wrote:

"Dave Hansen" <i...@hotmail.c omwrites:

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

What do you make your strings out of?

[...]

I suspect Dave's harsh proscription was hyperbole. Still, instructive.

Slight hyperbole. All sweeping generalizations are false.

Regards,
-=Dave