Muss ich, nur weil ich Objekte benutze...

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*

DocJunioR

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

volkard

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.

volkard

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?

volkard

Original erstellt von Daniel E.:
Die Funktion malloc ist auch Teil von C++ und ist auch dafür da, oder etwa nicht?

Ja.
Je nach Programmierstil sollte new oder malloc besser sein. Programmierst Du objektorientiert, sollte new besser sein. Betreibst Du weiter C und magst weder Klassen noch Methoden, dann dürfte malloc besser sein. Es dürfte nicht sinnvoll sein, new und malloc zu mischen.
malloc sollte gut auf die Bedürfnisse von C-Programmierern optimiert sein. Insbesondere heißt das, öfters mal nen Puffer von 4096 Bytes holen, aber wer sich kleineres als sagen wir mal 256 holt, der ist sicher kein guter C-Progger, der darf lange brauchen. Und new C++ sollte für die kleinen sehr fix sein, wobei allerdings konstante Kosten auf die größeren allokierungen gelegt werden. Evtl nur 3 Takte für ein if(size<256) goto smallAlloc, aber da sind die mehrkosten und die deutlich schnellere Behandlung kleiner Objekte. Denn in C++ ist es üblich, sich von ner Factory polymorphe Objekte in den Freispeicher klopfen zu lassen, und große Objekte sind meist schlechtes Design, also hat new kleine Objekte gut zu schaffen.

Ja, du kannst jetzt nen historischen Compiler ausgraben, der new für kleine Objekte nicht schnell schafft oder einen, bei dem die Old-School-Programmierer benachteiligt werden. Ich hab nur beschrieben, wie es sein sollte. Auch im Standard stehen diese Folgerungen nicht.

DocJunioR

Original erstellt von volkard:
[quote]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.**[/QUOTE]

Das finde ich ehrlich gesagt etwas unfreundlich von dir.

Es geht mir hier nicht darum, was ich gerne programmiere. Ich hab eine allgemeine Frage gestellt (okay, ich habe mich als Beispiel eingesetzt)
Ich programmiere nicht erst seit gestern - und schon garnicht nur C/C++. Ich will nicht behaupten, dass ich C/C++ vollständig beherrsche, aber das tut hier niemand. (zumindest kann mir das keiner erzählen. Es gibt immer Sachen, die man besser kann und welche, mit denen man seine Probleme hat. )

Was mich momentan einfach stört ist, dass ihr schonwieder Funktionsorgien zusammenschreibt, wo es doch eigentlich nur um die Frage geht, ob man die C-spezifischen Funktionen vergessen muss, nur weil man Klassen bastelt. NICHTS WEITER!!

Java ist im übrigen keine Programmiersprache, die ich programmieren will. Ich habe mit C angefangen, weil dies eine Programmiersprache ist, die trotz 3. Generation sehr nahe an der Maschine ist. Ich möchte gerne selber unter Kontrolle halten, was mit der Maschine passiert. Des weiteren möchte ich keine Programmiersprache benutzen, die nichts weiter tut, als das System auszubremsen und das nur, damit sie theoretisch überall laufen kann.. auch wenn sie dort nie eingesetzt wird.

Warum artet eigentlich ein Thema, das mal so zur Diskussion gedacht ist immer in Beleidigungen, irrelevanten Seitenthemen und der Selbsthochhaltung der jeweiligen (un-)kenntnisse aus?
Ich hab schon mehrfach in zig Threads gesagt, dsas ich nicht alles kann - und auch nicht können muss.
Allerdings bin ich
A) kein Berufsprogrammierer, sondern Administrator
liegen meine Stärken eher in der Algorithmik und Planung.
C) kann ich keine dummen Bemerkungen auf Fragen gebrauchen - so, wie ich auch keine loslasse.

Was meinst Du eigentlich mit C++ gut lernen??
Ich benutze nicht den gesamten Funktionsumfang. Wenn man's genau nimmt tu' ich auch nichts weiter, als weitestgehend objektorientiertes C zu schreiben - und bin bis jetzt auch ganz gut damit gefahren.

Zuletzt noch eine kurze Entschuldigung in Richtung volkard: Sorry, das war jetzt nicht alles auf Dich bezogen. Das ganze hing mir schon ne Weile im Hals rum und Dein Post hab ich einfach mal als Ausgangpunkt genommen, um das mal zu sagen. Nimm's mir nicht zu krumm

cYa
DjR

volkard

Original erstellt von DocJunioR:
Was meinst Du eigentlich mit C++ gut lernen??
Ich benutze nicht den gesamten Funktionsumfang. Wenn man's genau nimmt tu' ich auch nichts weiter, als weitestgehend objektorientiertes C zu schreiben - und bin bis jetzt auch ganz gut damit gefahren.

