Klotzkopp

Ja, gibt es. Der jeweils zweite Code definiert eine Referenz (falls er nicht gerade in einer Klassendeklaration steht). Und da Referenzen bei der Definition initialisiert werden müssen, sind beide kein gültiger C++-Code. Der erste Code definiert eine Instanz des Typs MyClass namens mc. Der zweite Code deklariert eine Funktion namens mc, die eine Instanz von MyClass zurückgibt. Das geht nicht. getIt liefert eine temporäre Kopie. Wenn du die nicht benutzt, wird sie gleich wieder zerstört. Keinesfalls darfst du daher ihre Adresse aufnehmen. Delete darfst du da sowieso nicht machen. Du hast ja auch kein new gemacht. Es wird überschrieben. Was genau passiert, hängt vom Inhalt des Zuweisungsoperators ab. Die Lebenszeit eines Objekts kannst du nicht beeinflussen, indem du irgendwelche Pointer darauf zeigen lässt. In deinem Beispiel kommst du nicht um new herum. Ja, gibt es. Such mal nach dynamic_cast. Du solltest das aber nicht allzu oft benutzen. Meistens gibt es da besser Lösungen, und exzessiver Gebrauch von dynamic_cast ist oft ein Indiz für ein Designproblem.

Du solltest den Zufallszahlengenerator nur einmal initialisieren, vor der Schleife.

Code zeigen, was sonst? Vermutlich fehlt ein Semikolon oder so was.

Du könntest auch einfach in deine Dokumentation schauen. Da steht, welche Header die verwendeten Funktionen benötigen. Ein #include <string.h> könnte schon mal weiterhelfen. Du solltest keine Präprozessorsymbole definieren, die mit einem Unterstrich anfangen. Das ist dem Compiler vorbehalten.

Ich weiß beim besten Willen nicht, wie du von Batchdatei auf C++ kommst. Ab in die Windowsecke...

Aber die Bedingung ist dann immer noch falsch. iS1 ist immer ungleich 1 oder ungleich 0. Oder kannst du mir einen Wert nennen, der beides nicht ist? Die Negation von iS1 == 1 || iS1 == 0 ist iS1 != 1 && iS1 != 0 Für die Zukunft: Bitte erstelle einen neuen Thread, wenn du eine Frage zu einem anderen Thema hast. Und bitte verwende Code-Tags, damit die Einrückung erhalten bleibt.

Du verwechselst definitiv Dimension mit Spalte. Deine Tabelle hat zwei Dimensionen (Datensatz und Feld), aber sie hat auch zwei Spalten (Tag und Artikel). Was du hier Dimensionen nennst, sind einfach die Spalten. Der Algorithmus, den du suchst, sieht einfach so aus, dass du nach dem Tag sortierst, und falls der bei zwei zu vergleichenden Datensätzen gleich ist - und nur dann - nach Artikel sortierst.

Vielleicht solltest du doubles nicht mit %d ausgeben.

SHGetSpecialFolderLocation( NULL, CSIDL_DRIVES,&lpList); Bringt aber nichts, denn aus der Beschreibung von SHGetPathFromIDList: Und der Arbeitsplatz ist nicht Teil des Dateisystems. Ich bin mir nicht sicher, aber ich glaube, die sind fest. Hier stehen sie. Lobenswert

Ich dachte, das Problem wäre gelöst... :confused:

Der Arbeitsplatz ist eine so genannte Namespace Extension. Das sind -ganz grob gesagt- virtuelle Ordner. Man kann diese Ordner auch über ihre Class ID ansprechen. Und diese ID ist die des Ordners Arbeitsplatz. Andere sind z.B.: Netzwerkumgebung: {208D2C60-3AEA-1069-A2D7-08002B30309D} Systemsteuerung: {21EC2020-3AEA-1069-A2DD-08002B30309D} Internet Explorer: {871C5380-42A0-1069-A2EA-08002B30309D}

Eigentlich würde es hier bedeuten, dass die Zahlen abwechselnd größer und wieder kleiner werden. Möglicherweise mein Perpetuum mit "alternierend" aber auch nur weder aufsteigend noch absteigend. Eine Klärung wäre hilfreich...

@merlinthemagican: Beim nächsten mal bitte: - Aussagekräftigen Betreff wählen ("Hilfe" sucht hier so ziemlich jeder) - Vollständige Fehlermeldung posten - Zeile, in der der Fehler auftritt, kenntlich machen - Code-Tags benutzen

@studentenkopp, bist du sicher, dass du nicht Dimension mit Spalte verwechselst?

Versuch mal "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}".

Nur als Anmerkung: fflush(stdin) erzeugt laut Standard undefiniertes Verhalten. Viele Compiler leeren dabei den Tastaturpuffer, aber darauf kann man sich nicht verlassen. Wer Wert auf Portierbarkeit legt, sollte das nicht verwenden. Ich kenne allerdings keinen (nichtblockierenden) Weg, unter C den Puffer zu leeren. Wie es unter C++ geht, steht hier.

