Warum ergibt das double bzw 1?

Sebastian Pizer

_matze schrieb:

Und ein char fasst genau 8 Bit Daten, egal ob von 0-255 (unsigned) oder von (-128)-127.

Sorry, aber das ist falsch.
1. Ein char kann aus mehr als 8 Bits bestehen
2. Der Standard garantiert nicht, dass ein vorzeichenbehafteter char -128 darstellen kann. Das liegt daran, dass er das Zweierkomplement nicht vorschreibt. Demnach sind also auch alle logischen Bitoperationen auf vorzeichenbehafteten Ganzzahlen implementierungsabhängig.

Diese Basics sollten bei jedem sitzen.

Gruß,
SP

unskilled

imho ist nicht mal garantiert, was bei einem signed wert bei über-/unterlauf passiert... das ist imho nur bei unsigned garantiert...

bb

Sebastian Pizer schrieb:

_matze schrieb:

Und ein char fasst genau 8 Bit Daten, egal ob von 0-255 (unsigned) oder von (-128)-127.

Sorry, aber das ist falsch.
1. Ein char kann aus mehr als 8 Bits bestehen
2. Der Standard garantiert nicht, dass ein vorzeichenbehafteter char -128 darstellen kann. Das liegt daran, dass er das Zweierkomplement nicht vorschreibt. Demnach sind also auch alle logischen Bitoperationen auf vorzeichenbehafteten Ganzzahlen implementierungsabhängig.

Diese Basics sollten bei jedem sitzen.

Gruß,
SP

Ein Byte ist heute nun einmal 8 Bit groß. Die variable Festlegung im Standard entstammt dem C Standard und als dieser festgelegt wurde war das noch nicht der Fall bzw. absehbar. _matze weiß das bestimmt, aber wenn man wirklich Probleme lösen will (hier die des TOs) muss man halt schauen wie es in der Realität aussieht, ausschließlich dem Standard folgend kann nicht begründet werden warum eine 1 heraus kommt.

Sebastian Pizer

Realistiker schrieb:

[...bla über 8-Bit-Bytes...]

Das ist ja alles schön und gut. Wenn _matze einen entsprechenden Qualifizierer wie "in der Regel" oder so benutzt hätte, hätte ich auch nicht gemeckert. Aber das hat er nicht. Meiner Meinung nach kann man nicht zu wenig darauf hinweisen, was der Standard garantiert und welche Freiheiten die Implementierungen haben. Das gilt ja nicht nur für char, sondern auch für andere Datentypen, sowie alle anderen Dinge, bei denen der Compiler freie Hand hat (copy elision, struct layout, empty class optimization, ...).

Realistiker schrieb:

ausschließlich dem Standard folgend kann nicht begründet werden warum eine 1 heraus kommt.

Auch wenn Du für eine Erklärung Implementierungsdetails "erraten" musst, ist das kein Grund zu behaupten, CHAR_BIT==8 wäre Gesetz.

Gruß,
SP

freakC++

Hey,
vielen Dank für eure Antworten! Ihr habt mir echt geholfen!

Vielen Dank
lg, freakC++

Realistiker schrieb:

Ein Byte ist heute nun einmal 8 Bit groß.

Fail.

Tim schrieb:

Fail.

Gegenbeispiel?

http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.4

http://home.att.net/~jackklein/c/inttypes.html#char

http://en.wikipedia.org/wiki/Byte (Unter History 2. )

@Gilder
Das ist schon klar. Das Wort Byte wird in vielen Zusammenhängen verwendet. Nur wie häufig arbeitest du mit einer C++ Umgebung in welcher ein Byte tatsächlich nicht 8 Bit breit ist?

Für das vom OP dargestellte Problem braucht man imho keine langen Erklärungsversuche aus dem Hut zaubern. Entweder 16 * 16 passt in seiner Umgebung in den Wertebereich eines char Typs oder wir haben an der Stelle UB und jede weitere Diskussion ist sinnlos, weil statt dem Ergebnis 1 beim nächsten Programmdurchlauf die Festplatte gelöscht werden könnte.

c++-faq-lite schrieb:

[26.4] But, but, but what about machines where a char has more than 8 bits? Surely you're not saying a C++ byte might have more than 8 bits, are you?!?

Yep, that's right: a C++ byte might have more than 8 bits.

