Is it good to use char instead of int to save memory?

[Dr Malcolm McLean]

Consider if we/you know that "using sub-int data types" does not
increase code size and execution time, what are the drawbacks of using
unsigned char for numbers in the range 0 to 255?- Hide quoted text -

consider this

void flagduplicates(char **str, bool *flags, unsigned char N)
{
unsigned char i;
for(i=0; i <N-1;i++)
if(!strcmp(str, str[i+1]))
flags = true;
else
flags = false;
flags = false;
}

or this

unsigned char ch;

while( (ch = fgetc(fp)) != EOF )
/* do something */;

or this

unsigned char exponent;
double mantissa;

mantissa = frexp(x, &exponent);

 

[Eric Sosman]

But using a single char variable (which everyone has been arguing
against) fixes that.

... as would using an int* instead of a char*. So?

 

[Dr Malcolm McLean]

I would guess the OP had a lower bound of 0 in mind, wouldn't you? Unless
there's a one in a thousand chance he's working with 9-bit chars.

Zero? Danagerous Saracen magic. The lower bound should be one.

 

[bartc]

... as would using an int* instead of a char*. So?

The context is that something wants to store a value via a char* (perhaps a
function call). You can't use int*.

In this case it's one example of where an individual char variable can be
useful.

I have others..

 

[Eric Sosman]

The context is that something wants to store a value via a char*
(perhaps a function call). You can't use int*.

"The context" is

//int i = 1;
char i = 1; //is this better than previous line?

There is no char* anywhere in sight. There is not even a store
operation anywhere in sight, certainly not a store through a char*
via the intermediary of a function call. You're imagining things.

 

[Seebs]

Is it recommended to use char instead of int for variables that you
know never will contain a value larger than 255? A small example
follows:

"Is it recommended"? By someone, somewhere? Certainly.

I would not recommend it.

What are the pros and cons of using char instead of int when values
will not exceed 255?

Never use char unless you mean it. If you just want a value, and don't
really care too much about its range, always use int. In many cases,
declaring the variable "char" will cost several times more space than it
saves.

-s

 

[bartc]

"The context" is

//int i = 1;
char i = 1; //is this better than previous line?

There is no char* anywhere in sight. There is not even a store
operation anywhere in sight, certainly not a store through a char*
via the intermediary of a function call. You're imagining things.

I was replying to:

I wouldn't use types lower ranking than int,
unless they were in an array.

I gave an example where a char variable would be handy. That example stored
something via a char* type. That was the context, expressed as:

*p=65;

for illustration, but a function call might be an example where a char*
might be imposed:

char c;

while (readnextvalue(f,&c)) printf("%d",c);

 

[dspfun]

"Is it recommended"?  By someone, somewhere?  Certainly.

I would not recommend it.


Never use char unless you mean it.  If you just want a value, and don't
really care too much about its range, always use int.  In many cases,
declaring the variable "char" will cost several times more space than it
saves.

Can you give some specific examples of why unsigned int is better than
unsigned char when values are in the range 0-255? I know with respect
to performance and memory there can be a difference.

 

[Seebs]

Can you give some specific examples of why unsigned int is better than
unsigned char when values are in the range 0-255? I know with respect
to performance and memory there can be a difference.

Uh, yeah. Those are the specific examples: Performance and memory.

I don't understand what part of the answers you already have you don't
understand.

-s

 

[Julienne Walker]

This is an even more pedantic answer than spinoza was anticipating.

Not by my reading. It seems to me he was expecting the "a char doesn't
have to be 8 bits" nitpick, which is the default unhelpful observation
by pedants when someone asks about a specific limit.

I would guess the OP had a lower bound of 0 in mind, wouldn't you?

Yes, I would. But my point was that by guessing you could easily reach
the wrong conclusion. Maybe he wants (-256,256) and doesn't understand
the distinction between signed and unsigned. The correct approach in
my opinion is to confirm the range his program needs and *then* answer
the question.

 

[spinoza1111]

Zero? Danagerous Saracen magic. The lower bound should be one.

Malcolm!! Are congratulations in order, old fellow? Did you complete
your PhD? If so: my sincere compliments. If not, my best wishes.

 

