Klotzkopp

http://support.microsoft.com/kb/311259 Du mischst die Klassen der C++-Standardbibliothek mit den .NET-Klassen. Die können nicht miteinander. Mach dir klar, was der Unterschied zwischen System::String und std::string ist. Nochmal mein Rat: Benutz C#, oder benutz zumindest konsequent die .NET-Klassen. Mit diesem Mischmasch begibst du dich auf einen sehr steinigen Pfad.

Hab ich doch geschrieben :confused:

OpenFileDialog1->FileName Ich habe deinen Thread ins .NET-Forum verschoben, weil das kein C++ ist, sondern C++/CLI. Das ist trotz des ähnlichen Namens eine andere Sprache. Und ein ernst gemeinter Rat: Wenn du GUI mit Windows Forms machen willst, nimm besser C#. Siehe auch: Jochen Kalmbach Statt dich zu entschuldigen, kannst du sie auch einfach noch einfügen. Du kannst deine Beiträge 15 Minuten lang editieren.

Also ist die Information, dass das in eine Tabelle soll, irrelevant. Du machst vor der Array-Ausgabelogik die Zelle auf, und danach wieder zu. Dazwischen (im interessanten Teil) passiert nichts, dass sich auf die Tabelle beziehen würde. Bitte beantworte doch die Frage: In welcher Reihenfolge sollen die Array-Elemente ausgegeben werden? In deinem Beispielcode (wo allerdings array3 und nicht array ausgegeben wird) gibst du das erste Element als Überschrift aus, und dann jeweils zwei Elemente nebeneinander. Ist das so gewünscht? Wenn man das fortsetzt, kommt man aber immer auf eine ungerade Anzahl, nicht auf 10.

Überleg mal, in welcher Reihenfolge du die Array-Elemente ausgeben musst.

Wo ist denn CloseHandle geblieben? Nebenbei: vector::at brauchst du nur, wenn du willst, dass eine Bereichsprüfung auf dem Index stattfindet. Du kannst einfach [] benutzen, wie du es beim Zugriff auf m_hThread getan hast.

Das ist aber nicht sicher. Erstens musst du immer daran denken, wenn du irgendwo ein vorzeitiges return einbaust, und zweitens funktioniert das nicht, sobald irgendwo dazwischen eine Exception fliegt. Solides C++ sieht anders aus. Genau. Es sollte schon ein Array von CWinThread* sein.

Ressourcenbelegung ist Initialisierung In C++ haben Variablen eine klar definierte Lebensdauer. Wenn der Gültigkeitsbereich einer Variable endet, wird sie zerstört. Bei Klassen bedeutet das, dass der Destruktor aufgerufen wird. Das passiert übrigens auch dann, wenn eine Ausnahme geworfen wird, die den Gültigkeitsbereich der Variablen verlässt. Wenn man nun solche Ressourcen wie Handles, die man explizit wieder freigeben muss, an eine Klasse koppelt, die genau das Freigeben im Destruktor übernimmt, kann man das Freigeben nicht mehr vergessen. Das Handle wird automatisch freigegeben, sobald das Objekt, das es kapselt, seinen Gültigkeitsbereich verlässt. Man kann also problemlos vorzeitig aus Funktionen herausspringen oder Ausnahmen werfen, und muss sich nicht mehr darum sorgen, ob alle angeforderten Ressourcen ordentlich freigegeben werden, weil das ganz automatisch passiert. Auf diesem Prinzip beruhen in C++ die Smartpointer. Das ist auch der Grund, warum man fstream::close normalerweise nicht braucht. Grundsätzlich wäre hier ein std::vector<HANDLE> besser als ein rohes Array, denn dann kannst du das delete[] weglassen und somit nicht mehr vergessen. Um das CloseHandle auch noch zu kapseln, musst du etwas tiefer in die Trickkiste greifen: Wenn du Visual C++ 2010 hast (da wird schon ein Teil des neuen Standards unterstützt), könntest du statt einem rohen HANDLE-Array einen std::vector<std::shared_ptr<HANDLE>> benutzen. Allerdings kannst du da nicht direkt die HANDLEs so "am Stück" rausholen, wie du es für WaitForMultipleObjects brauchst. Eine andere Möglichkeit wäre der ptr_vector von boost.

Du siehst da einen Unterschied, wo keiner ist. Letztendlich rechnest du auch im zweiten Fall x3=x1+x2 und y3=y1+y2. Jede Rechenoperation auf Vektoren wird auf Operationen auf die skalaren Komponenten zurückgeführt, und das zeigt sich zwangsläufig in der Implementierung.

Das sieht schon gar nicht schlecht aus. Allerdings schließt du so nur das Handle des ersten Threads. Und wenn du new[] benutzt, musst du auch delete[] benutzen. Eine Klasse, die das ausnahmesicher mit RAII kapselt, wäre natürlich noch besser.

Ok, jetzt habe ich es verstanden. Ich könnte mir allerdings vorstellen, dass die Compiler Schwierigkeiten haben, das zu erkennen.

Da du die Werte in der Matrix änderst, und jeder Wert Berechnungsgrundlage für die benachbarten Werte ist, hast du eine Abhängigkeit. Mal ganz konkret: Im ersten Schleifendurchlauf änderst du a[1][1]. Im zweiten änderst du a[2][1], wobei a[1][1] Eingabewert ist. Im nächsten änderst du a[1][2], wieder ist a[1][1] Eingabewert für die Berechnung. Deine Berechnungen bauen aufeinander auf.

