Kratzy974

Jaja, war ja auch nur Hinweis. In dem Fall wäre die Geschwindikeit eh nicht wichtig, zu wenig Elemente für ein großen Unterschied (Quicksort's Zeitverhalten nähert sich dann auch der n² des Bubblesort an). Aber bei mehr Elementen eines Int Arrays wäre Quicksort auf jeden Fall vorzuziehen (normalerweise n*log(n), worst case n²). Bei ganz großen Mengen ist Heapsort auch Klasse. (auch angegeben mit n*log(n)). Beim Sortieren von anderen Listen können andere Algorithmen schneller sein, da dort auch die Zugriffzeiten und Speicherverbrauch usw wichtig sind. Ich habe allerdings noch keinen sinnvollen Einsatz von Bubblesort gesehen, wo es Quicksort nicht besser gemacht hätte.

Ich frag mich die ganze Zeit, warum Bubblesort. Ist doch eher eins der langsamen. Da kann man doch gleich Quicksort nehmen. Das ist sogar in der Standard Library : int compare_ints( const void* a, const void* b ) { int* arg1 = (int*) a; int* arg2 = (int*) b; if( *arg1 < *arg2 ) return -1; else if( *arg1 == *arg2 ) return 0; else return 1; } ... qsort( array, array_size, sizeof(int), compare_ints ); [/PHP] (geklaut aus http://www.cppreference.com/stdother/qsort.html) Ehrlich gesagt, für das Problem nehm ich auch lieber die von Eytibi genannte Lösungsart. Bubblesort nimmt man doch normalerweise nur, um zu lernen, wie Sortieren funktioniert. Nicht für Min / Max Aufgaben.

Bei genau zwei Rückgabewerten kann man auch mit der Klasse std :: pair arbeiten, um sich den Aufbau eine Struktur zu schenken. Beim Funktionsaufruf einer Funktion mir void func(int* any) kann auch NULL als parameter übergeben werden. Das muß in der Funktion mit überprüft werden. Aus dem Grunde bin ich eher für void func(int& any), da hier diese Abfrage in die Compilezeit gelegt wir (Compilefehler) anstatt wärend der Laufzeit passiert (if any == NULL -> return). Den Pointer würde ich bei optionalen Parametern verwenden. Dadurch ergibt sich auch eine andere Lesbarkeit (& - veränderbar, nötig, * - veränderbar optional ... )

Eine Sache noch Es wird bei i++ mehr Speicheplatz benötigt, als bei ++i. Dies läßt sich gut mit der Implementation des operators darstellen : className operator ++() // ++i { // increace current object return *this; } className operator ++(int) // i++ { className newObj(*this); // increase current object return newObj; } [/PHP]

Ahh, das ist eine gute Erklärung. Zwar tauchten bei mir noch keine der Probleme mit STL containern auf, aber habe auch nicht auf allen Compilern gearbeitet. Den operator = habe ich dennoch lieber nach Meyer implementiert (bis auf das const) TestClass& operator = (TestClass const& obj) { TestClass newObj(obj); this->swap(newObj); return *this; } [/PHP] ... so und nu los, einigen Sourcecode umschreiben *g*

Kleine Ergänzung : CTestClass const& operator=(const CTestClass& rhs) { // Zuweisung, z.B. mit Copy&Swap return *this; } [/PHP] da sonst (test = test2) = test 3 funktionieren würde, was im Fehlerfall in if statements passieren kann (beim vertippen von = statt ==)

Ja, es würde für eine Klasse gehen, welche keinen eigenen Speicher mit new oä allokalisiert. Jedoch würde ich immer einen operator = schreiben, damit nicht in Zukunft, wenn die Klasse geändert wird unerklärliche Probleme auftreten.

Vielleicht hab ich irgendwas übersehen, aber versuch es doch mal mit PostMessage(WM_KEYDOWN, 116, 0); immerhin ist der zweite Parameter das übergebene wParam, und der dritte der lParam. Kristian

Sprachwirrwarr im Kopf, Also nochmal : Stack kann mit /F unter VC++ angepasst werden (Kompileroption). Für Threads gibt es eigendlich immer Befehle. Stackgröße hatte ich bisher nicht in den Debug informationen gesehen (andere Kompiler haben das vielleicht, vielleicht auch der VC*, weiß bloß nicht wo). Aber der Stack sollte eigendlich kein Problem sein, wenn men damit nicht vorsätzlich verschwenderisch umgeht.

This is compiler and system dependend. To set the Stacksize with VC++ you could use the compiler option /F I didn't see any debug information for current stacksize. But I didn't need that information. But : At normal you don't get Stackoverflows, when you use for larger memoryparts (the char[1000] thing) the heap.

Vielleicht noch ein Hinweis : nach free (heap) sollte nicht mehr auf heap zugegriffen werden, sonst kann es zu Abstürzen kommen. Der Speicher ist deinem Programm nicht mehr zugewiesen. Gruß, Kristian

Der Heap ist dein Arbeitsspeicher + Virtuellen Speicher. Liegt also an deinem Systemspeicher. Der Stack ist am Start des Programms / Threads festgelegt, auf dem WinXP Rechner normalerweise 1 MB. Wenn der Stack voll ist, gibts ein Stackoverflow, sprich einen Absturz (undefinierter Zustand). Der Stack wird auch für die Aufrufe von Funktionen verwendet und Baut sich FiLo (First in / Last out) auf. Dabei werden auch die zu übergebenden Variablen (Parameter eine Funktion) auf dem Stack gespeichert. Dabei kann es natürlich bei rekursiven Aufrufen (eine Funktion ruft sich selber auf) zu Stackoverflows kommen, wenn dies nicht begrenzt wird. Stack ist wichtig und recht klein, also alle größeren Wünsche an den Heap richten. Grüße, Kristian Kratzenstein

.. und gcc 3.3 / 4.0 ... und Codewarrior (ab 8.3, uU auch früher) Borland hab ich nicht benutzt.

Ein Includewächter sollte in jeder Header datei sein. Meistens funktioniert auch ein #pragma once . Dabei kann es zu keinen Namensproblemen mit den Defines kommen.

Die andere Möglichkeit, die Größe mitgeben. Als Struktur, zusätzlicher Parameter oder (bei Zahlen möglich) als erstes Element (wie Pascal String). Speicher für eine Größe würde auch gebraucht. Der Speichergewinn / Verlust ist dabei abhängig von der Elementgröße. Der Vorteil ist halt, daß nur der Array bekannst sein muß, keine zusätzlichen Informationen. Der Nachteil, daß eine Elementmöglichkeit entfällt. Zeitaufwand : ist bei Linearer Bearbeitung nicht anders. Bei der Größenermittlung natürlich anders.