Printable View
I'm writing an im-client that should connect to the icq server, meaning I need to fiddle around with the oscar/flap/snac/tlv protocols/stuff. Let's say a certain tlv needs to be four byte, no more , no less. And on my system an int is four byte and I use that type. Then on some other system an int maybe is only two byte, then nothing would work. Then I'd be sending tlv:s to the server that's only two byte large and the server wouldn't be able to read anything. How to solve this?
So the server is only expecting 4 bytes right?? Cant you use 4 chars, because chars are always 1 byte, or an unsigned long, or long int, would do the trick I think (not sure about the last there).
Well you could wrap up the translation from the external representation (message of 4 bytes) and the internal representation (say an int) using a class.
This can hide away your choice of data types, and can also solve that endian problem which invariably arises when doing network programming.
You should never rely on some external message mapping nicely to an internal data type, not if you want portability as well.
From what I've read a char isn't always one byte, and even if it were, one byte wouldn't always be eight bits... Don't know how accurate that is, but better to be safe than sorry!
How do you mean wrap up the translation between internal and external representation? And yes, portabillity is important for me so... :-)
perhaps bit fields would work?
what do you mean bit fields?
No. A char is defined in the standard as always being one byte.Quote:
From what I've read a char isn't always one byte
You can use the binary operators (<<, >>, &, !, ^, etc...) and "masks" to work directly with the binary bits. If you just have to store a bunch of true or false values, instead of using a whole byte or more to store the data, you can store 8 times as many by working with memory.Quote:
what do you mean bit fields?
You've lost me, gaah. Whatever you're trying to do is over my head, but a type LONG will always hold AT LEAST FOUR BYTES. Maybe you can use a long, have your program dynamically check the size using <limits>, and trim-off the unused bits like misplaced & sean suggested.
Here are the minimim capacities for each type:
char -128 to +127 (1 byte)
unsigned char 0 to 255 (1 byte)
int -32,768 to +32,767 (2 bytes)
unsigned int 0 to 65535 (2 bytes)
long -2,147,483,648 to +2,147,438,647 (4 bytes)
unsigned long 0 to 7,294,967,295 (4 bytes)
float +/- 2.1E-38 to +/- 3.4 E38 (4 bytes)
double +/- 2.2E-308 to +/- 1.8 E308 (8 bytes)
[EDIT] - Here's a little from the ANSI/ISO C++ language standard. (Sorry about the formattng.)
Quote:
[basic.fundamental] 3.9.1 Fundamental types
1 Objects declared as characters (char) shall be large enough to store any member of the implementation’s
basic character set. If a character from this set is stored in a character object, the integral value of that character
object is equal to the value of the single character literal form of that character. It is implementationdefined
whether a char object can hold negative values. Characters can be explicitly declared unsigned
or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a
signed char, and an unsigned char occupy the same amount of storage and have the same alignment
requirements (3.9); that is, they have the same object representation. For character types, all bits of
the object representation participate in the value representation. For unsigned character types, all possible
bit patterns of the value representation represent numbers. These requirements do not hold for other types.
In any particular implementation, a plain char object can take on either the same values as a
signed char or an unsigned char; which one is implementationdefined.
2 There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this
list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural
size suggested by the architecture of the execution environment 39) ; the other signed integer types are
provided to meet special needs.
3 For each of the signed integer types, there exists a corresponding (but different) unsigned integer type:
“unsigned char”, “unsigned short int”, “unsigned int”, and “unsigned long
int,” each of which occupies the same amount of storage and has the same alignment requirements (3.9)
as the corresponding signed integer type 40) ; that is, each signed integer type has the same object representation
as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type
is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding
signed/unsigned type shall be the same.
4 Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number
of bits in the value representation of that particular size of integer. 41)
Actually, DougDbug, no.
There are very few invariants in C++:
1) sizeof(char) == 1
Note: 1 means one byte, but we don't know what 1 byte is. It might be any number of bits.
2) sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) ( <= sizeof(long long) )
Note: among other things, this means that in theory a long might be 1 byte small.
3) sizeof(float) <= sizeof(double) <= sizeof(long double)
To the best of my knowledge, the standard mentions nothing beyond these three.
The C99 standard, on the other hand, specifies the existence of a header called stdint.h, which contains types with a known number of bits. int8_t, int16_t, ...
As of yet, the C++ standard doesn't require the existence of this header. Microsoft C++ does not yet support it, as of .Net 2003. I don't know about 2005.
The Boost libraries offer the cstdint.hpp header, which aims to provide the contents of stdint.h even for compilers and platforms that don't have the standard header. However, if you port to a really exotic platform, you may have to implement the header yourself, and you may also find yourself incapable of doing so, given that the compiler in question might not provide types of this size.
(It should be noted, however, that such a compiler/platform combo is of no use in the real, connected world anyway.)