Rekursive Dateisuche Stack overflow

Wenn ich es könnte, würd ich es tun

Vicious Falcon

Hast du einmal vom Debugger Gebrauch gemacht? Was aber extrem ins Auge sticht, ist, dass du <string> einbindest, von dem std::string jedoch keinen Gebrauch machst. Dinge wie

wchar_t path[41];
wchar_t path_tmp[41];

schreien geradezu nach Überlauf.
Iterativ könnte man es so lösen, dass gefundene Verzeichnisse in einen std::vectorstd::string gepackt und die gefundenen Verzeichnisse jeweils einzeln ausgewertet werden.
Gibt es eigentlich einen Grund dafür, den Quicksort selber zu implementieren? Der Algorithmus der Standardbibiothek ist viel besser getestet als alles, was man selbst schreiben könnte.

Martin Richter

Crosspost:
http://social.msdn.microsoft.com/Forums/de-DE/visualcplusde/thread/1e884300-9b76-4e2b-ad41-6b70e92d74a3

knivil

Nach meiner Denkweise wäre es doch nun für mich am einfachsten, wenn ich den Stack erhöhe

Aendere deine Denkweise!

Vicious Falcon

Ohje.

AGU_toosmall[10000],
ARE_toosmall[10000],
ARX_toosmall[10000],               
AGU[10000000],
ARE[10000000],
ARX[10000000];

Wie konnte ich das übersehen ?

@knivil: Denkweise geändert! War nur ne Idee.

@Vicious Falcon:
Für die Datenmenge brauch ich halt platz

Im Crosspost link von Martin Richter findet ihr auch die komplette Begründung.

Die Quicksort-Funktion stammt noch aus meinen Informatikunterrichtsstunden die schon was her sind
Tauschen kann ich den später immer noch ; )

knivil

Für die Datenmenge brauch ich halt platz

Das DB-Objekt wird aber auf dem Stack abgelegt. Der Heap waere die bessere Wahl.

Martin Richter

knivil schrieb:

Für die Datenmenge brauch ich halt platz

Das DB-Objekt wird aber auf dem Stack abgelegt. Der Heap waere die bessere Wahl.

Nein! Ein dynamischer Container wäre die korrekte Wahl.

Muh_Q schrieb:

Wenn ich es könnte, würd ich es tun

Alles was du rekursiv lösen kannst, kannst du auch iterativ lösen!
Und dein Programm wird immer an einem Stack Overflow sterben, wenn deine Funktion sich zu oft selbst aufruft. Der Stack ist begrenzt, selbstverständlich kannst du ihn erweitern (Zur Compiletime, wenn deine DB größer wird musst du das Programm ändern und neu kompilieren), aber wieso eine schlechte Lösung der guten vorziehen?

Lösungen wurden schon hier genannt: STL(Vector, List, Queue, Map,...)

AGU_toosmall[10000],
ARE_toosmall[10000],
ARX_toosmall[10000],               
AGU[10000000],
ARE[10000000],
ARX[10000000];

Du beliebst zu scherzen...

1. Rekusivität ist ganz böse und sollte unbedingt vermieden werden. Was da mit den CPU-Registern gemacht wird ist einfach zu redundant.

2. Der Stack eines Threads ist für gewöhnlich auf ... wie viel war das noch ... 1 MB reduziert? Und allein mit diesen Feldern hier:

GU_toosmall[10000], //40.000 Bytes ...
ARE_toosmall[10000],//... und noch einmal.
ARX_toosmall[10000],//Once again, for old times sake.
AGU[10000000],//Hier direkt 40 Millionen ...
ARE[10000000],//... und noch einmal ...
ARX[10000000];//... und noch einmal.

reservierst du Speicher in der Größe von 114 Megabytes auf dem Stack. Mein Vorschlag: verwende Zeiger, benutze Container oder noch besser, programmiere sie selbst, damit du einen Einblick in die Speicherverwaltung bekommst und lernst, genügsamer zu sein.

3. Es ist theoretisch möglich, den Stack zu erhöhen, aber das wirklich nur in Ausnahmefällen. Wenn du Visual Studio verwendest, kannst du in den Projekteinstellungen die Stapelcommit- und Stapelreservierungsgröße verändern. Aber das wirklich nur in Ausnahmefällen.