[spinoza1111]

Unfortunately, the OP didn't give us an absolute range of allowed
values to work with, so it would be unwise to assume the lower limit
of his allowed range given only the upper limit. In this case I would
ask for more information before answering with an unwarranted
assumption, or give multiple answers depending on the most reasonable
assumptions:

If we're talking about values that also won't be negative, an unsigned
char is fine and there's no need to talk about ranges because the 8-
bit range is the required minimum. On the other hand, if negative
values *are* allowed (ie. signed char), the upper limit of 255 is
beyond the guaranteed minimum and short or int would be better suited.


I'm confident that one's mental abilities aren't judged by choice of
numeric data type in C. ^_^ Some people might, but for those people I
would recommend chilling out.

Hey, this is clc. And instead of chilling out, in my view, Julienne,
people need to get rowdy about the behavior of some of the regulars.
But you know my views.

 

[spinoza1111]

This is an even more pedantic answer than spinoza was anticipating.

I would guess the OP had a lower bound of 0 in mind, wouldn't you? Unless
there's a one in a thousand chance he's working with 9-bit chars. And one in
a million chance of something even weirder.

Strange things happen in the embedded world, so Julienne's question
made sense, IMO.

 

[Anand Hariharan]

On Mar 18, 6:50 am, Marc Boyer <[email protected]>
wrote:
(...)

   int  vali[1024];
   char valc[1024];

In this case, valc will use less memory than vali (the ratio beeing
sizeof(char) ).

ITYM sizeof(int).

 

[Anand Hariharan]

On 3/18/2010 7:40 AM, dspfun wrote: (...)

What are the pros and cons of using char instead of int when values
will not exceed 255?

     If you need [0..255] you should use unsigned char, not plain
char.  (If you need [-127..127] make it signed char.)

Are there any 1's complement machines out there which have C
implementations that are actively used?

- Anand

 

[Eric Sosman]

On 3/18/2010 7:40 AM, dspfun wrote: (...)

What are the pros and cons of using char instead of int when values
will not exceed 255?

If you need [0..255] you should use unsigned char, not plain
char. (If you need [-127..127] make it signed char.)

Are there any 1's complement machines out there which have C
implementations that are actively used?

No, of course not. And no signed-magnitude machines,
either. What's more, there *never* will be, no, not ever,
not while your children's children's children still use C.

That guy Heraclitus was a nitwit.

 

[Sjouke Burry]

Hi,

Is it recommended to use char instead of int for variables that you
know never will contain a value larger than 255? A small example
follows:

#include <stdio.h>
int main(void)
{
//int i = 1;
char i = 1; //is this better than previous line?
printf("i=%d\n",i);
return 0;
}

What are the pros and cons of using char instead of int when values
will not exceed 255?

Brs,
Markus

I only once did that in an astro program that held data
about several millions of stars, where each byte saved made a
huge difference.
In all other cases, dont do it.

 

[jamm]

Hi,

Is it recommended to use char instead of int for variables that you
know never will contain a value larger than 255? A small example
follows:

Hmm people here seem to forget that C isn't just used on desktop Intel
PCs...

On an 8 bit uC with 128 bytes of SRAM, where char is 8 bit and int is 16
bit, yes char is what you're going to want to use. You would usually avoid
larger types for performance/memory reasons unless you really need an int.
Then use an int.

 

[bartc]

I only once did that in an astro program that held data
about several millions of stars, where each byte saved made a
huge difference.
In all other cases, dont do it.

I ran some tests using this struct:

typedef struct {char x,y; short z;} D;

On my x86-32 machine, using int instead of char and short made them take up
to 6 times as long to execute.

(One test passed the struct to a function by value, and returned a new
value. Another just copied one to another. Nothing involving large arrays.)

The OP may not have such a PC, but should do his own evaluations.

 

[Dr Malcolm McLean]

Malcolm!! Are congratulations in order, old fellow? Did you complete
your PhD? If so: my sincere compliments. If not, my best wishes.

Veteran readers of comp.lang.c will have noticed a change in my
moniker. I'm Dr Malcolm McLean now.