Warum ergibt das double bzw 1?

drakon

2.0
3.0
9.0

automatisch der Typ double verwendet wird. Wenn ich diese Zahl als float haben möchte, dann muss ich das direkt forder:

Flieskommazahlen, welche kein Suffix (f) haben, werden als double angenommen.

Wenn du float haben willst, dann mit dem entsprechenen Suffix:

2.0f; //float
2.0; //double

freakC++

Alles klar, dann habe ich das kapiert!!

Es bleibt aber noch eine Frage, weshalb ich den Titel des Threads auch geändert habe:

#include <iostream>
using namespace std;
#define square(a) ((a) * (a))

int main()
{
	char m = (char)square(16);
	cout << m+1 << endl;

	return 0;
}

Warum kommt hier 1 heraus? m hat den Wert 127, aber ich dachte, dass dies gar nicht mehr im Wertebereich eines char liegts. Oder liegt es daran, dass char auch größer sein kann, aber 8 bits auf jeden Fall da sind?

Eine ASCII Tabelle kann mir da aber auch nicht helfen...warum kommt 1 heraus?

Vielen Dank
lg, freakC++

drakon

Wertebereich von char: -128 - + 127 (msvc++08 signed)

Du weist 256 zu, was dazu führt, dass char überläuft:
bei "128" wird es zu -128 und die restlichen 128 kommen noch dazu und ergeben 0 und das + 1 = 1

_matze

Ein char kann nur 8 Bit fassen. Dein 16^2 ergibt 256, also binär 100000000. In ein char passt aber 00000000. Das passt einfach nicht! So, wenn du nun 00000000 gespeichert hast, und noch eins draufaddierst, bist du wo?

Wie du darauf kommst, dass m 127 hat, weiß ich nicht...

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

Sebastian Pizer

freakC++ schrieb:

Es bleibt aber noch eine Frage, weshalb ich den Titel des Threads auch geändert habe:
#include <iostream>
using namespace std;
#define square(a) ((a) * (a))

int main()
{
	char m = (char)square(16);
	cout << m+1 << endl;

	return 0;
}
Warum kommt hier 1 heraus? m hat den Wert 127,

Hat es? Ich dachte, 16*16=256. Und die 256 passt nicht in einen 8bit-Character. Wir wissen auch nicht, ob char bei Dir vorzeichenbehaftet ist, oder nicht. Falls char vorzeichenlos und 8bittig ist, ist m=0. Falls char vorzeichenbehaftet ist, ist das Ergebnis implementierungsabhängig (sprich: Schau in der Dokumentation Deines Compilers nach, was er macht. Der Standard garantiert hier nichts).

Angenommen, Dein Compiler macht aus (char)(256) eine 0.

freakC++ schrieb:

warum kommt 1 heraus?

Offensichtlich, weil m 0 ist. Das Ergebnis von char+int ist auf jeden Fall int. Das Ergebnis von char+char ist auch ein int. Das liegt an der "integral promotion". Die Ganzzahltypen char, signed char, unsigned char, short und unsigned short werden zu int konvertiert, wenn Du mit denen rechnen willst und ein int all die Werte darstellen kann. Wenn Du std::cout über den << Operator einen int gibst, wird die Zahl textuell dargestellt ---> "1"

Gruß,
SP

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)