Forum: PC-Programmierung Frage zu Datentypen in C++


von Lui (Gast)



Lesenswert?

Hi,

Ich schreibe gerade ein Programm um Datentypen besser zu verstehen.
Screenshots befinden sich im Anhang.
Nun bekomme ich aber bei der Ausgabe die Information, dass ein Float und 
ein Double gleich lang sind. Das macht keinen Sinn oder? Was mache ich 
falsch?

Vielen Dank schon mal


#include<iostream>

int MinusOne(int number)
{
    return number -= 1;
}

int BytToBit(int byte)
{
    int bit = (byte*=8);
    return bit;
}

template <class god>

void printInfo( god x, char name[20])
{
    std::cout << "Der Datentyp " << name << " hat " << sizeof(x) << " 
Bytes und " << BytToBit(sizeof(x)) << " Bits mit denen man 2^" << 
BytToBit(sizeof(x))
    << " Werte darstellen kann.\nDruch das Zweierkomplement liegt der 
Wertebereich bei: -2^" <<  MinusOne(BytToBit(sizeof(x))) << " bis 2^"
    <<  MinusOne(BytToBit(sizeof(x))) << "-1, da die Null als positive 
Zahl gezaehlt wird\n\n";
}

int main()
{

    float a;
    char nameA [20] = "float";
    long b;
    char nameB [20]= "long";
    long long c;
    char nameC [20] = "long long";

    std::cout << "\nDiese Datentypen werden im Zweierkomplement 
gespeichert bei dem die Null als positive Zahl gewertet wird:\n\n\n";

    printInfo(a, nameA);
    printInfo(b, nameB);
    printInfo(c, nameC);
    return 0;
}

von Walter T. (nicolas)


Lesenswert?

Lui schrieb:
> Nun bekomme ich aber bei der Ausgabe die Information, dass ein Float und
> ein Double gleich lang sind. Das macht keinen Sinn oder?

Auf einem 64-Bit-System ist das nicht ungewöhnlich.

Um mehr zu sagen, müsste man Deinen Compiler, das Betriebssystem und die 
Compileroptionen kennen.

: Bearbeitet durch User
von Volker Z. (vzavza)


Lesenswert?

Ich sehe kein Deklaration mit Double. Zeig mal die Ausgabe.

Gruß  Volker

von Dirk B. (dirkb2)


Lesenswert?

Lui schrieb:
> int MinusOne(int number)
> {
>     return number -= 1;
> }

Warum das = ?

von Dirk B. (dirkb2)


Lesenswert?

Wie sieht es bei char, short und long double aus?

Was kommt raus, wenn du das mal ohne template machst?

von mh (Gast)


Lesenswert?

Walter T. schrieb:
> Lui schrieb:
>> Nun bekomme ich aber bei der Ausgabe die Information, dass ein Float und
>> ein Double gleich lang sind. Das macht keinen Sinn oder?
>
> Auf einem 64-Bit-System ist das nicht ungewöhnlich.

Auf 32 Bit Systemen Ok, aber auf welchem 64 Bit System ist denn 
sizeof(double) == sizeof(float)?

von Experte (Gast)


Lesenswert?

Lui schrieb:
> int bit = (byte*=8);

warum? Warum? WARUM?

von cppbert3 (Gast)


Lesenswert?

Die funktion sollte ByteToBits heissen

Bits = Bytes * 8;

oder

return number - 1;

deine Anwendung von *= und -= ist total komisch

sizeof float, double sollte 4 und 8 ergeben, oder machst du sizeof 
pointer?

von Al Fine (Gast)


Lesenswert?

mh schrieb:
> Auf 32 Bit Systemen Ok, aber auf welchem 64 Bit System ist denn
> sizeof(double) == sizeof(float)?

Wieso? Lass sie doch, wenns Spass macht. Kann man bestimmt in der 
BuildConfig vom Compiler angeben.

von cppbert3 (Gast)


Lesenswert?

Al Fine schrieb:
> mh schrieb:
>
>> Auf 32 Bit Systemen Ok, aber auf welchem 64 Bit System ist denn
>> sizeof(double) == sizeof(float)?
>
> Wieso? Lass sie doch, wenns Spass macht. Kann man bestimmt in der
> BuildConfig vom Compiler angeben.

