maximale dynmische arraygröße?

soerenP

und auslesen tu ich so:

for(int i=1;i<width;i++)
		{
			LineTo(hdc,i ,int(height/2-m_theSamples[c][int(float(i*(m_nSamples-1))/width)]*height/2) );
		}

Vielleicht etwas umständlich geschrieben (aus verzweiflung) aber hier dürfte ich doch eigentlich keinen Fehler drin haben, oder?

CStoll

Das ständige Gecaste sieht ja grauenhaft aus - und nebenbei solltest du mal kontrollieren, welchen Index du tatsächlich verwendest. (der maximal gültige Index ist 'nSamples-1')

soerenP

ist schon geprüft:
Der Fehler tritt bei i=637 auf, width ist 952. m_nSamples liegt bei 6,6mio, das macht 4,5 mio für den Index.
Das gleiche (ca4,5mio) gilt auch für andere Dateien mit anderen Werten.
Ich kann im übrigen nicht auf über m_nSamples-1 kommen, da i<width und i/width somit <1, also (m_nSamples-1)*i/width kann nicht über m_nSamples-1 kommen.
Das gecaste hab ich aus verzweiflung gemacht, weil ich den Fehler nicht gefunden hab...
Grüße
Sören

soerenP

Haha, gar nicht:
i*(m_nSamples-1) geht an die 32 bit-Grenze, das mochte er wohl nicht so gerne und hat ne negative Zahl draus gemacht.
Danke!
Sören

Simon2

Tja, mit vector oder size_t wäre das nicht passiert..... :p
Nein stimmt natürlich nicht ...

Gruß,

Simon2.

muffmolch

nunja, wie man es nimmt... size_t ist normalerweise ja ein unsigned da sind noch ein paar stellen mehr möglich Und zudem kann er beim std::vector anstatt den index-operator zum validieren testarray.at(i) verwenden und erhält dann eine index-exception.

aber die frage ist und bleibt, ob es wirklich sinn macht dermaßen lange arrays zu verwenden...

Gruß,
SirAnn

CStoll

soerenP schrieb:

Haha, gar nicht:
i*(m_nSamples-1) geht an die 32 bit-Grenze, das mochte er wohl nicht so gerne und hat ne negative Zahl draus gemacht.

Bei solche Problemen hilft es oft nur noch, auf größere Datentypen auszuweichen (wenn du statt des Produkts nur das i in float umgewandelt hättest, wäre das vielleicht etwas geworden) oder die Reihenfolge der Berechnungen umzustellen ('i*((nSamples-1)/width)' produziert z.B. keinen Überlauf).

soerenP

muffmolch schrieb:

aber die frage ist und bleibt, ob es wirklich sinn macht dermaßen lange arrays zu verwenden...

Was genau meinst du?
Ob es Sinn macht, die Daten auf einmal im Arbeitsspeichr zu haben, oder ein Array mit new[] zu nehmen anstatt nen Vector?

Naja, wenn man keinen Casting-Quatsch betreibt gibts doch erstmal keine Probleme. Und auch keinen Daniel Küblböck, verzeiht mir das Wortspiel;-)
Ich danke euch allen nochmal
Sören

muffmolch

soerenP schrieb:

Was genau meinst du?
Ob es Sinn macht, die Daten auf einmal im Arbeitsspeichr zu haben, oder ein Array mit new[] zu nehmen anstatt nen Vector?

wenn soweit alles läuft, dann ist ja alles in grünen bereich.
und wenn du die daten benötigst, dann sollten sie sich wenn möglich auch alle im arbeitsspeicher befinden. dennoch macht es hin und wieder sinn, daten zu unterteilen. was ist, wenn deine daten vom theoretischen verfügbaren speicher in den RAM passen, aber dieser dermaßen defragmentiert ist, dass dies nicht "an einem Stück" (was array/std::vectoren nunmal sind) geschehen kann???

ist eben eine design frage.

thordk

wenn du nen array mit 2^32 floats anlegst, belegt der 1 gig ram. das wird auf vielen rechnern wohl gut gehen, aber spätestens, wenn du mit den daten ein wenig rumjonglierst und sich das volumen verdoppelt, fliegt dir ne windows anwendung um die ohren, egal wieviel ram drinsteckt. bei großen datenmengen sollte man paketeweise arbeiten. ist meist überhaupt kein problem, wenn man sich eine maximale paketgröße von ein paar tausend (großzügig denken) objekten definiert. damit wird man meistens den kontext auch noch hinbekommen, die anwendung bleibt schnell und kommt mit drastisch weniger speicher aus. eine million floats sind wesentlich handlicher als 4.5 milliarden

soerenP

Ich möchte mal klarstellen, dass ich nicht mit 2^32 floats gearbeitet habe, sondern mit 4,5 Millionen, da liegt ein faktor 1000 zwischen,wenn ich mich recht entsinne.
Also, angenommen, ich komme nie über ca. 150MB (eigentlich sogar meistens wesentlich weniger), dann beweg ich mich doch auf der sicheren Seite, oder?
Danke nochmal
Sören

muffmolch

soerenP schrieb:

Ich möchte mal klarstellen, dass ich nicht mit 2^32 floats gearbeitet habe, sondern mit 4,5 Millionen, da liegt ein faktor 1000 zwischen,wenn ich mich recht entsinne.
Also, angenommen, ich komme nie über ca. 150MB (eigentlich sogar meistens wesentlich weniger), dann beweg ich mich doch auf der sicheren Seite, oder?
Danke nochmal
Sören

150MB stellen für heutige rechner i.d.R. natürlich kein Problem dar.
Auf nem PPC wird es da natürlich eng