473,321 Members | 1,708 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

What is better? char or int?

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

Feb 16 '07 #1
58 4790
In article <11*********************@q2g2000cwa.googlegroups.c om>,
LuisC <lu*****************@gmail.comwrote:
>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.
Feb 16 '07 #2
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.
Feb 16 '07 #3

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.

Feb 16 '07 #4
On Feb 16, 1:41 pm, "LuisC" <luiscardozocarre...@gmail.comwrote:
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

Feb 16 '07 #5
In article <11**********************@k78g2000cwa.googlegroups .com>,
Dave Hansen <id**@hotmail.comwrote:
>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
Feb 16 '07 #6
"Dave Hansen" <id**@hotmail.comwrites:
Never use plain char. For anything. I'm serious.
What do you make your strings out of?
--
Ben Pfaff
bl*@cs.stanford.edu
http://benpfaff.org
Feb 16 '07 #7
"Dave Hansen" <id**@hotmail.comwrites:
On Feb 16, 1:41 pm, "LuisC" <luiscardozocarre...@gmail.comwrote:
>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.hheader (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_Keith) ks***@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.
Feb 17 '07 #8
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
Feb 17 '07 #9
"LuisC" <lu*****************@gmail.comwrote:
# 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.
Feb 17 '07 #10
Keith Thompson wrote:
"Dave Hansen" <id**@hotmail.comwrites:
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.

Feb 17 '07 #11

"LuisC" <lu*****************@gmail.comwrote 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.
Feb 17 '07 #12
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
Feb 17 '07 #13
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.hthere 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.hbecause
that paragraph does not apply to other functions, but I'm glad to see
that it's addressed, even if not explicitly, already.

Feb 17 '07 #14
"Malcolm McLean" <re*******@btinternet.comwrote in message
news:Re******************************@bt.com...
>
"LuisC" <lu*****************@gmail.comwrote 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

Feb 17 '07 #15
"Malcolm McLean" <re*******@btinternet.comwrote:
"LuisC" <lu*****************@gmail.comwrote 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
Feb 19 '07 #16
Richard Bos wrote:
"Malcolm McLean" <re*******@btinternet.comwrote:
"LuisC" <lu*****************@gmail.comwrote 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.

Feb 19 '07 #17
Harald van Dijk wrote:
Richard Bos wrote:
>>"Malcolm McLean" <re*******@btinternet.comwrote:
>>>"LuisC" <lu*****************@gmail.comwrote 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.
Feb 19 '07 #18
Ian Collins wrote:
Harald van Dijk wrote:
Richard Bos wrote:
>"Malcolm McLean" <re*******@btinternet.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.)

Feb 19 '07 #19
Harald van Dijk wrote:
Ian Collins wrote:
>>Harald van Dijk wrote:
>>>Richard Bos wrote:

"Malcolm McLean" <re*******@btinternet.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.
Feb 19 '07 #20
Ian Collins wrote:
Harald van Dijk wrote:
Ian Collins wrote:
>Harald van Dijk wrote:
Richard Bos wrote:
"Malcolm McLean" <re*******@btinternet.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.

Feb 19 '07 #21
On Fri, 16 Feb 2007 14:12:03 -0800, Ben Pfaff wrote:
"Dave Hansen" <id**@hotmail.comwrites:
>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.
Feb 19 '07 #22
"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:
Richard Bos wrote:
"Malcolm McLean" <re*******@btinternet.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
Feb 19 '07 #23
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*******@btinternet.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
Feb 19 '07 #24
Richard Bos wrote:
"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:
Richard Bos wrote:
"Malcolm McLean" <re*******@btinternet.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>

Feb 19 '07 #25
"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:
Richard Bos wrote:
"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:
Richard Bos wrote:
"Malcolm McLean" <re*******@btinternet.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
Feb 19 '07 #26
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>
Feb 19 '07 #27
On Feb 16, 4:12 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
"Dave Hansen" <i...@hotmail.comwrites:
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

