std::intx_t vs integers

[KK27]

Hallo zusammen,

im SourceCode auf der Arbeit sehe ich immer wieder alten Legacy Code wo typedef von int, short, long etc. gemacht werden und es teilweise unklar wird, was dahintersteht. Zum Beispiel:

typedef int SHORT;

Dann habe ich die fixen std integers entdeckt. In den Fällen, wo man eine spezifische Range braucht, sind diese doch immer vorzuziehen. Eigentlich sehe ich keinen Grund, warum man die std integers nicht verwenden sollte. Oder gibt es welche?

In Zukunft möchte ich stattdessen std::int8_t etc. verwenden

[SeppJ]

Das ist richtig. Die std Integer sind die standardisierte Methode, damit man das nicht mehr selber basteln muss, wenn man das braucht. Aber die gab es halt nicht immer, daher findet man das in altem Code teils noch selbst gebastelt.

[KK27]

@SeppJ sagte in std::intx_t vs integers:

Das ist richtig. Die std Integer sind die standardisierte Methode, damit man das nicht mehr selber basteln muss, wenn man das braucht. Aber die gab es halt nicht immer, daher findet man das in altem Code teils noch selbst gebastelt.

Wobei ich in meinem Fall die std Integers auch gegenüber short oder long long bevorzugen würde. Einerseits weil manche Integer unterschiede Wertebereiche haben können und andererseits damit es einheitlich ist.

[DirkB]

