Muss ich, nur weil ich Objekte benutze...
-
.. gleich auf den alten C-Befehlssatz verzichten?
Es gibt Leute, die fragen, dass das C++ - Pendant zu einigen C-Befehlen ist. Auf der anderen Seite wurde mir schon mehrfach angekreidet, dass ich C benutze, wenn ich im C++ - Forum bin. Ist das nicht relativ egal ?
Ich meine, ich hab C lange vor der OOP gemacht und bin gut damit zurecht gekommen. Die ANSI - Befehle funktionieren, weil C eine Teilmenge von C++ ist.
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?cYa
DjR
-
Gefährliches Gebiet, auf das Du Dich hier begibst... warte mal ab, in 8 Stunden wirst Du für diese Aussagen in den Folgethreads geschlachtet.
Grundsätzlich ist es nicht problematisch, wenn Du weiterhin printf & Co verwendest. Du verlierst halt diesbezüglich Typprüfungen und ähnliche Dinge, solange Du Dir darüber bewußt bist kein Problem.
Aufpassen solltest Du allerdings mit malloc - da Du für dyn. Objekte Speicher ohnehin nur mit new anlegen sollst, wäre es sinnvoll auch für andere dyn. Objekte grundsätzlich auf new zu gehen. Und analog delete statt free. Bei malloc werden halt keine Konstruktoren aufgerufen.
Weiterhin ist es eine gute Idee, auf dynamische Arrays im alten C-Still zu verzichten und auf Container der STL auszuweichen, weil Du hier mehr Möglichkeiten (auch bzgl. einer Art realloc) hast.
-
Original erstellt von DocJunioR:
**.. gleich auf den alten C-Befehlssatz verzichten?Es gibt Leute, die fragen, dass das C++ - Pendant zu einigen C-Befehlen ist. Auf der anderen Seite wurde mir schon mehrfach angekreidet, dass ich C benutze, wenn ich im C++ - Forum bin. Ist das nicht relativ egal ?
Ich meine, ich hab C lange vor der OOP gemacht und bin gut damit zurecht gekommen. Die ANSI - Befehle funktionieren, weil C eine Teilmenge von C++ ist.
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?
**Es ist halt so, dass C und C++ Grundsätzlich anders sind, strukturiert VS Objekt Orientiert.
Wenn man jetzt halb strukturiert halb Objekt Orientiert programmiert, dann kommt ein mischmasch raus. Es spricht nichts dagegen C Funktionen zu verwenden, solange sie eben in die Objekt Orientierung hinein passen. Was sie aber oft nicht tun...
-
Hallo,
das schöne an C++ ist, dass man eben nicht auf ein Paradigma festgelegt ist. Und solang man weiß, was man macht, sehe ich auch kein Problem darin mehrere Techniken in ein und dem selben Projekt zu verwenden.Dennoch würde ich auf C-Funktionen verzichten, für die es ein besseres (z.B. in Bezug auf Typsicherheit) C++ Pendant gibt (Bsp: new vs. *alloc).
-
Ob C oder C++ - Programmieren kannst du sowieso nicht.
- so wie ich deine Programme im WinAPI / Spiele/Grafikforum gesehen habe. :p
-
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..
-
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 ?!
-
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]