Muss ich, nur weil ich Objekte benutze...

[BTW]

Ob C oder C++ - Programmieren kannst du sowieso nicht. - so wie ich deine Programme im WinAPI / Spiele/Grafikforum gesehen habe. :p

[DocJunioR]

Danke BTW!
Achso. Ich lasse mich übrigens von niemandem blöd anmachen, der zu feige ist, sich dazu anzumelden. Ich kenne übrigens meine Stärken und Schwächen ziemlich genau. (WinAPI ist keine Stärke meinerseits)

Ich benutze new natürlich immer, wenn es möglich ist. Wenn es aber darum geht, Speicher zu allozieren, benutze ich eben am liebsten die *alloc's
Okay, eigentlich hat windows da auch schon wieder sein HeapAlloc, etc. allerdings hat sich da bei mir immer irgendwie das Rückenmark gekräuselt, weil ich am liebsten so arbeite, dass ich Module nur an bestimmten Stellen ändern muss, wenn sich das OS ändert..

[nep]

Original erstellt von DocJunioR:
**
Ich benutze new natürlich immer, wenn es möglich ist. Wenn es aber darum geht, Speicher zu allozieren, benutze ich eben am liebsten die *alloc's
**

öh ist das nicht ein kleiner widerspruch ?!

[DocJunioR]

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. ]

[Mr. N]

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

Wozu diese Inkonsistenz?

[PeterTheMaster]

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.

[Daniel E.]

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.

[Mr. N]

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)

[Bashar]

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

[Mr. N]

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

Was ist das?

[volkard]

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. ]

[Gerard]

nim doch einfach

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

damit bekommt man auch rohen speicher

[Daniel E.]

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?

[Mr. N]

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

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

[Daniel E.]

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.

[Mr. N]

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

*LOL* Eine Nicht-Garantie ist viel wert.

[Daniel E.]

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]

[Mr. N]

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

[HumeSikkins]

@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

[Bashar]

*get_temporary_buffer erwähn*