Wo leake ich hier memory? Dynamic array

[Swordfish]

Wichtig: Frag bitte. Frag bitte bei jeder Zeile die unklar ist oder Dir auch nur komisch erscheint nach!!

[marcel91200]

@Swordfish Was bedeutet denn:

if (!data_size)

Also dann hat man keinen Input eingegeben, aber man initialisiert doch data_size mit nem Wert, was hat das "!" da zu suchen?

[Swordfish]

@marcel91200 Wenn kein input dann hat data_size den Wert 0 mit dem es initialisiert wurde. !0 gibt true. Kurz für data_size == 0.

[marcel91200]

@Swordfish Achso, wusste nicht dass das geht ^^
Wenn man es aber jetzt "richtig" machen muesste, wuerde man doch gar nicht mit free und so ausserhalb von nem Destruktor arbeiten oder? Damit man sich nicht selbst staendig um die Speicheralloziierung kuemmern muss

[Swordfish]

@marcel91200 sagte in Wo leake ich hier memory? Dynamic array:

Wenn man es aber jetzt "richtig" machen muesste, wuerde man doch gar nicht mit free und so ausserhalb von nem Destruktor arbeiten oder? Damit man sich nicht selbst staendig um die Speicheralloziierung kuemmern muss

Nein. Man würde std::vector<> oder std::deque<> nehmen. (Nein, man würde so einen Container nicht selbst schreiben.)

@Swordfish sagte in Wo leake ich hier memory? Dynamic array:

//edit: Diskussion über eine halbwegs no-bullshit Vectorimplementierung in dem Thread: https://www.c-plusplus.net/forum/topic/351034/run-time-check-failure-2

Deswegen nicht.

Auch die C-Reliquien sind in C++ mit äußerster Vorsicht zu genießen weil malloc() und co für alles was nicht POD ist nicht funktionieren.

[marcel91200]

Gibt es keine Faelle in denen es sinnvoll waere sowas selbst zu implementieren? Was ist denn sonst der Sinn von dem Ganzen, wenn man es nie benutzen soll? Also natuerlich spart man sich ne Menge Arbeit und Probleme wenn man es nie benutzt, aber trotzdem eigenartig

[Swordfish]

@marcel91200 sagte in Wo leake ich hier memory? Dynamic array:

Gibt es keine Faelle in denen es sinnvoll waere sowas selbst zu implementieren? Was ist denn sonst der Sinn von dem Ganzen, wenn man es nie benutzen soll?

Sinnvoll. Ja, schon irgendwie. Man sollte mal erlebt haben was Speicherverwaltung bedeutet. Sowas relativ am Anfang eines C++-Kurses zu machen halte ich für Bullshit.
Container selbst implementieren? Ja klar. Wenn man ganz spezielle Anforderungen hat. Aber auch dann würde man eher nur einen allocator schreiben. Oder man braucht sowas in die Richtung: https://patents.google.com/patent/US8375062B2/en

[Swordfish]

Hast Du den Code schon um den trivialen Rest ergänzt und kommt er durch die Validierung eures tollen Servers?

[marcel91200]

@Swordfish Das werd ich morgen mal ausprobieren, danke dir nochmal fuer die Hilfe und die ganzen Ansaetze die ich noch lernen muss ^^

[Swordfish]

Kein Problem. Der Thread war ein Trauerspiel zum mitansehen. Willst Du denn wirklich C++ lernen?

[marcel91200]

@Swordfish sagte in Wo leake ich hier memory? Dynamic array:

Kein Problem. Der Thread war ein Trauerspiel zum mitansehen. Willst Du denn wirklich C++ lernen?

Ja eigentlich schon, aber haben es von der Uni aus jetzt auch erst seit 2 Wochen. Da ist ja klar, dass ich noch einiges vor mir hab

[Swordfish]

Ja nee. Besorg' Dir "Der C++-Programmierer" in der aktuellen Auflage und vergiss ganz schnell ganz viel von dem was Du an der Uni "lernst".
Talent scheinst Du zu haben bei nur einer Frage zu meinem Code

[marcel91200]

@Swordfish Danke fuer den Tipp, ich werds mir mal anschauen, ich wollte mir eh noch ein Buch dazu holen. Ist leichter als sich nur durch Tutorials und Dokumentationen zu lesen fuer den Anfang

[Swordfish]

Das Hauptproblem mit Tutorials ist daß Du die Qualität als Anfänger nicht einschätzen kannst und Du Dir sehr wahrscheinlich Blödsinn beibringst.
Da ein Link zu "unserem" Discord: https://discord.gg/5aGDBu2r

[Swordfish]