Das hat nichts mit irgendwelchen BuildConfigs zu tun, es gibt so gut wie 
gar kein Hardware-System das jünger als 40 Jahre ist wo das nicht so 
ist, was nicht heisst das alle System single oder double Precision 
supporten, aber wenn dann so

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> das jünger als 40 Jahre ist

Die meisten (eher alle) folgen diesem 1985 Standart

https://en.m.wikipedia.org/wiki/IEEE_754

von Al Fine (Gast)


Lesenswert?

cppbert3 schrieb:
> Al Fine schrieb:
>> mh schrieb:
>>
>>> Auf 32 Bit Systemen Ok, aber auf welchem 64 Bit System ist denn
>>> sizeof(double) == sizeof(float)?
>>
>> Wieso? Lass sie doch, wenns Spass macht. Kann man bestimmt in der
>> BuildConfig vom Compiler angeben.
>
> Das hat nichts mit irgendwelchen BuildConfigs zu tun, es gibt so gut wie
> gar kein Hardware-System das jünger als 40 Jahre ist wo das nicht so
> ist, was nicht heisst das alle System single oder double Precision
> supporten, aber wenn dann so

Was hat denn die Harware damit zu tun? Das ist vielleicht naheliegend, 
sich an der Hardware zu orientieren - das war's aber auch schon.

von cppbert3 (Gast)


Lesenswert?

Al Fine schrieb:
> Was hat denn die Harware damit zu tun? Das ist vielleicht naheliegend,
> sich an der Hardware zu orientieren - das war's aber auch schon.

Das war mal vor langer langer Zeit anders aber in den letzten 
Jahrzehnten gibt es, wenn überhaupt mit Floating Point support, nur noch 
IEEE754 konformes, ansonsten wird nur mit Integer gerechnet, FPU 
Emulationssoftware ist auch ein Relikt aus den frühen 80ern, probier mal 
eine alte oder neue Hardware mit Floating Point support oder aktuelle 
FPU Emulation zu finden die nicht IEEE754 konform ist

von Al Fine (Gast)


Lesenswert?

cppbert3 schrieb:
> Das war mal vor langer langer Zeit anders aber in den letzten
> Jahrzehnten gibt es, wenn überhaupt mit Floating Point support, nur noch
> IEEE754 konformes, ansonsten wird nur mit Integer gerechnet, FPU
> Emulationssoftware ist auch ein Relikt aus den frühen 80ern, probier mal
> eine alte oder neue Hardware mit Floating Point support oder aktuelle
> FPU Emulation zu finden die nicht IEEE754 konform ist

Ja, aber der Punkt ist ja gerade, dass das Programm - stand Wissens - 
auch in irgendeinem abgef****ten emulator, interpreter oder weiß der 
Geier laufen könnte. Vielleicht hat auch irgendein Guru für 
Softwaretests einen "speziellen" Compiler auf dem System installiert.
Also, ja, geschenkt - Hardware wurde auch besser mit der Zeit: Es gibt 
sogar Standards!!! Die streng genommen nicht der C/C++-Standard sind 
btw.

von cppbert3 (Gast)


Lesenswert?

Al Fine schrieb:
> Ja, aber der Punkt ist ja gerade, dass das Programm - stand Wissens -
> auch in irgendeinem abgef****ten emulator, interpreter oder weiß der
> Geier laufen könnte. Vielleicht hat auch irgendein Guru für
> Softwaretests einen "speziellen" Compiler auf dem System installiert.

Davon kann man natürlich bei dem Eingangspost ganz klar ausgehen...

btw passt "abgefahren" gar nicht in abgef****ten rein ;)

von mh (Gast)


Lesenswert?

cppbert3 schrieb:
> was nicht heisst das alle System single oder double Precision
> supporten, aber wenn dann so

Ich habe explizit nach 64 Bit Systemen gefragt, bei denen sizeof(double) 
== sizeof(float) ist, da es ja "nicht ungewöhnlich" sein soll.

von PittyJ (Gast)


Lesenswert?

Ist das wieder so ein Trollposting, wo sich der Originalautor nie wieder 
auf Rückfragen meldet, und der Rest sich die Köppe heiss diskutiert?

Beitrag #6595222 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Lesenswert?

PittyJ schrieb:
> Ist das wieder so ein Trollposting, wo sich der Originalautor nie wieder
> auf Rückfragen meldet, und der Rest sich die Köppe heiss diskutiert?

Er hat wahrscheinlich längst peinlich berührt gemerkt, dass er nicht die 
Länge von "double" gemessen hat.

