Klotzkopp

Du musst die Bedingung negieren. Bei dir steht quasi die "Abbruchbedingung". Die while-Schleife benötigt eine Weitermachbedingung. Du musst also nur das logische Gegenteil des Bedingungsausdrucks bilden. Und so ein bißchen Code kannst du auch ins Forum pasten, das ist kein Problem.

Das sind aber ganz stark nach C aus, nicht C++. Einzelne Zeichen schreibt man ja auch mit fputc (c für Character), nicht fputs (s für String). Einfacher ist es aber, eine Escapesequenz zu benutzen: fputs ("\"", pFile);

Ich glaube, du hast nicht ganz verstanden, wo das Problem liegt Das ist eine Zuweisung: if(a = [/code] [b]Das[/b] ist ein Vergleich: [code]if(a ==

Na und? In der Beschreibung von Quicksort steht nicht: "Prüfe, ob die Liste bereits sortiert ist, und falls ja, brich ab." Der Algorithmus prüft das nicht, er macht weiter. Ich sagte es doch schonmal:

Du musst doch einfach nur denselben Algorithmus auf die gefundenen Teillisten [ 0 1 2 ] und [ 4 5 ] anwenden.

Vermutlich nicht, weil du die Teillisten, die sich aus dem ersten Schritt ergeben, nicht sortiert hast.

Naja, zumindest ist sie unvollständig. Quicksort erkennt nicht auf magische Weise, dass die verbliebenen Teillisten bereits sortiert sind, der Algorithmus läuft weiter bis zum bitteren Ende. Auch wenn nichts mehr vertauscht wird, es wird weiter geteilt, bis die Teillisten eine triviale Größe erreicht haben. Du brauchst nichts zu verbinden, weil nie etwas getrennt wurde. Quicksort arbeitet "in-place".

-32767 gibt's in C++ auch. Vergleiche macht man allerdings mit doppelten Gleichheitszeichen. Einzelne Gleichheitszeichen bewirken eine Zuweisung. Und bei nächsten Mal bitte eine bessere Fehlerbeschreibung als "geht leider nicht :S". Weniger komische Smileys, mehr Fehlermeldung

Das klingt nach einem nutzlosen Scherzprogramm. Viel Glück bei der Suche nach jemandem, der dir so etwas schreibt. Ernsthafte Programmierer werden so etwas kaum machen.

Die bei Wikipedia beschriebene Variante tauscht nur dann, wenn die Elemente echt größer bzw. echt kleiner sind als das Pivotelement. Das spart Vertauschungen, es kann aber passieren, dass die Grenze ganz am Rand liegt. Dann würde der Algorithmus nicht terminieren. Das kann man verhindern, indem man das Pivotelement rausnimmt, und damit garantiert, dass die Teilmengen kleiner als die Usprungsmenge sind.

"2 noch mit auf die linke Seite" kommt aber bei Quicksort nicht vor. Du kannst nicht einfach irgendwelche Schritte für Spezialfälle dazuerfinden, denn dann ist das kein Algorithmus mehr. Entweder du bringst das Pivotelement an die richtige Stelle (d.h. 2 und 3 vertauschen), dann hast du [0 1 2] 3 [4 5], oder nicht, dann hast du [0 1 3 2] [4 5].

Ich weiß nicht, was du da machst, aber Quicksort ist es nicht. Wenn du die 0 als Pivotelement wählst, findet der linke Zähler die 5, und der rechte gar nichts, es wird also zunächst einmal nichts vertauscht. Dann wird das Pivotelement selbst an die richtige Stelle gepackt (sonst würde das nicht terminieren), d.h. die 5 und die 0 werden vertauscht. Damit ist die 0 an der richtigen Stelle, die linke Teilliste ist leer, und die rechte Teilliste ist 4 3 2 1 5.

"Dein Bekannter" will also ein Programm, das aussieht wie Hyperterminal, aber eigentlich nichts tut?

Langsam, das sind nicht die Teillisten des ersten Durchgangs. Wenn das Pivotelement 3 ist, kann nicht 2 in der rechten Teilliste landen. Und wo ist überhaupt die 3 geblieben? Das Pivotelement kannst du beim Teilen nur dann weglassen, wenn du es zwischen die Teillisten setzt. Das hast du aber nicht gemacht.

So wie auf jedes andere Array auch. Sortieralgorithmen haben die Eigenschaft, mit jeder Art von Eingabedaten zu funktionieren. Weißt du denn, wie Quicksort grundsätzlich funkioniert? Hier findest du eine Animation und ein Beispiel für einen kompletten Sortierdurchlauf.

Du hast bisher nicht verraten, wo dieser Ordner config mit der Datei temp_boot liegt, aber ich nehme an, er liegt in dem Verzeichnis, in dem auch die Programmdatei liegt. Du weißt natürlich zur Compilezeit nicht, welches Verzeichnis das ist. Aber mit dieser Funktion kannst du das zur Laufzeit herausbekommen. An den zurückgegebenen String hängst du einfach config\temp_boot an, und schon hast du einen absoluten Pfad.

Sobald du dein Programm ausführst, ist bereits eine exe-Datei erstellt worden. Das ist aber kein Speichern im eigentlichen Sinne, weil du aus der exe-Datei nicht einfach wieder den Quellcode rekonstruieren kannst.

Dann empfehle ich, das zweidimensionale Array auf ein eindimensionales Array abzubilden, und die Positionen entsprechend auszurechnen. Etwas anderes macht der Compiler bei zweidimensionalen Arrays auch nicht. Andererseits sind mehrdimensionale Arrays immer ein furchtbares Gehampel, wie du ja sicher gemerkt hast. Mit Objekten meinst du jetzt die ints? Dann gibt es immer noch keinen Grund, warum die Vectoren (die dritte Dimension) Zeiger sein sollten. Kommt drauf an, wie aufwändig die Kopieroperationen sind. Wenn die Objekte eine ordentliche swap-Methode haben, kann das sehr schnell sein. Andererseits verbrauchen die Zeiger natürlich zusätzlichen Speicher. Vermutlich meinst du std::vector<int*> M[zeilen][spalten]; Das geht, ist aber Blödsinn, zumindest für int. Kein Performancegewinn, doppelter Speicherbedarf. Wie gesagt, das kommt stark auf die Objekte an. Wie groß sind die denn so?

Warum willst du denn mit einem Zeiger durch dein Array laufen? Und ist es wirklich unbedingt notwendig, dass die Elemente Zeiger sind? Und das hier: *(new int(rand() % 9 + 1)) ist ein astreines Speicherleck. Die Zeiger kannst du nie wieder freigeben. Ich habe mir mal erlaubt, das ganze ohne Zeiger zu machen. #include <iostream> #include <cstdlib> #include <ctime> #include <vector> const int zeilen = 3; const int spalten = 4; void h( std::vector<int> M[zeilen][spalten]){ for(int i=0; i<zeilen; i++){ std::cout << "\t*[ "; for(int j=0; j<spalten; j++){ std::cout << "("; int laenge=M[i][j].size(); for(int k=0; k<laenge; k++){ std::cout << M[i][j][k] << ","; } std::cout << ") "; } std::cout << "]\n"; } } int main() { int laenge = 2; // spater verschieden srand(15); std::vector<int> M[zeilen][spalten]; for(int i=0; i<zeilen; i++){ std::cout << "\t[ "; for(int j=0; j<spalten; j++){ M[i][j].resize(laenge); std::cout << "("; for(int k=0; k<laenge; k++){ M[i][j][k] = rand() % 9 + 1; std::cout << M[i][j][k] << ","; } std::cout << ") "; } std::cout << "]\n"; } std::cout << "**************************\n"; h(M); std::cout << "\nprog ended successfully\n"; return 0; } // end main()[/code]

Links auf derartige Tools möchten wir hier nicht, siehe Boardregeln.

Da steht nur, dass man in die erste Partition installieren muss. Von der Anzahl der Partitionen steht da gar nichts. Das heißt, du hast bereits versucht, neu zu partitionieren? Was heißt denn "funktioniert nicht"?

Application.StartupPath Property (System.Windows.Forms)

Was meinst du mit "Datenverwaltung übernehmen"? Und warum meinst du, dass du das musst, wenn du Windows von einem USB-Stick installierst?

Doch, machst du. Du benutzt einen relativen Pfad. Relative Pfade beziehen sich auf das Arbeitsverzeichnis. Also nimmst du an, dass unterhalb des Arbeitsverzeichnisses (das wie gesagt, alles mögliche sein kann) ein Unterverzeichnis config mit einer Datei temp_boot liegt. Das trifft aber vermutlich nur dann zu, wenn das Arbeitsverzeichnis auch das Verzeichnis ist, in dem das Programm liegt. Du triffst eine Annahme über das Arbeitsverzeichnis, und wenn diese nicht zutrifft, funktioniert dein Programm nicht. Natürlich nicht, davon rede ich doch die ganze Zeit. Versuch bitte nicht, durch Herumfrickeln mit Verknüpfungen oder Batchdateien den Fehler in deinem Programm zu umgehen. Beheb ihn.

Wenn dein Programm nur dann funktioniert, wenn das Arbeitsverzeichnis auch das Programmverzeichnis ist, ist das ein Bug in deinem Programm. Bei einer sauberen Programmierung darfst du keinerlei Annahmen über das Arbeitsverzeichnis machen. Das kann alles mögliche sein, insbesondere wenn jemand dein Programm über die Eingabeaufforderung startet oder eigene Verknüpfungen anlegt. Zudem gibt es Windows-Funktionen, die das Arbeitsverzeichnis zur Laufzeit ändern können. Relative Pfade haben da nichts zu suchen.