ntohl usw...

Swordfish

drakon schrieb:

Ja, das stimmt, aber es gibt weiter noch short: 16 Bit, long: 32 Bit.

Wie kommst Du auf diesen Blödsinn!?

ISO/IEC 14882:2003(E) schrieb:

3.9.1 Fundamental types [basic.fundamental]

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 type40) ; 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.

(39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.

greetz, Swordfish

Foxx90

Ok, abe rehrlich gesagt verstehe ich nicht wofür man genau ntohl etc braucht .. ?
Oder besser gesagt wie werden float gehandhabt ...
Ich mein ich weiß dass diese funktionen lediglich little / big - endian umwandeln..
und das nur bei long / short.. was ist denn mit floats ?! oder doubles... muss man die nicht iwie in netbyte order umwandeln und gegebenfalls wieder umwandeln ?!

Gruß Chris

queer_boy

Foxx90 schrieb:

ok also ntohl etc sind für die bytedarstellung wichtig... aber wie ist das denn jetzt bei floats.. doubles? werden die auf jeder plattform gleich dargestellt ?
oder muss ich erst float in int umwandeln und dann die ints mit ntohl etc.. bearbeiten?

das würde wohl auch nicht portabel sein. konvertiere float/double lieber in ein format, dass du selbst bestimmst (und wenn es nur ASCII ist) - ansonsten musst du wohl nachforschen, ob dein compiler dir IEEE-float unterstützung anbietet.

camper

Swordfish schrieb:

drakon schrieb:

Ja, das stimmt, aber es gibt weiter noch short: 16 Bit, long: 32 Bit.

Wie kommst Du auf diesen Blödsinn!?

Das folgt aus den Mindestgrößen der Konstanten, die in limits.h/climits definiert werden.
ISO 9899: 5.2.4.2.1

drakon

Swordfish schrieb:

drakon schrieb:

Ja, das stimmt, aber es gibt weiter noch short: 16 Bit, long: 32 Bit.

Wie kommst Du auf diesen Blödsinn!?

Wie Camper schon schrib. Und es steht auch im "The C++ Programming Language"...

dot

*snipp*

sry, hab mich verklickt...

Foxx90

Ok, in welches Format würdest du es denn formatieren ?! zum Beipspiel in chars ?
Wobei es ja dann auch wieder nicht portabel ist

dot

camper schrieb:

Das folgt aus den Mindestgrößen der Konstanten, die in limits.h/climits definiert werden.
ISO 9899: 5.2.4.2.1

erstens sind es mindestgrößen und zweitens folgt das nur dann draus, wenn man davon ausgeht, dass das system auf einer entsprechenden integerrepräsentation (z.B. zweierkomplementdarstellung) basiert, was wiederum nirgendwo festegelegt ist. was den speicherbedarf angeht definiert der standard afaik nur dass gilt:

sizeof(char) == 1

und

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

man beachte: das wort bit oder byte fällt da nirgendwo...

drakon

Ich war mir eben auch nicht sicher, dann habe ich noch mal im Buch nachgeschaut und dort steht eben, dass GARANTIERT ist, dass short 16 und long 32 Bit hat...

EDIT:

Ok, garantiert MINDESTENS..

Swordfish

@camper: Wenn Du schon das genaue Kapitel ansprichst, dann möchte ich daraus etwas hervorheben:

ISO/IEC 9899:1999 (E) schrieb:

5.2.4.2.1 Sizes of integer types <limits.h>
1 The values given below shall be replaced by constant expressions suitable for use in #if
preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as would an
expression that is an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.

Somit ist "ein short hat genau 16 Bits" und "ein long hat genau 32 Bits" quatsch.

greetz, Swordfish

camper

Swordfish schrieb:

@camper: Wenn Du schon das genaue Kapitel ansprichst, dann möchte ich daraus etwas hervorheben:

ISO/IEC 9899:1999 (E) schrieb:

5.2.4.2.1 Sizes of integer types <limits.h>
1 The values given below shall be replaced by constant expressions suitable for use in #if
preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as would an
expression that is an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.

Somit ist "ein short hat genau 16 Bits" und "ein long hat genau 32 Bits" quatsch.

greetz, Swordfish

Das Wort "genau" wurde gar nicht benutzt (und ich habe es nat. nie gemeint; wir alle sind 32bit-Integer gewohnt, vorgeschrieben sind dort aber nur mindestens 16bit), ich gebe aber zu, dass man das missverstehen konnte - aber schließlich habe ich sogar selbst von Mindestgrößen gesprochen..., hier will mich evtl. jemand missverstehen. Allerdings bezweifle ich auch (und es ist mir daher auch nicht in den Sinn gekommen), dass drakon "genau" meinte, denn dann sind die folgenden Ungleichungen nahezu überflüssig.

@dot: unabhängig von der konkreten Darstellung muss z.B. ein short wenigstens 2*65535+1 verschiedene Zustände darstellen können, das geht nur mit wenigstens 16 bit für die value-Repräsentation. Alle Integertypen benutzen das Binärsystem um ihren Wert festzulegen - zudem sind nur 3 verschiedene Arten für die Darstellung negativer Zahlen zugelassen:
- Zweierkomplement
- Einerkomplement
- Vorzeichen+Betrag

Swordfish

camper schrieb:

Das Wort "genau" wurde gar nicht benutzt

Ich will dich nicht Missverstehen, es hat für mich den Anschein gehabt, denn:

drakon schrieb:

asc schrieb:

Nein. Ich glaube es gibt in C++ nur ein Typ wo der Standard besagt das er genau ein Byte groß ist: char.

Ja, das stimmt, aber es gibt weiter noch short: 16 Bit, long: 32 Bit.

...impliziert IMVVHO ein genau. Also sind wir uns jetzt einig, dass

sizeof( char ) == sizeof( unsigned char ) == sizeof( signed char ) == 1
2 <= sizeof( short int ) <= sizeof( int ) <= 4 <= sizeof( long int )
?

greetz, Swordfish

drakon

...impliziert IMVVHO ein genau. Also sind wir uns jetzt einig, dass

Sry. Habe ich nicht so gemeint.

sizeof( char ) == sizeof( unsigned char ) == sizeof( signed char ) == 1
2 <= sizeof( short int ) <= sizeof( int ) <= 4 <= sizeof( long )

So habe ich es gemeint und bin einverstanden.

camper

Swordfish schrieb:

camper schrieb:

Das Wort "genau" wurde gar nicht benutzt

Ich will dich nicht Missverstehen, es hat für mich den Anschein gehabt, denn:

drakon schrieb:

asc schrieb:

Nein. Ich glaube es gibt in C++ nur ein Typ wo der Standard besagt das er genau ein Byte groß ist: char.

Ja, das stimmt, aber es gibt weiter noch short: 16 Bit, long: 32 Bit.

...impliziert IMVVHO ein genau.

Es kann so interpretiert werden. Es ist aber nicht die einzig mögliche Deutung.

Also sind wir uns jetzt einig, dass

sizeof( char ) == sizeof( unsigned char ) == sizeof( signed char ) == 1
2 <= sizeof( short int ) <= sizeof( int ) <= 4 <= sizeof( long int )
?

Auf keinen Fall. Nirgendwo steht, dass 1 < sizeof(short) oder 3<sizeof(long) ist.
char kann ohne weiteres auch 32bit haben, und dann ist sizeof(long)==1 absolut möglich.

Swordfish

camper schrieb:

Auf keinen Fall.

Verdammt.

greetz, Swordfish

PS: assert( CHAR_BITS == 8 );

drakon

PS: assert( CHAR_BITS == 8 );

Haha..:D - Ich habe jetzt DAS einfach mal angenommen.

Swordfish

Tja, angenommen, man irrt sich

greetz, Swordfish

Foxx90

Ich will wirklich nicht eure "Religiösen-Debatten" stören xDDD
Aber könntet ihr mir vielleicht mal gaaaaaaaaaaaannz kurz helfen ?
Ihr hattet vor einnniiiger Zeit (eben iwann) geschrieben ich solle float etc einfach in bekannte daten typen converten... also wenn ich z.b. ein float in 2 chars speicher... die übertrage (tcp etc) und dann wieder in ein float konvertiere.. is das dann in ordnung ? wegen der byte-order... oder is das nur bei ganzzahlen wichtig ?!

Gruß Chris

Swordfish

Du störst doch nicht

Wahrscheinlich soetwas in der Art:

float value = 1.234f;

if( sizeof( value ) <= sizeof( short ) ) {

    unsigned short *p = reinterpret_cast< unsigned short* >( &value );
    s_value = htons( *p );

} else if( sizeof( value ) <= sizeof( long ) ) {

    unsigned long *p = reinterpret_cast< unsigned long* >( &value );
    l_value = htonl( *p );

} else {

    // Houston, we've got a problem...
}

greetz, Swordfish

Foxx90

ahh ok aber es ist doch nötig wie ich vermutet habe, dass man float auch so handhaben sollte oder ? ich hab neulich in die sfml mal reingeschaut ...
die Klasse Package dort handhabt nur short und int bzw long so ... d.h. mit floats bzw. double wird nichts gemacht.. aber im prinzip sollte man das doch so machen wie du geschrieben hast oder?

Gruß Chris