Muss ich, nur weil ich Objekte benutze...



  • Nope -
    wenn ich Objekte erstelle, dann mach ich das mit new, klar.
    Wenn ich aber nur nen Pufferspeicher in variabler Größe habe, mach ich das per malloc..

    [Edit] @ Marc++us: Naja, ich hab so die dumme Angewohnheit, für meine Fragen und Antowrten einzutreten und mich zerpflücken zu lassen. hab ja eh nix zu verlieren - nur zu lernen. Außerdem ist das Einzige, was ich während meiner ausbildung wirklich gelernt hatte, dass man nur richtig arbeiten kann, wenn man die unangenehmsten Fragen auch stellt..

    [ Dieser Beitrag wurde am 22.01.2003 um 14:59 Uhr von DocJunioR editiert. ]



  • Original erstellt von DocJunioR:
    Wenn ich aber nur nen Pufferspeicher in variabler Größe habe, mach ich das per malloc..

    Wozu diese Inkonsistenz?



  • er mag grosse executables. und will angeben, was er alles fuer englische woerter kennt. sorry, einen anderen grund gibts hier echt nicht.
    wenn man die c++ version nicht kennt und deshalb c nimmt, weil man halt weiterkommen will, dann ist das ok. ober nostalgie pflegen ist hier wohl kaum sinnvoll.



  • Wenn ich einen Puffer für irgendwelche Objekte bräuchte, würde ich vermutlich auch in C++ malloc verwenden. Einfach, weil es mir das ist, was ich dann will. 'new char[]' und 'std::vector<char> v (...)' signalisierem dem Leser, dass es um eine Folge von chars (also idR Strings) geht. Ein 'malloc (...)' gibt mir Speicher 'ohne Typ', also genau das, was ich will.

    Es ist also nicht 'Inkonsistenz', sondern vielleicht das richtige Werkzeug.



  • Wer unbedingt new char[] vermeiden will:

    void *allocate_bytes(size_t n) {
      return (void *) new char [n];
    }
    

    Wunderbar, wir können delete [] nutzen.
    Wer delete [] aber häßlich findet:

    void delete_the_fucking_array(void *p) {
      delete [] p;
    }
    

    YES!
    Und das zu weitaus geringeren Kosten als malloc und free... (Wir haben ja schon new)



  • Was ist eigentlich mit get_temporary_buffer und return_temporary_buffer (20.4.3, <memory> )?



  • Original erstellt von Bashar:
    Was ist eigentlich mit get_temporary_buffer und return_temporary_buffer (20.4.3, <memory> )?

    😕 Was ist das? 😃



  • Wenn wir schon bei C sind, dann doch lieber

    #define HERDAMIT(SIZE) ((void*)new(std::nothrow)char[SIZE])
    #define WEGDAMIT(P) {delete[] P;P=NULL;}
    

    Beachte die entscheidenden Verbesserungen:
    -klar lesbare makros
    -konsistente namensgebung
    -nullsetzen des zeigers zur fehlervermeidung
    -keine gefährlichen exceptions, denn die verhindern zu oft, daß man ein fclose(...) noch aufrufen kann

    @Daniel E.: nimm die funktion operator new, um rohen speicher zu holen, dazu ist sie da. klar ist der operator new[] deplatziert und suggeriert ein char-array wo man rohen speicher meint.

    [ Dieser Beitrag wurde am 22.01.2003 um 17:01 Uhr von volkard editiert. ]



  • nim doch einfach

    void * operator new(size_t n); 
    void operator delete(void * p, size_t n);
    

    damit bekommt man auch rohen speicher



  • Original erstellt von Mr. N:
    Und das zu weitaus geringeren Kosten als malloc und free...

    Magst Du erläutern warum?

    Original erstellt von volkard:
    nimm die funktion operator new, um rohen speicher zu holen, dazu ist sie da.

    Die Funktion malloc ist auch Teil von C++ und ist auch dafür da, oder etwa nicht?



  • Original erstellt von Daniel E.:
    Magst Du erläutern warum?

    Gerne. Weil kein Code für malloc eingelinkt werden muss. :p



  • Original erstellt von Mr. N:
    Weil kein Code für malloc eingelinkt werden muss.

    Das ist nirgends garantiert. Malloc ist eine Bibliotheksfunktion der Standardbibliothek, über die der Compiler genau so großes Wissen haben kann, wie über new. Evtl optimiert er das eine in das andere um.



  • Original erstellt von Daniel E.:
    Das ist nirgends garantiert.

    *LOL* Eine Nicht-Garantie ist viel wert.



  • Machen wir lieber Beweis durch Beispiel?

    ~/tmp$ F=t.C; cat $F; c++ $F -O2 -static -o new && c++ $F -O2 -static -o malloc -DBLA=1 && ls -l
    #include <cstdlib>
    
    #if BLA
    #       define ALLOC(x)         (char*)std::malloc(x)
    #       define FREE(x)          std::free(x)
    #else
    #       define ALLOC(x)         new char[x]
    #       define FREE(x)          delete[]x
    #endif
    
    int main (void) {
            char* p = ALLOC(10000);
    
            if (!p) return EXIT_FAILURE;
            p[67] = '\a';
    
            FREE(p);
    }
    total 100
    -rwxr-xr-x  1 de  de  15301 Jan 22 17:32 malloc
    -rwxr-xr-x  1 de  de  82418 Jan 22 17:32 new
    -rw-r--r--  1 de  de    276 Jan 22 17:27 t.C
    /tmp$ c++ -v
    Using builtin specs.
    gcc version 2.95.3 20010315 (release) [FreeBSD]
    


  • Du musst in jedem Fall new auch bneutzen *g*.



  • @Daniel E.
    Sonst bringst du eigentlich immer Argumente, die mich sofort überzeugen. Deine Antwort auf Volkard (bzw. Dimah) finde ich aber äußerst schlapp. Das klingt eher nach "jetzt fällt mir nichts mehr ein, also Blocke ich ab und bleibe bei dem was ich gesagt habe". Ist ja auch überhaupt nicht schlimm, ich wollte mich nur nochmal vergewissern, ob da nicht vielleicht wirklich noch Argumente sind, die ich mir merken kann 🙂



  • *get_temporary_buffer erwähn*



  • hmm..
    mal so nebenbei..
    kann ich den Thread nach "was ist größer? malloc oder new" umbenennen, oder wollen wir nicht nochmal zur allgemeinen Frage (was anderes sollte das eh nicht sein) "Muss ich C vergessen, nur weil ich oop mache?"

    Wenn ich das so zusammenfassen kann, ist also ein Großteil der Meinung, dass wenn OOP dann C++, oder versteh ich das falsch?

    Mal so nebenbei: Ich habe einen Rechner, der 1 Milliarde Operationen pro sekunde macht, eine ganze CD im Hauptspeicher unterbringen kann und fast das 200 - Fache an Plattenplatz hat.
    Ich glaube nicht, dass es bei mir auf 200 KByte ankommt. Und auch die Geschwindigkeit ist nicht unbedingt wichtig.
    Okay, ich werde das nächste mal, wenn ich ein Spiel schreibe auch new verwenden. Allerdings wollt ich hier eure Meinung zum C hören und nicht zur Speicherallozierung..



  • Original erstellt von DocJunioR:
    Mal so nebenbei: Ich habe einen Rechner, der 1 Milliarde Operationen pro sekunde macht, eine ganze CD im Hauptspeicher unterbringen kann und fast das 200 - Fache an Plattenplatz hat.
    Ich glaube nicht, dass es bei mir auf 200 KByte ankommt. Und auch die Geschwindigkeit ist nicht unbedingt wichtig.

    Dann wechsle bitte nach Java und laß uns mit so Fragen in Ruhe.

    Seh ich das falsch, wenn ich nun sage, dass ich auch weiterhin malloc, realloc, printf und scanf benutze und damit noch ne ganze weile hinkomme?

    Hast Du das Interesse, C++ gut zu lernen? Offensichtlich nicht. Dann wechsle bitte nach Java und laß uns mit so Fragen in Ruhe.



  • Original erstellt von Daniel E.:
    **Machen wir lieber Beweis durch Beispiel?
    Würdest Du bitte in den Code dazubauen:
    string s;
    cin>>s;
    cout<<"hallo, "<<s<<endl!
    **

    und dann nochmal messen?


Anmelden zum Antworten