Dynamisches 2D-Array (auf Heap)
-
hustbaer schrieb:
Wo schreib' ich denn was von Arrays?
Und ein std::vector legt seine Daten immer mit "new" an, auch wenn du den std::vector "auf dem Stack" anlegst.Ich dachte, STL-Container benutzen Allokatoren, die rein gar nichts mit
newzu tun haben?
-
[quote="unskilled"]
Mandel schrieb:
Hm... Das ist dann ja aber auf dem Stack und nicht auf dem Heap, wenn ich das richtig sehe, oder?
Das siehst du ganz richtig. Warum muss der vector denn unbedingt auf dem Heap liegen?
-
[quote="daddy_felix"]
unskilled schrieb:
Mandel schrieb:
Hm... Das ist dann ja aber auf dem Stack und nicht auf dem Heap, wenn ich das richtig sehe, oder?
Das siehst du ganz richtig. Warum muss der vector denn unbedingt auf dem Heap liegen?
Es ist doch offensichtlich, welche Befürchtungen hinter der Frage stecken. Nämlich, dass die Daten ebenfalls auf dem Stack liegen. Das ist aber natürlich nicht der Fall.
Statt den OP so dummdreist in die Verwirrung rennen zu lassen mit Deiner Gegenfrage, hättest Du auch direkt sinnvoll antworten können.
-
Hacker schrieb:
hustbaer schrieb:
Wo schreib' ich denn was von Arrays?
Und ein std::vector legt seine Daten immer mit "new" an, auch wenn du den std::vector "auf dem Stack" anlegst.Ich dachte, STL-Container benutzen Allokatoren, die rein gar nichts mit
newzu tun haben?Aber der Standardallokator nutzt new!*
*: Naja genau genommen drückt sich der Standard etwas komplizierter aus, aber das ist, was man am Ende aus den 5 verschiedenen, relevanten Textstellen mitnehmen kann.
-
Hallo,
ich hänge mich mal an das Thema ran, da es sehr ähnlich mit meinem Problem ist.
Ich erstelle auch ein 2D-Array mittels Vekroren. In einer Schleife wird ein Teil einer sehr großen Textdatei (1,2gb) ausgelsen und verarbeitet. Die verarbeiteten Daten in eine andere Datei geschrieben. Dann wird der Vektor mittels der clean()-Funktion gelöscht und neue Inhalte in das Feld gespeichert.
Das Programm läuft bei kleineren Datenmengen ohne Fehler. Bei den großen Daten bricht das Programm ab und gibt mir folgendes aus:
Unbehandelte Ausnahme: System.Runtime.InteropServices.SEHException: Eine externe
Komponente hat eine Ausnahme ausgelöst.
bei std._Xout_of_range(SByte* )
bei std.basic_string<char,std::char_traits<char>,std::allocator<char> >.inser
t(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , UInt64 _O
ff, basic_string<char\,std::char_traits<char>\,std::allocator<char> >* _Right, U
Int64 _Roff, UInt64 _Count)
bei zerlegendatum(basic_string<char\,std::char_traits<char>\,std::allocator<c
har> >* s1, vector<double\,std::allocator<double> >* vrow)
bei main(Int32 argc, SByte** argv)
bei mainCRTStartup()Was bedeutet das für mich? Wie komme ich auf eine Lösung?
Bin kein Informatiker, sondern erlerne das Programmieren um einfache aufgaben effektiver zu erledigen.
Danke
-
derbernd schrieb:
Bin kein Informatiker, sondern erlerne das Programmieren um einfache aufgaben effektiver zu erledigen.
Und wie kommst du dann auf C++??? Für so etwas eignet sich Python ganz gut.
-
Für mich klingt das, als würde dir der Speicher ausgehen. Oder jedenfalls genügend große Blöcke an einem Stück. Datei von 1.2 GB ist auch schon verdächtig nahe an dem was ein 32 Bit-Programm in 32-Bit Windows nutzen kann. Wenn da gegen Ende des Lesens eine Reallocation mit kompletter Deep Copy fällig wird, kommt man auch leicht über das Maximum.
Wenn die Datenmengen so groß werden, sollte man sich auch mal fragen:
a) Ob man die überhaupt alle gleichzeitig im Speicher braucht. Das ist erfahrungsgemäß nie der Fall bei Leuten, die hier solche Fragen stellen.
b) Ob die gewählte Datenstruktur tatsächlich optimal ist.
c) Falls die Datenstruktur zwar optimal wäre, man aber an technische Grenzen (32 Bit) stößt, ob nicht auch ein Kompromiss reicht. Z.B. eine Struktur, die nicht alle Daten in einem zusammenhängenden Block hält.
d) Falls c ein Problem ist, ob man nicht ein System mit weniger Einschränkungen nutzen kann. Z.B. Linux oder allgemein 64-Bit Systeme und/oder 64-Bit Programme.
-
Also ich brauch die Daten nicht alle im Speicher. Deswegen lese ich immer eine gewisse Anzahl an Zeilen ein und speichere diese in einem Vektor. Danach verarbeite ich den Vektor, leere ihn über vector.clear() und lese neue daten ein. Das ganze wiederhole ich bis zum Dateiende.
PS: Ich lerne c++ da mich das interessiert und ich stück für stück mehr lernen möchte.
-
derbernd schrieb:
PS: Ich lerne c++ da mich das interessiert und ich stück für stück mehr lernen möchte.
Du weißt, dass es Jahre dauert, C++ zu lernen?
-
ja, ich möchte ja auch keine "große" Programme schreiben, sondern meist sehr "aufwändige Skripte". Das heißt gewissen Tools die mir Daten verarbeiten und gegebenenfalls ausgeben. Konnte zB ein Excel-Macro in c/c++ umsetzen und die Rechenzeit von 20min auf 1min verkürzen.
Aber hier geht es ja nicht darum ob ich c++ lernen sollte oder nicht, sondern um das oben beschriebene Problem
Versuche gerade noch den Fehler mit try und catch abzufangen. Jedoch funktioniert catch(std::bad_alloc&) nicht.
-
Was möchtest du da auch groß abfangen? Auf bad_alloc kann man kaum mehr sinnvoll reagieren. Und sie tritt gewöhnlicherweise dann und genau dann auf, wenn ein zu großer Speicherblock angefordert wurde. Und zwar hier für einen String ind zerlegendatum. Das ist sicherlich ein Fehler im Programm, entweder konzeptionell (dein Algorithmus braucht einfach zu viel Speicher) oder ein Programmierfehler (du benutzt versehentlich mehr Speicher als geplant). Das sollte man nicht zur Laufzeit behandeln*. Also musst du da entweder mal selber mit dem Debugger ran oder du tust weniger geheimnisvoll und zeigst uns Code, anstatt uns zu erzählen, dass du ein Programm hast, das eine bad_alloc schmeißt.
edit: Moment, du hast ja gar keine bad_alloc, sondern eine System.Runtime.InteropServices.SEHException! Machst du überhaupt C++? Das klingt nach C++/CLI, eventuell auch C#.
*: Für den Fall, dass das Programm an sich läuft, aber eventuell zu viele Daten durch eine Nutzereingabe bekommt, kann man natürlich abfangen. Aber das Debuggen mit Exceptions ist keine tolle Idee.
-
Es ist wohl C++/CLI. Fck you M$.
