size_t zu int. Großer Datentyp vs. Cast mit check



  • Hallo zusammen,

    eine Frage an die erfahrenen C++ Entwickler.
    Wenn ich die Länge eines Vectors von dem ich weiß das er maximal sagen wir 50 Elemente beinhaltet in eine Variable speichern möchte.
    Ist es dann hinsichtlich Speicherbedarf und Performance klüger den size_t zu einem int oder short zu casten und vorher zu prüfen ob die size tatsächlich nicht zu groß ist. Oder besser einfach einen uint64_t verwenden in den der size_t auf dem Zielsystem sicher rein passt.

    Prüfen würde ich vor dem cast um eine Fehlermeldung auszugeben falls sich der Code mal ändert und der Vektor doch größer wird damit man dann den Datentyp anpassen kann.

    Zu einem int casten möchte ich da ich anschließend besser damit weiter arbeiten kann.

    Bin gespannt auf eure Meinungen



  • @cplusplus8 Wenn der Vector so groß werden kann, dass ein int nicht mehr ausreicht, ist das System so performant, dass da ein size_t nicht ins Gewicht fällt.

    Wenn du auf Systemen mit wenig Resourcen arbeitest, dann geht auch unsigned char. 😉



  • eine Frage an die erfahrenen C++ Entwickler.

    Ich antworte trotzdem mal :o)

    Ich verstehe Deine (sorry, etwas chaotisch gestellte) Frage so: Du möchtest mit der Größe eines C++ Containers etwas berechnen. Allerdings fürchtest Du Dich (zu Recht) vor std::size_t, weil unsigned. Deshalb willst Du vor der Verwendung zu einem signed Datentyp casten. Du willst jetzt wissen, ob du immer prüfen solltest, dass der Wert von Container::size() (size_t) auch wirklich in deinen signed Datentyp passt (int)?

    Hinsichtlich Performance: Vermutlich irrelevant, immer erst messen.
    Hinsichtlich Speicherbedarf: Vermutlich ebenfalls irrelevant.
    Fazit: Kannst Du ein kleines Codebeispiel bringen?

    Du kannst die Größe von Datentypen schon beim Kompilieren prüfen, z. B.:

    static_assert(sizeof(int) >= 4, "Int too small");
    

    Allgemein kann man schon cast-Funktionen schreiben, welche das gleiche machen wie static_cast, aber zusätzlich eine Exception werfen, falls es zu einem Overflow kommt. Am besten wäre es, soweit wie möglich bei std::size_t zu bleiben (oder gleich Iteratoren verwenden). Damit wird das casting-Problem verhindert.

    Ansonsten wäre es natürlich "sauber", einen sicheren Cast zu verwenden. Bei boost gibt es numeric_cast. Dann musst Du das Rad nicht neu erfinden.

    Evtl. auch relevant: Abschnitt Arithmetic, gsl::index



  • Nein, habe ich nicht so verstanden.
    Auf x86 und ähnlichen Systemen ist es grundsätzlich eher langsamer die "kleineren" Datentypen wie short zu nehmen. Es ist schneller, mit Datentypen zu arbeiten, die der Registerbreiter entsprechen.
    Der Speicherbedarf fällt meist nicht so ins Gewicht. Außer, du willst tatsächlich extrem viele dieser Werte speichern. Aber wenn es um die Größe eines vectors geht, ist es wohl eher nicht der Fall.
    Oder du brauchst relativ viele dieser Werte ziemlich oft, sodass der Cache eine Rolle spielt. Hört sich aber auch nicht danach an.



  • @cplusplus8 sagte in size_t zu int. Großer Datentyp vs. Cast mit check:

    ....
    Zu einem int casten möchte ich da ich anschließend besser damit weiter arbeiten kann.

    In den Vektoren, die ich benutze, sind selten weniger als 0 Elemente. Wäre schon komisch, wenn ich 3 Elemente einfügen müsste, damit der Vektor leer wird. Daher bin ich fast immer dafür, einen unsigned Datentypen für die Anzahl von Elementen zu benutzen.



  • Daher bin ich fast immer dafür, einen unsigned Datentypen für die Anzahl von Elementen zu benutzen.

    @DocShoe Womit wir wieder bei der alten Diskussion wären ^^


Log in to reply