Feb 19 '07 #28
On Feb 16, 6:18 pm, Keith Thompson <k...@mib.orgwrote:
"Dave Hansen" <i...@hotmail.comwrites:
On Feb 16, 1:41 pm, "LuisC" <luiscardozocarre...@gmail.comwrote:
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.hheader (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_signed(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

Feb 19 '07 #29
"Dave Hansen" <id**@hotmail.comwrites:
On Feb 16, 4:12 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
>"Dave Hansen" <i...@hotmail.comwrites:
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.
You must find string literals difficult.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan
Feb 19 '07 #30
On Feb 19, 2:45 am, William Ahern <will...@25thandClement.comwrote:
On Fri, 16 Feb 2007 14:12:03 -0800, Ben Pfaff wrote:
"Dave Hansen" <i...@hotmail.comwrites:
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

Feb 19 '07 #31
On Feb 19, 3:21 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
"Dave Hansen" <i...@hotmail.comwrites:
On Feb 16, 4:12 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
"Dave Hansen" <i...@hotmail.comwrites:
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.

You must find string literals difficult.
Not any more difficult than passing uint8_t * to the str.* functions.

Regards,
-=Dave
Feb 19 '07 #32
Richard Bos wrote:
>
.... snip ...
>
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).
In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 20 '07 #33
Ian Collins wrote:
Harald van Dijk wrote:
.... snip ...
>
>typedef unsigned char uchar;

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

At least uint8_t is standardised.
So is "typedef unsigned char uchar;" :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 20 '07 #34
CBFalconer <cb********@yahoo.comwrote:
Richard Bos wrote:
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.
If you wish to use an integer type which has exactly eight bits, your
specification is unportable. The best way to ensure that your program is
not ported anywhere where its specifications, not just your
implementation thereof, are invalid, is to make sure it can't.

(Yes, you can sometimes work around it. But that misses the point, in
this case.)

Richard
Feb 20 '07 #35

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
CBFalconer <cb********@yahoo.comwrote:
>Richard Bos wrote:
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

If you wish to use an integer type which has exactly eight bits, your
specification is unportable. The best way to ensure that your program is
not ported anywhere where its specifications, not just your
implementation thereof, are invalid, is to make sure it can't.

(Yes, you can sometimes work around it. But that misses the point, in
this case.)
We simpy hope that if char is not 8 bits then it is nine. A bit extra won't
hurt.

Should chars be 32 bits the computer proably has an infinite amount of
memory installed, so that's not too much of a problem either.

Feb 21 '07 #36
"Malcolm McLean" <re*******@btinternet.comwrites:
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
>CBFalconer <cb********@yahoo.comwrote:
>>Richard Bos wrote:

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

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

If you wish to use an integer type which has exactly eight bits, your
specification is unportable. The best way to ensure that your program is
not ported anywhere where its specifications, not just your
implementation thereof, are invalid, is to make sure it can't.

(Yes, you can sometimes work around it. But that misses the point, in
this case.)
We simpy hope that if char is not 8 bits then it is nine. A bit extra
won't hurt.

Should chars be 32 bits the computer proably has an infinite amount of
memory installed, so that's not too much of a problem either.
Realistically, if chars are 32 bits, the computer is probably a DSP.
I have no idea why you think this would imply infinite memory.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 21 '07 #37
"Malcolm McLean" <re*******@btinternet.comwrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
CBFalconer <cb********@yahoo.comwrote:
Richard Bos wrote:

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

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.
If you wish to use an integer type which has exactly eight bits, your
specification is unportable. The best way to ensure that your program is
not ported anywhere where its specifications, not just your
implementation thereof, are invalid, is to make sure it can't.

(Yes, you can sometimes work around it. But that misses the point, in
this case.)
We simpy hope that if char is not 8 bits then it is nine. A bit extra won't
hurt.
So you think using 36 bits for each pixel where every other system
expects 32 is not going to result in some decidely odd images?

Richard
Feb 22 '07 #38
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote
>
>We simpy hope that if char is not 8 bits then it is nine. A bit extra
won't
hurt.

So you think using 36 bits for each pixel where every other system
expects 32 is not going to result in some decidely odd images?
Why? Generally you don't want to calculate pixel values modulus 256. So
intermediate calculations are done with int, and clamped if there is
possibility of overflow.
So an extra blank bit in the msb of the channel won't do any harm

Feb 22 '07 #39

"Keith Thompson" <ks***@mib.orgwrote in message
"Malcolm McLean" <re*******@btinternet.comwrites:
>>
Should chars be 32 bits the computer proably has an infinite amount of
memory installed, so that's not too much of a problem either.

Realistically, if chars are 32 bits, the computer is probably a DSP.
I have no idea why you think this would imply infinite memory.
Or no memory whatsoever.

As with so many things in life, if you have nothing or everything you don't
need to worry about it. It is only when you have an intermediate amount that
you need to worry about the space taken up by pixel channels.

Feb 22 '07 #40
In article <11**********************@k78g2000cwa.googlegroups .com>,
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= <tr*****@gmail.comwrites
>Ian Collins wrote:
>Harald van D0 Richard Bos wrote:
>>"Malcolm McLean" <re*******@btinternet.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 think that uint8_t is both posix and MISRA complient
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Feb 22 '07 #41
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Richard Bos wrote:
>>
... snip ...
>>
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.
As unit8_t is a typedef you can always have it available.

As to portability uint8_t is AFAIK part of POSIX
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Feb 22 '07 #42
In article <45*************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>CBFalconer <cb********@yahoo.comwrote:
>Richard Bos wrote:
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

If you wish to use an integer type which has exactly eight bits, your
specification is unportable.
So what?

What do you mean by unportable? about a third of the MCU in the world
are 8 bit 8051's I can write a spec that requires 8 bit characters
that will work on several thousand different target processors.

Also uint8_t is in posix.

Signed and unsigned char are integer types anyway.

Of course if you are using PIC's then it all goes out of the window.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Feb 22 '07 #43
Chris Hills <ch***@phaedsys.orgwrites:
>In article <45***************@yahoo.com>,
CBFalconer <cb********@yahoo.comwrites
>>OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

As unit8_t is a typedef you can always have it available.
Yes, with a typedef which gives it a definition which breaks the spec,
and any code which relies on its spec.
As to portability uint8_t is AFAIK part of POSIX
It's in C99 and means an integer type of _exactly_ 8 bits. If POSIX
says uint8_t is always available, then it is saying a non-8bit machine
cannot support POSIX.

If you want a type of "8 or more bits" from C99, use uint_least8_t.

--
Regards,
Hallvard
Feb 22 '07 #44
Hallvard B Furuseth wrote:
Chris Hills <ch***@phaedsys.orgwrites:
In article <45***************@yahoo.com>,
CBFalconer <cb********@yahoo.comwrites
>OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.
As unit8_t is a typedef you can always have it available.

Yes, with a typedef which gives it a definition which breaks the spec,
and any code which relies on its spec.
As to portability uint8_t is AFAIK part of POSIX

It's in C99 and means an integer type of _exactly_ 8 bits.
C99 lifted it from POSIX, and POSIX had previously defined it to mean
an unsigned integer type of exactly 8 value bits, while allowing extra
padding bits.
If POSIX
says uint8_t is always available, then it is saying a non-8bit machine
cannot support POSIX.
Because of C99's decision to forbid >8-bit machines from defining
uint8_t types even though they were required to do so by the very
standard C99 lifted the type from, the POSIX folks had only a few
choices:
- reject C99
- reject previously strictly conforming POSIX programs
- reject >8-bit systems
The third option was chosen. So yes, a >8-bit machine can only support
older POSIX standards.

Feb 22 '07 #45
Chris Hills <ch***@phaedsys.orgwrites:
In article <45***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>>Richard Bos wrote:
>>>
... snip ...
>>>
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

As unit8_t is a typedef you can always have it available.
uint8_t is declared in <stdint.hin C99. It must be exactly 8 bits
with no padding bits. If the implementation doesn't provide a type
that meets those requirements, it will not declare uint8_t.

You can declare your own uint8_t if you like, of course. You can make
it a typedef for long double if you like; the compiler won't complain.
As to portability uint8_t is AFAIK part of POSIX
Perhaps, but POSIX imposes requirements that the C standard does not.
For example, if I recall correctly, POSIX requires CHAR_BIT==8. A
conforming C implementation with CHAR_BIT 8 cannot support POSIX.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 22 '07 #46
Chris Hills <ch***@phaedsys.orgwrites:
In article <45*************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>>CBFalconer <cb********@yahoo.comwrote:
>>Richard Bos wrote:

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

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

If you wish to use an integer type which has exactly eight bits, your
specification is unportable.

So what?
So your specification is unportable.
What do you mean by unportable?
It means that the specification can only be supported on systems that
provide an integer type which has exactly eight bits. If that
restriction isn't a problem for you, that's great; not all software
has to be portable. The point is merely that you should be aware that
it's not completely portable.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 22 '07 #47
Chris Hills wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nlwrites
.... snip ...
>
>If you wish to use an integer type which has exactly eight bits,
your specification is unportable.

So what?

What do you mean by unportable? about a third of the MCU in the
world are 8 bit 8051's I can write a spec that requires 8 bit
characters that will work on several thousand different target
processors.
Around here 'portable' means the program will compile and run
correctly on any system that meets the requirements of the C90 (or
C99) standard. Those standards do NOT specify 8 bits per char.
They do specifiy a MINIMUM of 8 bits per char.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Feb 23 '07 #48
In article <hb*************@bombur.uio.no>, Hallvard B Furuseth
<h.**********@usit.uio.nowrites
>Chris Hills <ch***@phaedsys.orgwrites:
>>In article <45***************@yahoo.com>,
CBFalconer <cb********@yahoo.comwrites
>>>OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

As unit8_t is a typedef you can always have it available.

Yes, with a typedef which gives it a definition which breaks the spec,
and any code which relies on its spec.
>As to portability uint8_t is AFAIK part of POSIX

It's in C99 and means an integer type of _exactly_ 8 bits. If POSIX
says uint8_t is always available, then it is saying a non-8bit machine
cannot support POSIX.

If you want a type of "8 or more bits" from C99, use uint_least8_t.
Signed and unsigned char are integer types and therefore can be uint8_t
ir int8_t

whilst signed and unsigned int would be uint16_t and int16_t

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Feb 23 '07 #49
Chris Hills <ch***@phaedsys.orgwrites:
In article <hb*************@bombur.uio.no>, Hallvard B Furuseth
<h.**********@usit.uio.nowrites
>>Chris Hills <ch***@phaedsys.orgwrites:
>>>In article <45***************@yahoo.com>,
CBFalconer <cb********@yahoo.comwrites
OTOH, in that case I would never use either int _or_ char, but
always unsigned char (and if I had C99, uint8_t).

In which case you have immediately made your code non-portable,
because there is no guarantee that uint8_t is available.

As unit8_t is a typedef you can always have it available.

Yes, with a typedef which gives it a definition which breaks the spec,
and any code which relies on its spec.
>>As to portability uint8_t is AFAIK part of POSIX

It's in C99 and means an integer type of _exactly_ 8 bits. If POSIX
says uint8_t is always available, then it is saying a non-8bit machine
cannot support POSIX.

If you want a type of "8 or more bits" from C99, use uint_least8_t.

Signed and unsigned char are integer types and therefore can be
uint8_t ir int8_t
They *can* be (and typically are), but not necessarily. In
particular, if CHAR_BIT 8, then uint8_t and int8_t will not exist.
(C allows this; POSIX apparently does not.)
whilst signed and unsigned int would be uint16_t and int16_t
*Only* if int is exactly 16 bits. (Even then, if char or short is
also exactly 16 bits, then one of them can be used for uint16_t and
int16_t).

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 23 '07 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Nobody | last post by:
Lets say I have a class that is only available if a specific DLL (a.dll) is present. I can't link to that DLL through lib files or my app will fail on any machine that doesn't have a.dll. So I...
20
by: sugaray | last post by:
Hi, can somebody help me out with a better version of the following functions which only convert decimal integer to it's corresponding binary form. the problem i'm having now is that I can't...
86
by: Randy Yates | last post by:
In Harbison and Steele's text (fourth edition, p.111) it is stated, The C language does not specify the range of integers that the integral types will represent, except ot say that type int may...
64
by: ng5000 | last post by:
Hi, What's the point of a signed char? As I see it a char represents a character (not an integer, use an int type e.g. short int if you want an 8 bit number, or one of the new types, uint8 I...
11
by: Alfonso Morra | last post by:
Hi, I am at the end of my tether now - after spending several days trying to figure how to do this. I have finally written a simple "proof of concept" program to test serializing a structure...
8
by: alternativa | last post by:
Hi, what would you say - which way of building a class is better? Why? /**** 1 ****/ class Person { public: Person(char *n, char *sn, int d); ~Person(); protected: char *name;
7
by: rsk | last post by:
char *i_reg_fname = "none"; -- Message posted using http://www.talkaboutprogramming.com/group/comp.lang.c/ More information at http://www.talkaboutprogramming.com/faq.html
89
by: Tubular Technician | last post by:
Hello, World! Reading this group for some time I came to the conclusion that people here are split into several fractions regarding size_t, including, but not limited to, * size_t is the...
3
by: vainstah | last post by:
Hello Guys and Galls, To start off, I have reached the solution I was looking for, but I would like comments and feedback on the solution I have reached and tips/tricks on making it more elegant....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.