Ich habe einen 32-bit PC das bedeutet ja dass ich mit size_t dann insgesamt eine liste mit 2^32 Elementen speichern kann, gut das reicht zum
streamen sogar alle male aus
.
Nein, das ist eigentlich immernoch falsch.
a) Was nimmst Du zur Adressierung eines einzelnen Elements? Ein size_t ist auf 32Bit-Maschinen ein unsigned int, hat also einen Wertebereich von 0 bis 2^32-1. Wenn Dir das reicht, ist alles gut.
b) Die maximale Größe eines std::vector. Du hast ein 32Bit-Betriebssystem, also kann der größte zusammenhängende Speicherblock nur 2^32 Byte lang sein, also 4 GB. Und das ist die Grenze, die Dir std::vector::max_capacity() zurückgibt : 4 GB geteilt durch die Größe des gespeicherten Elements.
c) Du wirst in der Praxis schon weit vorher scheitern - auf Windows 32Bit hast Du z.B. nur 2GB an Adressraum für Deine Anwendung, außer Du aktivierst in den VisualStudio-Projekteinstellungen "Große Adressen aktivieren" und Du konfigurierst Dein Windows, so dass es mehr als 2GB für Anwendungen gibt. Unter 64Bit-Betriebssystemen reicht nur der ProjektKonfig-Flag, und eine 32Bit-Anwendung hat volle 4 GB.
c2) Du wirst in der Praxis auch dann noch weit vorher scheitern, weil für einen std::vector der Speicher als ein kontinuierlich zusammenhängender Block zur Verfügung stehen muss. Wenn Du vorher schon ein paar Allokationen gemacht hast, reduziert sich diese Maximalgröße eines zusammenhängenden Blocks schnell.
d) Wenn Du streamst, ist wieder alles gut. Dann kannst Du auch einfach einen uint64_t (aus stdint.h) als Index nehmen und _fseeki64() und Artverwandte zum Spulen in Dateien, und die Maximalgröße Deiner Daten liegt weit jenseits des Nirvanas. Dann kann Dir aber noch das Dateisystem Ärger machen: FAT32 (wird manchmal noch auf USB-Sticks verwendet) kann nur Dateien mit bis zu 4GB Größe anlegen.
So, genug im Trüben gefischt. Du wirst ja merken, wo es hängt, wenn Du mal mit solchen Dateigrößen arbeitest.