Umwandlung von Int-Typen

geeniusRL

Also ich hab das noch nich so ganz gerafft, wie das mit der Umwandlung von den Typen funktioniert und mit dem signed und unsigned und was da is wenn da was minus is...

also ich habe einen signed char (also ich benutze ihn als zahl, weil das ja eigentlich geht und ich halt keinen 2-Byte int will...) und der hat den wert

-5

also müsste dann im speicher an der stelle

11111011 = 251 stehen

soweit richtig?

so und jetzt kommt die sache, die ich nich ganz peile...

wenn ich das ganze jetzt in einen (signed) int umwandle, dann ist der wert doch

0000000011111011 = 251

und die zahl somit nicht mehr negativ...

oder wird dann so was

1111111111111011

gebastelt, dass das ganze -5 bleibt?

ness

Wenn du einem unsigned was negatives zuweist gibts nen bufferunderflow. Soll heißen, der Wert ist wieder positiv. Wenn du das dann nach signed castest, bleibts das auch.

leo aka qsch

bei signed wird ein bit dafuer verwendet um zu kennzeichnen ob die zahl negativ/positiv ist..
bei unsigned wird dieses bit einfach fuer einen groesseren Wertebereich benutzt

//EDIT ups seh grad das war gar nicht gefragt

groovemaster

ness schrieb:

Wenn du einem unsigned was negatives zuweist gibts nen bufferunderflow. Soll heißen, der Wert ist wieder positiv. Wenn du das dann nach signed castest, bleibts das auch.

Nein, der Wert wird wieder negativ. Beim signed <-> unsigned Casten wird auf Bitebene ja nix verändert, lediglich die Interpretation der Bits ist eine andere. Zu beachten gibt es hier lediglich die Speicherbreite des verwendeten Datentyps. Wenn du also zB -5 von signed char nach unsigned char castest, bekommst du 251. Wenn du das dann wieder nach signed char castest, erhälst du wieder -5. Aber ein Casten nach signed short zB, bringt weiterhin den Wert 251, weil auf den meisten Plattformen short einen grösseren Wertebereich als char hat in den dieser Wert problemlos hineinpasst.

ness

Ein, na das wusste ich nicht. Ok, benutzt man auch nicht soo oft, aber da hab ich wohl schon bei den casts was falsch verstanden. Das von dir genannte Ergebnis hätte ich bei reinterpret_cast erwartet...
*Gleichmaltesten* -- stimmt - für -4. Aber wenn ich das:

int main()
{
	unsigned a=-4294967292;
	cout<<a<<endl;
	cout<<static_cast<int>(a);
	cin.get();
	return 0;
}

kompiliere erhalte ich 2* 4 als Ausgabe... Halt warte, ich habs: es wird gecastet, und dabei gibt es einen integer-underflow?

camper

-4294967292 impliziert einen 64bit integer, also kommt es bereits bei der zuweisung zu einem cast, i.d.r. erhälst du eine warnung vom compiler. 4 entspricht den niederwertigen 32bit dieser zahl (kann man auch mit wrap-around erklären, dank zweierkomplement ist da kein unterschied).

groovemaster

@ness
Du solltest dir in Zukunft abgewöhnen, deine Compiler Warnungen zu ignorieren oder gar abzustellen.
Dass bei der Zuweisung von a bereits eine implizite Konvertierung vorgenommen wird, sollte dir schon deshlab auffallen, da ein unsigned Typ nunmal keine negativen Werte in seinem Wertebereich hat.

ness

@groovemaster: Natürlich wird eine implizite konvertierung vorgenommen, das ist klar. Aber im gesamten Thred gehts doch darum, einem unsigned einen negativen Wert zuzuweisen...

groovemaster

ness schrieb:

@groovemaster: Natürlich wird eine implizite konvertierung vorgenommen, das ist klar.

Warum wunderst du dich dann, dass 2 mal 4 als Ausgabe kommt?

ness schrieb:

Aber im gesamten Thred gehts doch darum, einem unsigned einen negativen Wert zuzuweisen...

Wenn ich geeniusRL richtig verstanden hab, gehts ihm grundsätzlich um signed <-> unsigned Umwandlung. Und das ist mehr als die Interpretation von Literalen.