pointCloud::pointCloud(double long x, double y, double z)
{	
	for(double i=0; i<x; i++)
		for(double j=0; j<y; j++)
			for(double k=0; k<z; k++)
			{
				pointCloud::point3d p(i, j, k);
				pCloud.push_back(p);
			}		
}

Problem gelöst !

Darf man erfahren, was es war?

anscheinend gibt es leute die nichts besseres zu tun haben als sich hier als jmd anderes auszugeben. habe mich jetzt aber registriert.

ich denke mal du hast recht. so wie ich das gemacht habe ist das einfach zu groß. ich habe die laufvar als double deklariert weil ich die in point3d als double benötige...kann man natürlich auch casten.

hab mir jetzt ein bool'sches 3d array erstellt, das geht auch...

ich denke mal du hast recht. so wie ich das gemacht habe ist das einfach zu groß. ich habe die laufvar als double deklariert weil ich die in point3d als double benötige...kann man natürlich auch casten.

Ganzzahlen und Fließkommazahlen sind implizit ineinander überführbar. Keine Notwendigkeit, zu casten.

hab mir jetzt ein bool'sches 3d array erstellt, das geht auch...

Wobei dir hoffentlich klar ist, dass bool mehr als 1 Bit Speicher benötigt. Wie kann das überhaupt sein, dass du double durch bool ersetzen kannst?

Meiner Meinung nach solltest du dich aber vielleicht eher fragen, ob du die Werte überhaupt alle benötigst. Welche Anwendung die auf einem Rechner mit so wenig Speicher läuft, braucht denn 125 Millionen Koordinaten? Ich vermute mal, dass ist ein Heimrechner? Bis du da irgendwas mit dieser Größenordnung von Werten ausgerechnet hast, dauert das doch Jahre!

Angenommen der Vektor hat bereits 2GB (also ca. 83 Millionen point3d-Objekte) und seine Kapazität ist nun erschöpft.
Nun wird versucht neuen Speicherplatz zu allozieren, sagen wir mal 3GB -> +50%).

Gesamtspeicherbedarf in dem Moment: 5GB - auf Systemen mit nur 4GB Ram doof.

Also lieber vorher schon sagen: Mein Vekor soll 125Mio point3d-Objekte aufnehmen.

Riesige zusammenhängende Speicherbereiche zu finden kann schwierig werden. Vielleicht ist man mit einem Container wie std::deque besser beraten.

Das muss man Fall zu Fall prüfen. Der Overhead bei std::deque ist riesig, zumindest in der STLport und Dinkumware Implementation. Dort hängt die Blockgröße von der Größe des zu speichernden Typs ab und ist oft nur 2, 4 oder 8 Elemente groß, bei einem Overhead von 12 Byte je Block zur Verwaltung.
Ich hatte ein ähnliches Problem und habe eine abgespeckte deque programmiert mit eine über ein Template Parameter einstellbare Blockgröße, weil die std::queue zwar keinen zusammenhängenden Speicher braucht, aber durch die Verwaltungsinformation um den Faktor drei mehr Speicher brauchte als std::vector.