spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Inwiefern "besser"? Im Allgemeinen kann man das nicht so sagen...

Es ist insofern besser geeignet, als das es genau so groß ist wie Pointer und somit alle möglichen Indices repräsentiert werden können.
Wie man auch auf Wikipedia nachlesen kann, ist die Breite von "Int" mehr oder weniger fast willkürlich. Mit "std::size_t" ist man auf der sicheren Seite. Der Datentyp skaliert mit der Architekturbreite mit. Array-Indices sind nunmal in der Praxis eigentlich genau genommen immer so Breit wie "std::size_t", alles andere muss (meist implizit) gecastet werden.
Zum Beispiel bei

sollte der Compiler in vielen Fällen eine Warnung ausstoßen.

Solche Ärgernisse wie bei zlib, dass die maximale Datenmenge vom Compiler abhängt, gibt es dann auch nicht.

Zitat

als das es genau so groß ist wie Pointer

Das ist ein häufiges Missverständnis – uintptr_t ist genau so groß wie die größten Zeiger. size_t hingegen könnte z.B. auf 64-Bit Win32 immernoch nur 32 Bits groß sein, obwohl alle Zeiger 64 Bits groß sind – weil keine Datentypen oder Arrays größer 2 GiB erlaubt sind und man ergo nur 31 Bits für jede mögliche Größenangabe benötigt. Das schränkt natürlich nicht die Nutzbarkeit als Index ein; aber verbietet das Casten zwischen Zeigern und size_t.

Für Schleifen sollte man aber in den meisten Fällen sowieso keine Laufvariablen benutzen sondern Iteratoren.

Wenn man es doch tun muss, siehe dot: Es kommt auf den Fall an. int kann bspw. in wenigen Fällen bessere Optimierungen erlauben; in anderen Fällen das Programm komplett zerstören.

Zitat von »Krishty«

size_t hingegen könnte z.B. auf 64-Bit Win32 immernoch nur 32 Bits groß sein, obwohl alle Zeiger 64 Bits groß sind – weil keine Datentypen oder Arrays größer 2 GiB erlaubt sind und man ergo nur 31 Bits für jede mögliche Größenangabe benötigt.

Ich gehe davon aus, du meinst dies als hypothetisches Beispiel!? Oder meinst du tatsächlich, dass man unter 64-Bit Windows keine Arrays über 2GiB haben kann?

auto foo = new int[3ull * 1024 * 1024 * 1024];
error C2148: total size of array must not exceed 0x7fffffff bytes

Wenn du dich selber um die Speicherverwaltung kümmerst (VirtualAlloc() & Co.), bekommst du es natürlich hin – aber Visual C++’ CRT gibt knapp unter 2 GiB auf. Nichts würde den Compiler also davon abhalten, size_t 32-bittig zu halten, denn in der C++-Welt kommt der Speicher ja nur via new :-)

(Da liegt auch mein Fehler – ich hatte in Erinnerung, auch in meinen 64-Bit-Programmen keinen zusammenhängenden Block von über 2 GiB kriegen zu können, wenn ich direkt über die WinAPI gehe. Scheint aber zu funktionieren; keine Ahnung, was ich da verbockt hatte. Also Visual C++ kann nicht mehr, nicht Win32)

Es bleibt aber dabei, dass Addressraumgröße und Objektgröße unterschiedliche Konzepte sind, die durch unterschiedliche Typen (uintptr_t vs. size_t) abgebildet werden und nicht durcheinandergeschmissen werden dürfen.

Oha, tatsächlich, das war mir neu...

Edit: Hier findet sich eine Begründung die Sinn macht...

Ja; klingt sinnvoll. Ich kann mir außerdem vorstellen, dass es die Erkennung von Integer-Überläufen bei Allokationen erleichtert (für Microsoft war ein gefürchteter Angriffsvektor, eine Anwendung so viele Elemente allokieren zu lassen, dass n * sizeof(Element) überläuft, die Anwendung zu wenig Speicher reserviert, und dann in den Heap dahinter schreibt).

Ja, unabhängig von irgendwelchen Implementierungen sagt dir die Deklaration schon dass du in dieser Variable keine "normalen" Zahlen speichern willst, sondern eben Array-Größen oder so.