...wenn free oder delete vergessen wird



  • Hi Leute,

    ich habe mal eine Frage, die mir schon lange auf der Seele brennt...
    Wenn ich Speicher mit new/malloc reserviere und später vergesse diesen wieder mit delete/free freizugeben, dann habe ich gewisserweise ein Speicherleck.

    ...wann ist ein solcher Speicher wieder verfügbar? Nach Programmende oder erst nach neustart des PCs?

    viele Grüße,
    SBond



  • Das OS räumt nach Prozessende auf.



  • supi 🙂

    vielen Dank für die Antwort 😃



  • Dieser Thread wurde von Moderator/in Arcoth aus dem Forum C++ (alle ISO-Standards) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • 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. 🙂


Anmelden zum Antworten