Meiner Meinung nach ist dadurch, dass du an a[j] zuweist, das Ergebnis deines Programms davon abhängig, in welcher Reihenfolge die Durchläufe der inneren Schleife passieren, denn damit änderst du die Eingabewerte für andere Durchläufe.

Das ist eine unsinnige Begründung. Mit dem roten in erreichst du nur, dass dein Programm zwar übersetzt werden kann, aber trotzdem nicht funktioniert. - Das rote "in" muss weg. - Das blaue "in" muss in der Schleife bleiben. - Du brauchst die Statusinformation des blauen "in" in der Schleifenbedingung. Lösung: Leg außerhalb der Schleife eine bool-Variable an, die den Rückgabewert von in.good() in der Schleife speichert. Diese Variable kannst du dann für die Schleifenbedingung nutzen. Warum überhaupt der Cast auf int? Angst vor bool?

Geht es immer noch um "Textdatei in Array schreiben"? Falls nicht, mach bitte einen neuen Thread dafür auf. Ein Thema - ein Thread. Zeig bitte mal das ganze Programm, eigentlich sollte sich das nicht übersetzen lassen, es sei denn, es gibt da noch eine andere Variable namens in. Du kannst in der Schleifenbedingung einer do/while-Schleife nicht auf eine Variable zugreifen, die innerhalb des Schleifenblocks definiert ist. Und benutz bitte Code-Tags, damit die Einrückung erhalten bleibt. Und misch nicht printf/scanf und cin/cout, die müssen nicht gegeneinander synchronisiert sein.

Das sollte wohl feld+i heißen. Falsch abgeschrieben? Und fürs nächte Mal: Lass dir bitte einen aussagekräftigen Threadtitel einfallen. Ratlos ist hier so ziemlich jeder, der hier eine Frage stellt, sonst würde er ja nicht fragen.

Wenn l gleich 1 ist, steht da 1>(1-20) also 1>-19 Ist immer noch true. Eine Zahl ist immer größer als dieselbe Zahl um 20 verringert. Das wird erst dann false, wenn du die Grenze des Wertebereichs erreichst, bei einem 32-Bit-int also jenseits der -2 Milliarden. Du musst in der Schleifenbedingung einfach dafür sorgen, dass l nicht ungültig werden kann. Und bedenke, dass ein Dateiname keinen Punkt enthalten muss.

Für welchen Wert von l soll dieser Ausdruck denn jemals false ergeben? Die Schleifenbedingung while(pointpos<lenght)ist auch nicht gut, wenn man bedenkt, dass sich in der Schleife weder pointpos noch lenght ändert. Damit bleibt auch der Wert dieses Ausdrucks immer gleich. Schöne Endlosschleife. Ja, da liegst du falsch. Konsolenausgaben können gepuffert werden. Du könntest fflush(stdout) benutzen, um das Schreiben zu erzwingen. Noch besser wäre natürlich die Verwendung eines Debuggers.

Deine Schleifenvariable l in split läuft von -1 rückwärts. Wenn l kleiner als 0 ist, ist ein Zugriff auf a[l] undefiniert. Die Schleifenbedingung ist auch kaputt. l>l-20 wird erst dann false, nachdem l den kleinstmöglichen Wert für int erreicht hat.

Keine Ahnung. Du hast immer noch nicht gesagt, wozu du die zweite Map brauchst. Wenn da dasselbe drinstehen soll wie in der ersten, ist sie überflüssig. Wenn die Templateparameter gleich sind, kannst du einfach zuweisen.

Weil du in einer string-Map nach einem int suchst. std::map::find sucht nach Schlüsseln, nicht nach Werten. Was soll dieser Code überhaupt bezwecken, wofür brauchst du die zweite Map?

Du brauchst insert hier gar nicht. StrMap[line] sorgt schon dafür, dass ein Eintrag für diesen Schlüssel angelegt und der Wert mit 0 initialisiert wird, falls es noch keinen gibt. Deine increment-Funktion finde ich übrigens ziemlich merkwürdig, die macht den Code nur länger. ++StrMap[line];tut's auch.

Eben das CWD, also das aktuelle Arbeitsverzeichnis. Das ist das Verzeichnis, auf das sich relative Pfadangaben beziehen. Das ist eine veränderliche (daher das C in CWD) Eigenschaft eines Prozesses, die nichts damit zu hat, wo die ausführbare Datei steht. Wenn ein Programm aus dem enthaltenden Verzeichnis heraus gestartet wird, ist das CWD zu Anfang das Verzeichnis, in dem die ausführbare Datei steht. Aber erstens muss das nicht so sein, und zweitens kann sich das CWD ändern, während das Programm läuft. Bei Windows-Verknüpfungen kann man das anfängliche Arbeitsverzeichnis festlegen.

Das Arbeitsverzeichnis ist nicht das Verzeichnis, in dem die ausführbare Datei liegt. Unter Windows benutzt man GetModuleFileName. Wofür brauchst du den Pfad denn? Spätestens ab Vista hast du in dem Verzeichnis sowieso nichts zu suchen.