The C++ language guarantees a byte must always have at least 8 bits. But there are implementations of C++ that have more than 8 bits per byte

Das ist imho nicht richtig. Der Standard sagt auch nicht, dass es mindestends 8 Bit sein müssen. Bei Gegendarstellung bitte die Stelle im Standard angeben.

ISO/IEC 14882 schrieb:

1.7 The C + + memory model
1 The fundamental storage unit in the C + + memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C + + program consists of one or more sequences of contiguous bytes. Every byte has a unique address.

Nachdem das basic source character set 96 Zeichen enthält und somit das basic execution character set 100 Zeichen, sind auch 7 Bit vorstellbar.

TGGC

Die mathemtaische Begruendung ist: weil 1 == ( 16 * 16 + 1 ) mod 256. Und dein PC sowie Compiler halten sich an diese Arithmetik.

andi01 schrieb:

ich denke mal das hängt einfach von der zahl der nachkommastellen ab:
2.1*2.0=4.20;-->2 nachkommastellen-->double
2.1+2=4.1;-->1 Nachkommastelle-->float

um nicht unnötig genauigkeit zu verlieren nimmt das programm halt mal double da passt das ergebnis sicher ein.

mfg,
andi01.

Unsinn! f'`8k

Autocogito

Gruß, TGGC (Was Gamestar sagt...)

Sebastian Pizer

Nachfrager schrieb:

Für das vom OP dargestellte Problem braucht man imho keine langen Erklärungsversuche aus dem Hut zaubern. Entweder 16 * 16 passt in seiner Umgebung in den Wertebereich eines char Typs oder wir haben an der Stelle UB

Nein, nicht UB, sondern implementation-defined.

Nachfrager schrieb:

Der Standard sagt auch nicht, dass es mindestends 8 Bit sein müssen. Bei Gegendarstellung bitte die Stelle im Standard angeben.

Siehe §18.2.2 "C library", climits --> limits.h, siehe ISO C Standard für limits.h:

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.

number of bits for smallest object that is not a bit field (byte)
CHAR_BIT 8

minimum value for an object of signed char
SCHAR_MIN -127 // -(2^7-1)

maximum value for an object of signed char
SCHAR_MAX 127 // 2^7-1

maximum value for an object of unsigned char
UCHAR_MAX 255 // 2^8-1

minimum value for an object of signed char
CHAR_MIN see below

maximum value for an object of signed char
CHAR_MAX see below

...
If the value of an object of type char is treated as a signed integer when used in an expression, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX. The value UCHAR_MAX shall equal 2^CHAR_BIT - 1.

Mehr oder weniger 1:1 aus dem Standard steht das nochmal hier.

Gruß,
SP

Sebastian Pizer schrieb:

Auch wenn Du für eine Erklärung Implementierungsdetails "erraten" musst, ist das kein Grund zu behaupten, CHAR_BIT==8 wäre Gesetz.

etwas später

Sebastian Pizer schrieb:

Siehe §18.2.2 "C library", climits --> limits.h, siehe ISO C Standard für limits.h:

...
- number of bits for smallest object that is not a bit field (byte)
CHAR_BIT 8

Hm ...

pumuckl

Hinweiser schrieb:

Sebastian Pizer schrieb:

Auch wenn Du für eine Erklärung Implementierungsdetails "erraten" musst, ist das kein Grund zu behaupten, CHAR_BIT==8 wäre Gesetz.

etwas später

Sebastian Pizer schrieb:

Siehe §18.2.2 "C library", climits --> limits.h, siehe ISO C Standard für limits.h:

...
- number of bits for smallest object that is not a bit field (byte)
CHAR_BIT 8

Hm ...

Wo ist das Problem?

CHAR_BIT == 8 ist nicht festgelegt.
CHAR_BIT >= 8
widerspricht sich nicht

pumuckl schrieb:

Wo ist das Problem?

CHAR_BIT == 8 ist nicht festgelegt.

CHAR_BIT >= 8
widerspricht sich nicht

Hast Recht. Absätze vollständig zu lesen bringt einem manchmal weiter.:)

Nachfrager schrieb:

Tim schrieb:

Fail.

Gegenbeispiel?

Wurden zwar schon welche gegeben, aber ein ganz konkreter Fall (und nicht irgendwas antikes): http://focus.ti.com/lit/ug/spru514c/spru514c.pdf (Seite 82)