Ich sehe das mal so:
Dir ist aufgefallen, daß Du zwar in die OO eingestiegen bist, aber recht wenige der geilen C++-Tricks verwendest.
Die ist aufgefallen, daß da evtl was nicht stimmt.
Deine Meinung steht eigentlich schon fest, daß Du das wie bisher in Ordnung finden willst.
Aber zur Sicherheit fragste mal nach.
Jemand kommt mit dem malloc-Argument.
Jemand widerlegt das malloc-Argument.
Du sagst "laßt mich mit malloc in Ruhe".
Ich wunder mich, denn das malloc-Argument war eins, daß bei Nichtwiderlegung Tür und Tor geöffnet hätte.
Du kommst mit "Mein Rechner ist groß und schnell, ich brauch gar keine Performance".
Mir klingt das nach ner Vorbereitung, jedewedes Argument, was Dir nicht paßt, in ähnlicher Weise abzuwenden.
"new ist schneller" -> brauch keine Performance
"ostream ist sicherer" -> "brauch keine sicherheit"
"templates sind praktisch" -> "bin ja nicht faul"
"makros sind gefährlich" -> "nicht, wenn man aufpaßt"
Das alles wird aber nie Kern des echten Grundes sein, weshalb Du endlich von malloc und printf weg sollst.
Lern einfach C++. Also so C++, wie ich es fein finde. Ich sag, daß es sich lohnt. Nimm das hin oder laß es. Wenn du es läßt, dann lern Java, selbst mit Java wärste produktiver als mit altem C++.
Es ist schrecklich, daß Du gar nicht siehst, wie schlimm printf ist.
Irgendwie hab ich das Gefühl, in dieser Diskussion wurde bereits alles gesagt, das nicht auf taube Ohren stoßen wird. Daher waren meine unhöflichen Äußerungen auch final gemeint.

DocJunioR

Hmm..
okay. zumindest hab ich jetzt verstanden, worauf Du hinaus wolltest.

Ich meinte nicht, dass ich keine Performance brauchte. Ich meinte nur, dass mich 200 kb bei einem Programm mehr oder weniger nicht umbringen werden.
Gut, ich gestehe, dass ich nicht unbedingt die Lust verspüre, mich in sämtliche C++ - Funktionen einzuarbeiten - never change a running system - oder besser, wenn ich eine Funktion brauch, werde ich sie benutzen. Ansonsten bleib ich eben beim gleichen Umfang.
Das mit "zur Sicherheit mal nachfragen" muss ich verneinen. Ich wollte eigentlich nur mal wissen, wie ihr das seht. Das ist so ne dumme Angewohnheit von mir. Ich interessiere mich sehr für die Meinung anderer, mache aber trotzdem immer mein eigenes Ding. Was aber nicht bedeutet, dass ich keine ratschläge annehme. Allerdings muss ich dazu sagen, dass ich den Ratschlag mit java grundsätzlich erstmal ignoriere Ich bin C'ler (der wie gesagt, auch Klassen benutzt)
Okay, in letzter Zeit arbeite ich schon immer mehr mit Klassen und mit der Zeit baue ich immer neue C++ - Teile ein. Aber ich werde wahrscheinlich immer irgendwelche alten funktionen drin haben.

so wie ich das jetzt mirbekommen habe, meint der Großteil von euch, dass es sich eher lohnen würde, den kompletten C++ - Funktionsumfang zu nutzen.
Im Endeffekt hat nur marc++us gemeint, dass es - solange ich damit klar komme - auch kein Problem ist, die alten Funktionen zu nutzen. (was nicht heißt, dass er es auch so machen würde)

Ich denke, dass man das so als Abschluß stehen lassen sollte. - wer was gegen diesen Schluß hat, soll das melden.

cYa
DjR

Daniel E.

Original erstellt von HumeSikkins:
ich wollte mich nur nochmal vergewissern, ob da nicht vielleicht wirklich noch Argumente sind, die ich mir merken kann

Eher nicht. Es scheint ziemlich egal zu sein.

Übrigends Danke :).

Original erstellt von Bashar:
*get_temporary_buffer erwähn*

Es muss nicht soviel Speicher reservieren, wie ich angefordert hab', oder? Welchen Sinn ergäbe sonst der Rückgabewert der Größe des angegebenen Speicherbereichs?

volkard: Gerne:

-rwxr-xr-x  1 de  de  191227 Jan 23 16:35 malloc
-rwxr-xr-x  1 de  de  191227 Jan 23 16:35 new
-rw-r--r--  1 de  de     388 Jan 23 16:35 t.C

[Da sieht man mal wunderbar, was string und die iostream-Bibliothek für ein Bloat ist, btw ;).]

new hat sicherlich einige Vorteile, aber 'dann wird das Programm viel kleiner' ist keiner. Die Vorteile sind mehr für den Leser ersichtlich (kein 'p || die ("Out of memory");'[1]). Im Zusammenhang mit Objekten sowieso.

[1]: Perl ruiniert den Programmierstil ;).

Lars

so ein quatsch. Warum dass denn?
warum nicht einfach:

size_t nBytesToAlloc = 1024;
void* pBuffer = ::operator new(nBytesToAlloc);

/€: als ich das geschrieben hab hatte ich die erste Seite gelesen

[ Dieser Beitrag wurde am 23.01.2003 um 19:02 Uhr von Lars editiert. ]

Helium

nur mal so am Rande: Ich käme mit printf überhaupt nicht mehr klar, weil ich überwiegend eigene Objekte an Streams schicke. Und da ist das C++-system doch Klar im vorteil:

std::cout << mein_objekt;

vs. sowas wie

printf("%d %s %f", mein_objekt.get_attribut_1(), mein_objekt.get_attribut_2(), mein_objekt.get_attribut_3());