@Swordfish sagte in Wo leake ich hier memory? Dynamic array:

    double input;

    std::cout << "Your values:\n";
    while (std::cout << data_size + 1 << ": ", std::cin >> input) {
        double *tmp = static_cast<double*>(std::realloc(data, (data_size + 1) * sizeof(*data)));
        if (!tmp) {
            std::cerr << "Not enough memory :(\n\n";
            std::free(data);
            return EXIT_FAILURE;
        }
        data = tmp;
        data[data_size] = input;
        ++data_size;
    }

ach so, daraus sollte man eher eine for-loop machen:

    std::cout << "Your values:\n";
    for (double input; std::cout << data_size + 1 << ": ", std::cin >> input; ++data_size) {
        double *tmp = static_cast<double*>(std::realloc(data, (data_size + 1) * sizeof(*data)));
        if (!tmp) {
            std::cerr << "Not enough memory :(\n\n";
            std::free(data);
            return EXIT_FAILURE;
        }
        data = tmp;
        data[data_size] = input;
    }

Hat den Vorteil der engeren Lokalität von input und der hervorragenden Stelle an der data_size inkrementiert wird.

[Swordfish]

@marcel91200 Darf ich fragen welche Uni?

[hustbaer]

@Swordfish sagte in Wo leake ich hier memory? Dynamic array:

ach so, daraus sollte man eher eine for-loop machen:

    std::cout << "Your values:\n";
    for (double input; std::cout << data_size + 1 << ": ", std::cin >> input; ++data_size) {
        double *tmp = static_cast<double*>(std::realloc(data, (data_size + 1) * sizeof(*data)));
        if (!tmp) {
...

Ich würde eher sagen: Man sollte in Schleifenbedingungen keinen , Operator verwenden.

[Swordfish]

@hustbaer Ja, Du hast natürlich völlig recht, ist eine saublöde Angewohnheit

[hustbaer]

Naja, man kann da auch unterschiedlicher Meinung sein. Ich finde es halt doof.

[*john 0]

@marcel91200 sagte in Wo leake ich hier memory? Dynamic array:

Gibt es keine Faelle in denen es sinnvoll waere sowas selbst zu implementieren? Was ist denn sonst der Sinn von dem Ganzen, wenn man es nie benutzen soll? Also natuerlich spart man sich ne Menge Arbeit und Probleme wenn man es nie benutzt, aber trotzdem eigenartig

Man darf nicht vergessen, dass das ganze historisch gewachsen ist. Es wurden kaum Bestandteile der Sprache entfernt, so dass fast jeder alter Code übersetzt werden kann. Bei einigen modernen Modesprachen ist das nicht der Fall, da wird nach Belieben die Kompatibilität mit alten Code gebrochen – nicht so bei C++.

Vor der ersten ISO Norm von C++ war es faktisch unmöglich Programme zu schreiben, die kein new/delete verwendet haben. Mit der ersten ISO Norm (1998) wurden auch die Container zum Teil der Sprache, während sie vorher als STL durch die C++ Community verbreitet wurden. Die letzte von Stroustrup selbst publizierte Version (cfront 3.0) war sehr viel einfacher als das was es heute als ISO Norm gibt. Damals hatte die Sprachdefinition keine 300 Seiten (als Anhang in Die C++ Programmiersprache), mittlerweile ist die ISO Norm mehr als 1600 umfangreich.

Es gab dann für C++98 ein sehr gutes Einsteigerlehrbuch für modernes C++: Accelerated C++ von Koenig und Moo. Leider haben die beiden Autoren nie eine aktuelle Auflage für C++11 oder neuer publiziert. Was man hier bei den Aufgaben mal wieder sieht: die Intention der Dozenten ist es, lowlevel Speicherverwaltung zu lehren, weil man das einfach mal gemacht haben muss. Aber das passt leider gar nicht mehr zu modernem C++ und würde dort nur in extremen Ausnahmen eingesetzt z.B. wenn man einfängt einen eigenen Container zu schreiben, der dann aber wiederum nicht direkt auf Speicheranforderungen setzen würde, sondern einen Allokator nutzen würde. An dieser Stelle hatte ich einen Allokator gepostet, der die Allokation auf einem NUMA-System simuliert. Man kann daran sehen, wie man im Prinzip einen Allokator zu schreiben hat. Und mein Allokator nutzt für die eigentliche Speicherverwaltung zwar malloc und free, legt aber den Zeiger in einem std::unique_ptr ab, und übergibt diesem bei Konstruktion gleich die free Funktion, damit der std::unique_ptr sie selbst bei Bedarf aufruft.

Ich habe vor einiger Zeit damit angefangen eine eigene Matrixklasse zu schreiben, die per Allokator Speicher anfordert, aber da das ganze alles andere als trivial ist, ist sie noch nicht fertig und vor allem getestet. D.h. eigene Container zu schreiben ist alles andere als trivial.