...wenn free oder delete vergessen wird



  • Arcoth schrieb:

    Das OS räumt nach Prozessende auf.

    Das hängt vom OS ab.

    DOS, AmigaOS, AROS und Win9x/Me können das meistens nicht.


  • Mod

    Stimmt nicht schrieb:

    DOS, AmigaOS, AROS und Win9x/Me können das meistens nicht.

    Oh, nein! Die sind ja auch nur älter als der durchschnittlicher Programmierer von heute.

    Abgesehen von historischen Betriebssystemen deutet ein "vergessenes" free aber auf einen Logikfehler im Programm hin. Wobei dieser Fehler auch sein kann, dass der Programmierer einfach nicht weiß, wie man es richtig macht. Nichtsdestotrotz ein Fehler. Wenn andere Ressourcen (Datenbankverbindungen, Sockets, ...) ebenso fehlerhaft verwaltet werden, dann können die Konsequenzen weitaus schlimmer sein, denn dann kann einem das Betriebssystem oftmals nicht den Popo abwischen.



  • Nichtsdestotrotz ein Fehler.

    Nicht, wenn man mit Qt arbeitet. IIRC.


  • Mod

    Arcoth schrieb:

    Nichtsdestotrotz ein Fehler.

    Nicht, wenn man mit Qt arbeitet. IIRC.

    Was meinst du damit? Ich arbeite nicht mit Qt. Falls Qt automatisch Ressourcen freigibt, hat man es ja nicht vergessen, sondern macht es wie vorgesehen.



  • SeppJ schrieb:

    Arcoth schrieb:

    Nichtsdestotrotz ein Fehler.

    Nicht, wenn man mit Qt arbeitet. IIRC.

    Was meinst du damit?

    Soweit ich mich richtig erinnere, führt e.g. vom Qt Designer generierter Code nie ein delete auf die allozierten Widgets im Destruktor aus. Vielleicht arbeitet da intern eine Art GC?



  • Unsinn, bei Qt räumt ein parent seine Kinder auf.



  • ...wenn free oder delete vergessen wird

    Dann kommt man in die Hölle...



  • Tyrdal schrieb:

    Unsinn, bei Qt räumt ein parent seine Kinder auf.

    Hmm, macht auch mehr Sinn. Muss ich wohl falsch in Erinnerung gehabt haben, habe Qt schließlich seit sehr vielen Monden nicht mehr angefasst 😉



  • SeppJ schrieb:

    Abgesehen von historischen Betriebssystemen deutet ein "vergessenes" free aber auf einen Logikfehler im Programm hin. Wobei dieser Fehler auch sein kann, dass der Programmierer einfach nicht weiß, wie man es richtig macht.

    Biste wieder weit ausm Fenster.
    Stichwort (de)initialization order fiasco.
    Lieber einfach weglassen. Funktioniert.



  • Lieber einfach weglassen. Funktioniert.

    Ist das nicht auf die Dauer tödlich? Also bei vielen Objekten? Oder reden wir hier von ein paar Kilobytes?



  • Also ich zumindest rede von Singletons bzw. allgemein statischen/globalen Objekten, denn genau bei denen gibt es das (de)initialization order fisaco. OK, vollständig heisst es static (de)initialization order fisaco. Das "static" wäre wohl ein guter Tip gewesen, hätte ich vielleicht nicht weglassen sollen 😉



  • hustbaer schrieb:

    Also ich zumindest rede von Singletons bzw. allgemein statischen/globalen Objekten, denn genau bei denen gibt es das (de)initialization order fisaco. OK, vollständig heisst es static (de)initialization order fisaco. Das "static" wäre wohl ein guter Tip gewesen, hätte ich vielleicht nicht weglassen sollen 😉

    Nichts desto trotz hat SeppJ 100% recht.



  • Sagst du.
    Ich sag' das Gegenteil.
    Und nu?



  • hustbaer schrieb:

    Sagst du.
    Ich sag' das Gegenteil.
    Und nu?

    Du könntest ja Argumente bringen, aber das wäre langweilig weil man ein "Fehlendes delete deutet auf Logikfehler hin" nicht widerlegen kann. Es deutet nunmal auf einen Logikfehler hin - es ist nicht jedesmal zwingend einer, aber es deutet darauf hin.

    Auch wenn du dir Situationen konstruieren kannst wo ein fehlendes delete kein Logikfehler ist, widerlegst du SeppJs Aussage damit nicht.


  • Mod

    Ich hasse es, dass man in diesem Forum jede Antwort auf selbst einfachste Fragen mit 10 Seiten Disclaimern für alle vorstellbaren und unvorstellbaren Sonderfälle versehen muss. Da antworte ich teilweise lieber gar nicht mehr. Wurde mal wieder bestätigt.



  • SeppJ schrieb:

    Ich hasse es, dass man in diesem Forum jede Antwort auf selbst einfachste Fragen mit 10 Seiten Disclaimern für alle vorstellbaren und unvorstellbaren Sonderfälle versehen muss. Da antworte ich teilweise lieber gar nicht mehr. Wurde mal wieder bestätigt.

    das ist wohl eine Informatikerkrankheit.
    Irgendwer kommt immer mit einem Spezialfall daher, der gegen die Argumentation spricht. Meist in der Form "...aber TotalTollesFrameworkXY macht das anders ..."

    Ich darf jeden Tag in der Arbeit dieses Spiel spielen, sei froh dass es dich nur im Forum trifft 😉



  • Das ist diesmal keine Disclaimerkrankheit, sondern eine Unfugkrankheit.

    Stimmt nicht schrieb:

    Arcoth schrieb:

    Das OS räumt nach Prozessende auf.

    Das hängt vom OS ab.
    DOS, AmigaOS, AROS und Win9x/Me können das meistens nicht.

    Unfug. Beim Speicher klappts mit DOS und Win95 auch sauber. AmigaOS und AROS kenne ich nicht, glaube Dir aber ganz einfach nicht, daß die den Speicher nicht freigeben. Soweit sind malloc/free kein Problem.

    Um Speicher ging es in der Frage. new/delete kann auch beliebige andere Ressourcen binden. Win95 kann auch alle anderen Betriebssystemressourcen bis auf wenige Ausnahmen wie file locks. DOS hat keine anderen Betriebssystemressourcen, oder? Oh, TSR-Speicher wird nicht freigegeben, das ist aber kein Bug, sondern ein Feature. 🙂



  • hustbaer schrieb:

    Sagst du.
    Ich sag' das Gegenteil.
    Und nu?

    Nimm weniger Drogen beim Posten.



  • Tyrdal schrieb:

    Unsinn, bei Qt räumt ein parent seine Kinder auf.

    Auf meine Frage, wie es unsere GUI-Leute mit Exceptions halten, ob sie welche werfen, ob sie welche fangen, ob sie ihren Code exceptionsicher bauen, bekam ich zur Antwort: Wir scheren uns eigentlich gar nicht um Exceptions, denn das Qt-Framework erledigt das für uns. 😮



  • volkard schrieb:

    AmigaOS und AROS kenne ich nicht, glaube Dir aber ganz einfach nicht, daß die den Speicher nicht freigeben. Soweit sind malloc/free kein Problem.

    AROS kenne ich nicht, aber AmigaOS kenne ich gut. Hab selbst mal etwas dafür entwickelt was man unter DOS als TSR ("Terminate and Stay Resident") bezeichnet hätte. Daher weiss ich dass man unter AmigaOS keine speziellen Funktionen verwenden muss wenn man Speicher möchte der nach Programmende nicht freigegeben wird -- ganz normal AllocMem/AllocVec und dann ganz normal das Programm beenden und der Speicher bleibt belegt.

    Wenn man natürlich die Funktionen der Runtime-Library verwendet, dann kommt es auf die Runtime-Library an. Vermutlich haben die Runtime-Implementierungen der gängigen Compiler für AmigaOS das auch so gehandhabt dass bei Programmende der gesamte CRT-Heap freigegeben wird. Ist aber keine Funktion des OS, und daher irrelevant.

    Und nimm bitte selbst weniger Drogen.

    ps:
    https://en.wikipedia.org/wiki/Memory_leak

    running on an operating system that does not automatically release memory on program termination. Often on such machines if memory is lost, it can only be reclaimed by a reboot, an example of such a system being AmigaOS.[citation needed]


Anmelden zum Antworten