int8_t/uint8_t

On Jul 3, 2:30*am, Chris Forone <4...@gmx.atwrote:

Quote: hello group, > is the cast of int8_t and uint8_t in char for streaming in both directions (put(), get()) defined/plattform independent? > i have read here in the forum, that int8_t and uint8_t are guaranteed 2s complement, ist the cast between them bit-identical (or is to big unsigned in signed undef)? > are all three chars (char, signed char, unsigned char) on every plattform the same size? > is there a best practise to stream char plattform independend? > thanks a lot! > cheers, chris

I'm not sure I understand your question; but I think the quick answer
is 'no'; at the very least you must consider endianess issues.

"Chris Forone" <4one@gmx.atwrote in message news:g4hrm1$dsl$1@newsreader2.utanet.at...

Quote: hello group, is the cast of int8_t and uint8_t in char for streaming in both directions (put(), get()) defined/plattform independent?

I don't think int8_t and uint8_t are defined on all platforms.

Quote: i have read here in the forum, that int8_t and uint8_t are guaranteed 2s complement, ist the cast between them bit-identical (or is to big unsigned in signed undef)?

Probably.

Quote: are all three chars (char, signed char, unsigned char) on every plattform the same size?

On all platforms sizeof (char) == sizeof (signed char) == sizeof (unsigned char) == 1.

Quote: is there a best practise to stream char plattform independend?

I don't understand this question, but probably there is a best practice.

joseph cook schrieb:

Quote: On Jul 3, 2:30 am, Chris Forone <4...@gmx.atwrote: Quote: >hello group, >> >is the cast of int8_t and uint8_t in char for streaming in both >directions (put(), get()) defined/plattform independent? >> >i have read here in the forum, that int8_t and uint8_t are guaranteed 2s >complement, ist the cast between them bit-identical (or is to big >unsigned in signed undef)? >> >are all three chars (char, signed char, unsigned char) on every >plattform the same size? >> >is there a best practise to stream char plattform independend? >> >thanks a lot! >> >cheers, chris > I'm not sure I understand your question; but I think the quick answer is 'no'; at the very least you must consider endianess issues.

i only use (u)int8_t/(u)int16_t/(u)int32_t in my app. the endianess is
no problem, because i can only stream char, which is signed/unsigned
char (depends on impl.). the 16 bit i stream with Put(val >8) and
Put(val), the 32 bit with Put(val >24) ... Put(val), the Gets() are
equivalent. i think, serialized objects should be readable on most
plattforms, i only need the big 3 (linux/mac/win, alphabetical). the
only problem is, that i have to cast before the shift to unsigned char,
so the bit-identical is very important because i can only test on 2
plattforms...

cheers, chris

Chris Forone wrote:

Quote: hello group, > is the cast of int8_t and uint8_t in char for streaming in both directions (put(), get()) defined/plattform independent? > i have read here in the forum, that int8_t and uint8_t are guaranteed 2s complement, ist the cast between them bit-identical (or is to big unsigned in signed undef)?

They are twos complement, *if they exist*. On platforms with ones
complement, or 9 bit bytes, you're toast.

Quote: > are all three chars (char, signed char, unsigned char) on every plattform the same size?

They are all the same size on a given platform. Was that your
question?

Quote: > is there a best practise to stream char plattform independend?

The best way to be platform independent is to define the transport
format separately. They you have to implement this on each platform,
in a platform dependent way.


Bo Persson

On Jul 3, 4:21*am, joseph cook <joec...@gmail.comwrote:

Quote: On Jul 3, 2:30*am, Chris Forone <4...@gmx.atwrote:

Quote: Quote: is the cast of int8_t and uint8_t in char for streaming in both directions (put(), get()) defined/plattform independent? > Quote: i have read here in the forum, that int8_t and uint8_t are guaranteed 2s complement, ist the cast between them bit-identical (or is to big unsigned in signed undef)? > Quote: are all three chars (char, signed char, unsigned char) on every plattform the same size? > Quote: is there a best practise to stream char plattform independend? > I'm not sure I understand your question; but I think the quick answer is 'no'; at the very least you must consider endianess issues.

There are no endian issues to consider with 8-bit data. So the quick
answer is "yes", int8_t and uint8_t (unlike "char") are guaranteed to
use two's complement integer representation.

Greg

On Thu, 03 Jul 2008 08:30:22 +0200, Chris Forone <4one@gmx.atwrote
in comp.lang.c++:

Quote: hello group, > is the cast of int8_t and uint8_t in char for streaming in both directions (put(), get()) defined/plattform independent? > i have read here in the forum, that int8_t and uint8_t are guaranteed 2s complement, ist the cast between them bit-identical (or is to big unsigned in signed undef)?

People tend to say that, but they're wrong, of course. The exact
width integer types aren't actually part of standard C++ yet, but they
soon will be.

As defined in C, int#_t is required to be a signed integer type of the
specified number of bits with no trap representations and no padding
bits. It uses 2's complement for representing negative values.

But uint#_t types only hold unsigned values. They cannot represent
negative values, so they aren't ever 2's complement, 1's complement,
or sign and magnitude. These three things only apply to signed
integer types, and never to unsigned integer types.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html