von Jonas B. (jibi)


Lesenswert?

--float_single
-fsingle

oder

--float_single2
-fsingle2

als Compiler flag gesetzt?

von (prx) A. K. (prx)


Lesenswert?

... und sein Code auch sonst auf Ganzzahlen abzielt.

: Bearbeitet durch User
von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> cppbert3 schrieb:
>
>> was nicht heisst das alle System single oder double Precision
>> supporten, aber wenn dann so
>
> Ich habe explizit nach 64 Bit Systemen gefragt, bei denen sizeof(double)
> == sizeof(float) ist, da es ja "nicht ungewöhnlich" sein soll.

Verstehe ich nicht, egal ob 32 oder 64 bit system, float(single 
precision) sind 4 und double(double precision) 8 bytes, in den letzten 
Jahrzehnten...

von (prx) A. K. (prx)


Lesenswert?

cppbert3 schrieb:
> Verstehe ich nicht, egal ob 32 oder 64 bit system, float(single
> precision) sind 4 und double(double precision) 8 bytes, in den letzten
> Jahrzehnten...

Nicht bei GCC für AVR. Ist aber ein 8-Bit System.

von mh (Gast)


Lesenswert?

(prx) A. K. schrieb:
> cppbert3 schrieb:
>> Verstehe ich nicht, egal ob 32 oder 64 bit system, float(single
>> precision) sind 4 und double(double precision) 8 bytes, in den letzten
>> Jahrzehnten...
>
> Nicht bei GCC für AVR. Ist aber ein 8-Bit System.

Auch nicht bei den 16-Bit PICs. Es geht auch nicht darum, ob cppbert3 es 
versteht, sondern ob jemand 64-Bit Systeme auflisten kann, bei denen 
sizeof(double) == sizeof(float) gilt.
Vor allem warte ich auf eine Antwort von  Walter T., denn er hat 
behauptet:
Walter T. schrieb:
> Auf einem 64-Bit-System ist das nicht ungewöhnlich.

von cppbert3 (Gast)


Lesenswert?

(prx) A. K. schrieb:
> cppbert3 schrieb:
>
>> Verstehe ich nicht, egal ob 32 oder 64 bit system, float(single
>> precision) sind 4 und double(double precision) 8 bytes, in den letzten
>> Jahrzehnten...
>
> Nicht bei GCC für AVR. Ist aber ein 8-Bit System.

8 und 16 bit Systeme sind was anderes, aber ich glaube fast nicht das um 
diese hier geht

von Dirk B. (dirkb2)


Lesenswert?

Es kann passieren, dass float-Berechnungen als double durchgeführt 
werden.

Und bei C werden float-Parameter bei Funktionen mit variablen Argumenten 
in double Umgewandelt.
(Darum gibt es kein %lf bei printf, bzw. ist mit %f identisch)

Im Speicher(bedarf) unterscheiden sie sich aber.

von Walter T. (nicolas)


Lesenswert?

mh schrieb:
> Vor allem warte ich auf eine Antwort von  Walter T., denn er hat
> behauptet:
> Walter T. schrieb:
>> Auf einem 64-Bit-System ist das nicht ungewöhnlich.

Das nehme ich zurück. Es scheint doch eher exotisch zu sein. Schade 
eigentlich.

Ungefähr seit der ersten Opteron-Generation waren 
64-Bit-Double-Operationen zumindest nicht mehr ernsthaft benchmarkbar 
langsamer als 32-Bit-Single-Precision-Float-Operationen (Umfeld 
Lapack/Scalapack). Es wäre eigentlich die Gelegenheit gewesen, 
64-Bit-Float zum Default zu machen. Dann müßte man nicht die 32-Bit- und 
die 64-Bit-Math-Libraries gemeinsam dazulinken.

von mh (Gast)


Lesenswert?

Walter T. schrieb:
> Ungefähr seit der ersten Opteron-Generation waren
> 64-Bit-Double-Operationen zumindest nicht mehr ernsthaft benchmarkbar
> langsamer als 32-Bit-Single-Precision-Float-Operationen (Umfeld
> Lapack/Scalapack). Es wäre eigentlich die Gelegenheit gewesen,
> 64-Bit-Float zum Default zu machen. Dann müßte man nicht die 32-Bit- und
> die 64-Bit-Math-Libraries gemeinsam dazulinken.
Meinst du das ernst? Auf meiner CPU ist float 2x schneller als double, 
da die doppelte Menge an floats gleichzeitig verarbeitet werden können. 
Dazu brauchen doubles die doppelte (wer hätte das gedacht) Menge an 
Speicher. Das macht für dich vielleicht keinen Unterschied, wenn du mit 
ner handvoll Werten zu tun hast. Andere Anwendungen kratzen ständig am 
Speicherlimit. Es gibt nen Grund, warum es halfs (16-Bit floating point) 
gibt.

