malloc, calloc, das selbe?



  • Gibt es einen Unterschied zwischen
    malloc(10*sizeof(int))
    und
    calloc(10, sizeof(int))
    ?



  • Ja, gibt es. calloc belegt den Speicher direkt mit 0 vor. Hättest du auch selber rausfinden können, in dem du die Infoseiten zu malloc und calloc gelesen hättest.



  • Ja: bei calloc wird der allokierte Speicher noch mit 0 initialisiert, bei malloc nicht.

    Zeh Mau



  • Ok, danke
    und sorry für die blöde Frage, aber ich hab noch eine(normal verwende ich C++ und damit new und delete, aber jetzt muss ich mal C verwenden)
    Wie genau funktioniert free bei Arrays?
    Denn selbst wenn ich char* array = (char*) calloc(10, sizeof(int));
    mache löscht er bei free(array) laut Debugger alle Elemente. Also woher weiß er wie viel freigegeben werden muss?



  • free() weiß selbständig, wie viel Speicher freizugeben ist, gesetzt der Fall, dass du den richtigen Pointer übergibst, den du auch für die Allokation benutzt hast.

    Zeh Mau



  • gilt das auch wenn ich einen größeren Speicherbereich in einem kleineren Pointer speichere?
    Warum braucht C++ dann delete und delete[] ? ich dachte die greifen intern auch auf free zu.



  • zu A) Wichtig ist nur, dass die Adresse, auf die der Pointer zeigt, dieselbe ist wie vom Allokieren.

    zu 😎 Weiß ich nicht. :xmas2:



  • Ankou schrieb:

    gilt das auch wenn ich einen größeren Speicherbereich in einem kleineren Pointer speichere?

    Solange der Pointer von malloc() und Co. gekommen ist, kann free() bestimmen, wie groß der dahinterliegende Speicherplatz ist. (wie es das macht, ist Betriebsgeheimnis)

    Warum braucht C++ dann delete und delete[] ? ich dachte die greifen intern auch auf free zu.

    Hauptsächlich um zu unterscheiden, ob es einen oder hundert Desktruktoren bei der Freigabe aufrufen muß.



  • Ankou schrieb:

    gilt das auch wenn ich einen größeren Speicherbereich in einem kleineren Pointer speichere?

    der speicher wird nicht in dem pointer gespeichert, sondern der pointer zeigt auf den anfang des speicherbereichs.

    Ankou schrieb:

    Warum braucht C++ dann delete und delete[]?

    es würde auch nur mit 'delete' funktionieren (was es real aber nicht tut). es gibt keinen vernünftigen grund dafür. das ist einfach so.

    Ankou schrieb:

    ich dachte die greifen intern auch auf free zu.

    ja, wird oft gemacht, ist aber keine bedingung. es könnte auch eine ganz andere speicherverwaltung dahinter stecken.
    🙂



  • allocation-fan schrieb:

    Ankou schrieb:

    Warum braucht C++ dann delete und delete[]?

    es würde auch nur mit 'delete' funktionieren (was es real aber nicht tut). es gibt keinen vernünftigen grund dafür. das ist einfach so.

    Nein, würde es nicht (bzw. ist nicht definiert was rauskommt, wenn new[] und delete vermischt werden.

    Einfaches Beispiel:

    class A
    {
    public:
      A() {cout<<"A Ctor "<<this<<endl;}
      ~A(){cout<<"A Dtor "<<this<<endl;}
    };
    
    ...
    A* ptr = new A[10];
    delete ptr;
    

    (na, was gibt das Programm wohl aus?)



  • CStoll schrieb:

    Nein, würde es nicht (bzw. ist nicht definiert was rauskommt, wenn new[] und delete vermischt werden.
    [/quote]
    ich sagte bereits, dass es in wirklichkeit nicht funktioniert, aber funktionieren könnte, wenn der erfinder von C++ 10 minuten nachgedacht hätte. immerhin kann man ja new x[10]; mit delete[] x; und nicht delete[10] x; löschen. d.h. delete[] ist immerhin so schlau dass es weiss. wie viele elemente das array hat. der schritt zur automatischen unterscheidung von array und nicht-array wäre sicher nicht gross gewesen.
    🙂



  • Du vergisst dabei, daß viele Programmierer auch auf den Speicherplatz achten - und wenn du für einen "new int" Aufruf dazuschreiben mußt, wieviel Platz du angefordert hast, verdoppelst du damit dessen Größe effektiv.



  • CStoll schrieb:

    Du vergisst dabei, daß viele Programmierer auch auf den Speicherplatz achten - und wenn du für einen "new int" Aufruf dazuschreiben mußt, wieviel Platz du angefordert hast, verdoppelst du damit dessen Größe effektiv.

    das wär doch nicht so schlimm, die grösse kommt einfach mit auf den heap. irgendwo muss c++ ja speichern, wie viele destruktoren aufgerufen werden müssen und ist diese information 0, dann isses eben kein array sondern eine einzelne variable. ich bin eigentlich kein freund von vielen automatismen (in C hätte sowas nichts zu suchen), aber c++ macht sowieso einiges im hintergrund, also wäre ein einzelner 'delete' operator schon in ordnung, wäre auch benutzerfreundlicher und eine potentielle fehlerquelle wäre verschwunden.
    🙂



  • was-wäre-wenn-freak schrieb:

    das wär doch nicht so schlimm, die grösse kommt einfach mit auf den heap. irgendwo muss c++ ja speichern, wie viele destruktoren aufgerufen werden müssen und ist diese information 0

    Darum geht es doch gerade. Diese Information muss bei einem Einzelobjekt nicht gespeichert werden. Bei einem int ist das 50% des Speicherplatzes, der gespart wird wenn man diese redundante Info eben nicht mit speichert.



  • was-wäre-wenn-freak schrieb:

    CStoll schrieb:

    Du vergisst dabei, daß viele Programmierer auch auf den Speicherplatz achten - und wenn du für einen "new int" Aufruf dazuschreiben mußt, wieviel Platz du angefordert hast, verdoppelst du damit dessen Größe effektiv.

    das wär doch nicht so schlimm, die grösse kommt einfach mit auf den heap. irgendwo muss c++ ja speichern, wie viele destruktoren aufgerufen werden müssen und ist diese information 0, dann isses eben kein array sondern eine einzelne variable. ich bin eigentlich kein freund von vielen automatismen (in C hätte sowas nichts zu suchen), aber c++ macht sowieso einiges im hintergrund, also wäre ein einzelner 'delete' operator schon in ordnung, wäre auch benutzerfreundlicher und eine potentielle fehlerquelle wäre verschwunden.
    🙂

    Bei der Arbeit mit new/delete muß C++ eben NICHT speichern, wieviele Destruktoren es benötigt (ist grundsätzlich genau einer).



  • aber niemand wird ein programm schreiben mit 100.000 einzelnen new int; darin, o.ä. so dass dieser overhead tatsächlich ins gewicht fällt, es sei denn er ist total durchgeknallt. da nimmt man dann doch lieber ein paar arrays.
    🙂


Anmelden zum Antworten