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

[Walter Roberson]

Re: What is better? char or int?

In article <1171654880.261 429.42260@q2g20 00cwa.googlegro ups.com>,
LuisC <luiscardozocar reras@gmail.com 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?

Sort of. However:

a) char and iint are allowed to be the same size. sizeof(int) can be 1.
Apparently this happens on some DSPs. So you will not -always- save
memory by using char. Just usually.

b) whether char or int is faster to access on any particular system
is architecture dependant. It is not uncommon for modern architectures
to always fetch a full word and pick the char out of the word
(at a very low level), instead of having seperate logic to read
a single char. And modern architectures that can read a char at a time
sometimes have to bypass the cache and run special bus cycles that
load only the required character, because the memory hardware would
normally supply a full word. But it varies with the system, so
although we can say that "These days char might be slower
than int," you have to know your system very thoroughly to be sure
(and it might change with the next compiler version.)

So, like always: if it matters, measure. (And then throw out those
measurements and go hang out in comp.benchmarks for awhile in order
to learn about the 17 different ways in which your naive benchmark
was not measuring what you thought it was measuring!)
--
Programming is what happens while you're busy making other plans.

[Radamanthe]

Re: What is better? char or int?

LuisC wrote:

What is better for holding small numbers in a program?

int.

I have one rule: just don't use char or even short for this purpose
unless memory is concerned or in some big DB.

Long ago, I did care of this... today, I don't. Especially for function
arguments.

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?

int is supposed to be the "native-ideal" integer. That's the one you
must choose for performance reasons when dealing with simple numbers.
Choose the other types (short or char) for memory reasons.

Still in the chapter of performance, some architectures must do more
operations to handle char correctly where int would just work well on
his own (thus faster).



--
R.N.

[santosh]

Re: What is better? char or int?


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?

In C, char is the appropriate type for character literals and strings,
(in the latter case, as an array of char). If your value needs more
than 16 value bits, use long. If it needs more than 32 bits, long long
is neccessary. Anything under 16 bits is guaranteed to fit in an int
and that would probably be the best choice, unless space is a real
issue. Whether access to char is slower than int is platform and
compiler dependent. In most cases, it's a case of premature
optimisation. Note also that whether a plain char is signed or
unsigned is implementation specified.

[Dave Hansen]

Re: What is better? char or int?

On Feb 16, 1:41 pm, "LuisC" <luiscardozocar re...@gmail.com 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.

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

Regards,

-=Dave

[Walter Roberson]

Re: What is better? char or int?

In article <1171663234.766 125.240360@k78g 2000cwa.googleg roups.com>,
Dave Hansen <iddw@hotmail.c omwrote:

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

Valid in C99, not invented yet by C89.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[Ben Pfaff]

Re: What is better? char or int?

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

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

What do you make your strings out of?
--
Ben Pfaff
blp@cs.stanford .edu

http://benpfaff.org

[Keith Thompson]

Re: What is better? char or int?

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

On Feb 16, 1:41 pm, "LuisC" <luiscardozocar re...@gmail.com 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.

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

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

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Thad Smith]

Re: What is better? char or int?

Radamanthe wrote:

int is supposed to be the "native-ideal" integer. That's the one you
must choose for performance reasons when dealing with simple numbers.

That's not always true. A conforming compiler for 8-bit embedded
processors produces smaller and faster code for unsigned char than for
int, since int must be at least 16 bits in size.

If you use C99, <stdint.h>: int_fast8_t is the answer for signed
variables using no more than 8 bits, plus similar answers for some other
sizes, such as int_fast16_t.

--
Thad

[SM Ryan]

Re: What is better? char or int?

"LuisC" <luiscardozocar reras@gmail.com wrote:
# What is better for holding small numbers in a program?

Are you dealing with characters or integers? Program for maintenance.
If you're worried about the memory layout, use stdint.h integers
like uint8_t or use struct fields.

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

There's an advantage to making your intent clear. You can even typedef
integers to make your intent clear.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I have no idea what you just said.
I get that alot.

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

Re: What is better? char or int?

Keith Thompson wrote:

"Dave Hansen" <iddw@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]

Re: What is better? char or int?


"LuisC" <luiscardozocar reras@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]

Re: What is better? char or int?

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

Re: What is better? char or int?

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]

Re: What is better? char or int?

"Malcolm McLean" <regniztar@btin ternet.comwrote in message
news:ReydnRmnfP axIkvYnZ2dnUVZ8 turnZ2d@bt.com. ..

>
"LuisC" <luiscardozocar reras@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