float x = 2.1f;

x + 2 // Dies ergibt float, denn 2 wird zu int konvertiert!!??

x * 2.0 //Warum ergibt dies double? float nimmt doch auch Kommazahlen auf? 2.0 ist also für float ideal und müsste doch gar nicht konvertiert werden?

Könnt ihr mir helfen?

Vielen Dank
lg, freakC++

im ersten Fall entspräche das:
float > int, also

static_cast<float>(  x + static_cast<float>(2)  );

im zweiten fall double > float, also

static_cast<double>(   static_cast<double>(x)    *   2.0   );

würdest du 2.0f statt 2.0 schreiben, bliebe alles bei float. 2.0 ist nunmal double

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

mfg,
andi01.

Kann man sagen, dass bei diser Schreibweise:

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:

float a=2.0;

Vielen Dank
lg, freakC++

Naja, da Du ja auch für Badestrands Antwort plädierst, werde ich mir diese nun verinnerlichen!

Vielen Dank
lg, freakC++

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

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++

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

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.

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

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

bb

_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.

[...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

Vielen Dank
lg, freakC++

Ein Byte ist heute nun einmal 8 Bit groß.

Fail.

Fail.

Gegenbeispiel?

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

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

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.

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

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

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

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 ...

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?

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

Wo ist das Problem?

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

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