maximale dynmische arraygröße?
-
es ist ein mit new erstelltes Array. Um genau zu sein sogar zweidimensional, wegen mehreren Kanälen (in diesem Fall aber einkanalig...), aber das spielt wohl (hoffentlich) keine Rolle.
Grüße
Sören
-
Zeig doch mal den Code, wie das Array erzeugt wurde (btw, gab es schon beim Füllen des Arrays Speicher-Probleme?).
-
wieso verwendest du keinen std::vector?
da kannst du mit max_size() die max Größe ermitteln, die der Vektor auf dem aktuellen System haben darf
-
beim Füllen des Speichers gabs komischerweise keine Probleme.
Quellcode folgt...
-
So:
void CWaveFile::convertBufferToSamples() { m_theSamples=new float*[channels]; m_nSamples=data_size/(channels*bits_per_sample/8); int bytespersample=bits_per_sample/8; for(int c=0;c<channels;c++) { m_theSamples[c]=new float[m_nSamples]; } int pointer=0;//durchläuft den soundBuffer (Rohdaten aus File) for(int i=0;i<m_nSamples;i++) { for( c=0;c<channels;c++) { int theValue=0; for(int b=0;b<bytespersample;b++) { theValue+= m_soundBuffer[pointer++]*(int)pow(256,b); //Interpretation der Rohdaten } if(theValue>pow(2,bits_per_sample-1)) theValue-=(int)pow(2,bits_per_sample); m_theSamples[c][i]= (float)theValue/(float)pow(2,bits_per_sample-1); } } loaded=true; }Eigentlich sollte alles funzen, bei kleineren Dateien ist ja auch alles Ok.
-
Hat ein Vector sonst keine Nachteile?
Hab das noch nicht in betracht gezogen...
Da ich aber den Speicher allokieren durfte, scheint meine Datei wohl nicht definitiv zu groß zu sein, oder?
Grüße
Sören
-
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?
-
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')
-
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
-
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
-
Tja, mit vector oder size_t wäre das nicht passiert..... :p
Nein stimmt natürlich nicht ...
Gruß,
Simon2.
-
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
-
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).
-
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
-
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.
-
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

-
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
-
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ören150MB stellen für heutige rechner i.d.R. natürlich kein Problem dar.
Auf nem PPC wird es da natürlich eng