@KK27 sagte in [std::intx_t vs

Wobei ich in meinem Fall die std Integers auch gegenüber short oder long long bevorzugen würde. Einerseits weil manche Integer unterschiede Wertebereiche haben können und andererseits damit es einheitlich ist.

Dann solltest du aber auch die least und fast Typen beachten.
Z.B.: uint_least16_t , int_fast8_t

Denn du bist selten auf die genaue Bitbreite angewiesen.
Der Wertebereich muss nur ausreichend groß sein.

[*john 0]

@KK27 sagte in std::intx_t vs integers:

Wobei ich in meinem Fall die std Integers auch gegenüber short oder long long bevorzugen würde. Einerseits weil manche Integer unterschiede Wertebereiche haben können und andererseits damit es einheitlich ist.

Das Problem ist, dass zum Teil die APIs unterschiedliche Datentypengrößen erfordern. Das bekannteste Beispiel ist size_t, und je nachdem für welche Plattform man Programme schreibt, ist size_t 16Bit, 32Bit, 64Bit oder zukünftig gar 128Bit groß. Anstelle von size_t eine feste Größe zu nutzen ist nicht sinnvoll.

[KK27]

@john-0 sagte in std::intx_t vs integers:

Das Problem ist, dass zum Teil die APIs unterschiedliche Datentypengrößen erfordern. Das bekannteste Beispiel ist size_t, und je nachdem für welche Plattform man Programme schreibt, ist size_t 16Bit, 32Bit, 64Bit oder zukünftig gar 128Bit groß. Anstelle von size_t eine feste Größe zu nutzen ist nicht sinnvoll.

In diesem Kontext würde ich die std integers natürlich nicht verwenden. Aber wenn ich eigene Klasse haben und selbst die Range des Integer definiere, dann machen die std Klassen Sinn.

@DirkB sagte in std::intx_t vs integers:

Dann solltest du aber auch die least und fast Typen beachten.
Z.B.: uint_least16_t , int_fast8_t

Aber spielt das eine so große Rolle? Ist der Performance Unterschied spürbar?

[SeppJ]

@KK27 sagte in std::intx_t vs integers:

Aber spielt das eine so große Rolle? Ist der Performance Unterschied spürbar?

Wenn Größe oder Geschwindigkeit Rolle spielen, dann ist das schon wichtig. Bei deiner Wald- und Wiesenanwendung ist das wahrscheinlich egal (und es ist ihr wahrscheinlich auch egal, wie groß genau die Integer sind). Aber wenn du hunderte Millionen Werte gleichzeitig im Speicher brauchst, oder wenn du hunderte Milliarden Rechenoperationen pro Programmablauf machst, dann ist die wahrscheinlich schon wichtig, dass die Integer nicht in einem doppelt so großem Format gehalten werden als nötig wäre, oder ob zu jeder Rechenoperation vorher noch ein Bitshift gemacht werden muss. (Und dummerweise geht meistens nur eines von beidem gleichzeitig)

[DirkB]

@KK27 sagte in std::intx_t vs integers:

@DirkB sagte in std::intx_t vs integers:

Dann solltest du aber auch die least und fast Typen beachten.
Z.B.: uint_least16_t , int_fast8_t

Aber spielt das eine so große Rolle? Ist der Performance Unterschied spürbar?

Du solltest dir schon überlegen, was du brauchst.
Wählst du die Bitbreite wegen des Speicherplatzes oder wegen des Wertebereichs.

Dass int auf verschiedenen Systemen unterschiedlich groß ist, hat ja Gründe.

C ist nicht nur für 32-Bit CPUs, bzw. CPUs deren Byte 8 Bit hat.

[KK27]

@DirkB sagte in std::intx_t vs integers:

Wählst du die Bitbreite wegen des Speicherplatzes oder wegen des Wertebereichs.

In 99% der Fälle wegen des Wertebereichs.

[DirkB]

@KK27 sagte in std::intx_t vs integers:

@DirkB sagte in std::intx_t vs integers:

Wählst du die Bitbreite wegen des Speicherplatzes oder wegen des Wertebereichs.

In 99% der Fälle wegen des Wertebereichs.

Wenn du nicht sehr große Arrays davon hast, dann überlass dem Compiler die beste Wahl.

[hustbaer]

Es kommt total drauf an was man programmiert.

Bei vielen Dingen ist es völlig ausreichend per Default 32 Bit Datentypen zu verwenden - und nur dort wo man weiss dass es u.U. nicht ausreicht/sicher nicht ausreicht grössere Typen. Und kleinere Typen nur wenn man den eingeschränkten Wertebereich braucht bzw. dieser praktisch ist.

[*john 0]

@KK27 sagte in std::intx_t vs integers:

Aber spielt das eine so große Rolle? Ist der Performance Unterschied spürbar?

Das kommt jeweils auf die Plattform an. Zum Beispiel gab und gibt es Plattformen auf denen ein Zugriff auf ein char langsamer ist als auf int. Da ist es dann sinnvoller einen größeren weil schnelleren Datentypen zu nehmen.

[SeppJ]

Aber wir hatten (hier im Forum) auch schon den Fall, wo der berüchtigte vector<bool>, der ganz extrem Speicherplatz zu ungunsten von Zugriffsgeschwindigkeit (und sinnvollem Verhalten...) optimiert, tatsächlich die schnellste Lösung war. Weil Mikrodetails, wie Cachefüllstand, eben auch eine Rolle spielen können. Aber weder die Sprache noch der Compiler können irgendwie allgemein vorhersagen, ob ein vermeintlich langsamerer, kleinerer Typ auf der tatsächlichen Hardware nicht doch deutlich schneller ist, weil auf einmal der ganze relevante Datensatz in einen schnelleren Cache passt.

[hustbaer]

Ja klar, das stimmt.

Ich meine eher dass es bei vielen Anwendungen auf Performance nicht ankommt. Bzw. dass so viel Zeit bei Dingen draufgeht auf die man keinen Einfluss hat, dass es im Endeffekt wörscht ist was man im "eigenen" Code macht.

Also beispielsweise wenn man irgendwelche Web-Requests macht, dafür fertige Frameworks verwendet, und dann ein bisschen mit den zurückgegebenen Daten rechnet. Dann ist es vermutlich egal wenn diese Berechnungen 10x langsamer sind als möglich wäre, weil trotzdem 99% der Zeit für den Web-Request draufgehen.

Aber natürlich gibt es auch die anderen Fälle, wo ein Grossteil der Zeit im eigenen Code draufgeht, und diese Zeit auch nicht irrelevant ist. Da sollte man dann mehr auf sowas achten. Und mehrere Varianten vergleichen, weil man eben nur mit viel Wissen & Erfahrung - und auch dann nur schwer/schlecht - vorhersagen kann was schneller sein wird.