von Walter T. (nicolas)


Lesenswert?

mh schrieb:
> Dazu brauchen doubles die doppelte (wer hätte das gedacht) Menge an
> Speicher. Das macht für dich vielleicht keinen Unterschied, wenn du mit
> ner handvoll Werten zu tun hast.

Naja, ca. 500000 Gleichungen mit 500000 Unbekannten ist jetzt auch kein 
Kleinkram. Aber stimmt: Wirklich riesig ist das auch nicht (Sparse mit 
schöner Bandstruktur).

Doppelter Speicher juckt mich selten. Speicher kann man dazustecken. 
Interessanter ist, ob man doppelt so viele Float-Werte aus dem Speicher 
in die FPU bekommt. Weiß wer dazu mehr? Ich bin kein Informatiker.

mh schrieb:
> Auf meiner CPU ist float 2x schneller als double,

Gut, dass Du dazugeschrieben hast, welche CPU das ist.

Ich will nicht ausschließen, dass eine geschickte SIMD-Programmierung 
mit einer aktuellen FPU wieder float schneller als double macht. Aber da 
hätte ich gerne mal Benchmarks.

Bei schlecht gestellten Problemen hat double eben den Vorteil, dass 
weniger Schritte für Konvergenz nötig sind (und das System insgesamt 
gutmütiger ist). Wenn double und float gleich schnell sind, heißt das, 
das double effektiv schneller ist.

: Bearbeitet durch User
von mh (Gast)


Lesenswert?

Walter T. schrieb:
> Doppelter Speicher juckt mich selten. Speicher kann man dazustecken.
Du kannst vielleicht mehr Speicher dazu stecken. Ich müsste den 
aktuellen Speicher ersetzen. Kannst du mal nach Verfügbarkeit und 
Preisen für 4 x 64GB DDR4-3600 in vier Modulen suchen und dein Ergebnis 
hier Posten?

Walter T. schrieb:
> Interessanter ist, ob man doppelt so viele Float-Werte aus dem Speicher
> in die FPU bekommt. Weiß wer dazu mehr? Ich bin kein Informatiker.
Wo soll das Problem sein? Den Speicherbus und Cache interessiert nicht, 
ob das 1 double oder 2 floats sind, beides sind 64 Bit.

Walter T. schrieb:
> Gut, dass Du dazugeschrieben hast, welche CPU das ist.

Jeder AMD Ryzen oder Threadripper oder Intel iIrgendwas, nahezu jede AMD 
oder Nvidia GPU, ...

von Rolf M. (rmagnus)


Lesenswert?

Walter T. schrieb:

> Ungefähr seit der ersten Opteron-Generation waren
> 64-Bit-Double-Operationen zumindest nicht mehr ernsthaft benchmarkbar
> langsamer als 32-Bit-Single-Precision-Float-Operationen (Umfeld
> Lapack/Scalapack).

Ich würde sagen, das war eher bei (viel) älteren PCs so, denn die 
klassische FPU hat eh immer in 80 Bit gerechnet und beim Speichern dann 
die überzähligen Bits verworfen. Mit den ganzen SIMD-Erweiterungen heute 
kann man aber mehrere float-Berechnungen parallel ausführen, und je 
kleiner der Typ, desto mehr davon gehen gleichzeitig.

> Es wäre eigentlich die Gelegenheit gewesen, 64-Bit-Float zum Default zu
> machen. Dann müßte man nicht die 32-Bit- und die 64-Bit-Math-Libraries
> gemeinsam dazulinken.

Und wenn man dann bewusst nur 32 Bit will, weil 64 Bit zu viel Speicher 
brauchen würden oder die GPU bei 64 Bit extrem langsam ist (ist z.B. bei 
sämtlichen Computerspielen so)? Dann hätte man keinen 
Standard-Datentypen mehr, mit dem man das darstellen kann, denn float 
ist der kleinstmögliche.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.