So baut man Programme nunmal nicht auf. Der übliche Weg sieht so aus, dass du mehrere Übersetzungeinheiten hast (Übersetzungeinheit = .cpp-Datei). Die werden getrennt kompiliert und dann vom Linker miteinander verknüpft. Wenn du eine .cpp-Datei über eine #include-Direktive einer anderen hinzufügst, verbindest du sie zu einer einzigen ÜE. Das hat zur Folge, dass du die eingefügte Datei nicht dem Projekt/makefile hinzufügen kannst (d.h. sie wird nicht selbst kompiliert), weil sich sonst der Linker beschwert. Das mag bei kleinen Programmen noch funktionieren, aber du musst dabei extrem darauf achten, dass die Reihenfolge der #include-Direktiven passt und keine doppelte #includes auftreten. Spätestens, wenn du die eingebundene .cpp-Datei in mehr als einer anderen .cpp-Datei brauchst, geht das schon nicht mehr. Wenn du damit anfängst, .cpp-Dateien irgendwo einzubinden, die selbst andere .cpp-Dateien einbinden, verlierst du in garantiert in sehr kurzer Zeit den Überblick, was noch kompiliert werden muss - falls du die Abhängigkeiten überhaupt noch auflösen kannst. Der normale Weg sieht so aus: Falls ÜE1 auf Variablen oder Funktionen in ÜE2 zugreifen muss, erstellt man eine .h-Datei für ÜE2, die nur die Deklarationen enthält. Die kann ÜE1 (und auch jede andere ÜE, die den Zugriff braucht) dann einbinden. Der Linker kümmert sich darum, dass das passt. Das hat auch den Vorteil, dass bei Änderungen nur die geänderte .cpp-Datei neu kompiliert werden muss. Bei dir muss viel mehr neu erstellt werden. Man muss das nicht so machen. Aber es ist erprobt und für größere Programme der einfachste Weg. Gewöhn es dir einfach an.

Das hat wenig mit wollen zu tun. Der Standard schreibt vor, dass main int zurückgeben muss. Dass dein Compiler auch void akzeptiert, bedeutet nicht, dass es richtig ist. @Kumkum: Den ganzen Aufwand mit dem char-Array kannst du dir sparen. Der Algorithmus, den BadJoke vorgeschlagen hat, funktioniert so auch in C.

Das Problem ist, dass nach dem Einlesen des int immer noch das Zeilenvorschubzeichen im Eingabestrom steht. Du kannst vor jedem Einlesen aus cin den Puffer leeren und die Fehlerbits zurücksetzen: cin.clear(); cin.ignore(cin.rdbuf()->in_avail()); [/CODE] P.S.: CPP-Tags haben wir hier nicht. P.P.S.: Du solltest dir abgewöhnen, goto einzusetzen, wo es eine simple Schleife auch tut.

Anmerkung: Erfordert Compileroption /EHa #include <afx.h> #include <afxwin.h> #include <eh.h> CWinApp theApp; typedef void (*_se_translator_function)(unsigned int, struct _EXCEPTION_POINTERS* ); class E { }; void SeTranslator(unsigned int n, struct _EXCEPTION_POINTERS* p) { throw E(); } UINT Thread(LPVOID) { _se_translator_function old = _set_se_translator(SeTranslator); try { int* p(0); *p = 42; } catch(E e) { AfxMessageBox("Caught"); } _set_se_translator(old); return 0; } int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0); CWinThread t(Thread, 0); t.m_bAutoDelete = FALSE; t.CreateThread(); Sleep(2000); DWORD res = WaitForSingleObject(t.m_hThread, 0); } [/CODE] Aus _EXCEPTION_POINTERS* p solltest du einiges an Informationen rausholen können.

WAIT_OBJECT_0 bedeutet, dass der Thread beendet ist. Läuft er noch, bekommst du WAIT_TIMEOUT. Kannst du das nicht nutzen? Ich hab da noch ein paar Sachen im Hinterkopf, habe aber gerade nicht die Zeit, sie rauszusuchen. Ich melde mich nochmal. Kannst du den abzufangenden Crash genauer spezifizieren?

Gut, das Wiederverwenden ist wohl in Ordnung. Aber bekommst du hier WAIT_FAILED? #include <afx.h> #include <afxwin.h> CWinApp theApp; UINT Thread(LPVOID) { return 0; } int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0); CWinThread t(Thread, 0); t.m_bAutoDelete = FALSE; t.CreateThread(); Sleep(2000); DWORD res = WaitForSingleObject(t.m_hThread, 0); }[/CODE]

Hättest du jetzt die vollständige Meldung gepostet, hätte man dir helfen können.

CWinThread::Delete "zerstört" kein Handle. Es gibt auch keinen Aufruf von CloseHandle in CWinThread::Delete. Delete ruft den Destruktor auf, falls m_bAutoDelete true ist, mehr nicht. Der ruft CloseHandle auf. Ein Threadhandle wird nicht ungültig, wenn der zugehörige Thread terminiert. Das passiert erst bei CloseHandle (im Destruktor von CWinThread). Davon rate ich dringend ab. Du solltest für einen neuen Thread auch eine neue CWinThread-Instanz anlegen. Ich könnte mir vorstellen, dass es zu Initialisierungs- oder Deinitialiserungsproblemen kommt, wenn du dieselbe Instanz wiederverwendest.

Ich verstehe immer noch nicht, was du mit "läuft zZt nicht" meinst. Das Handle eines Threads wird erst dann ungültig, wenn jemand CloseHandle aufruft. Das passiert AFAIK bei einem erfolgreich erstellten CWinThread nur im Destruktor. Wenn also die Objekte nicht zerstört werden, solltest du nicht ERROR_INVALID_HANDLE bekommen.