Muss ich, nur weil ich Objekte benutze...

[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());

[volkard]

Original erstellt von 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());

**

gutes beispiel für c++.
manchmal ist auch das alte c im vorteil.
man nehme ein bs, das einem die übers netzwerk gesandten daten gibt als int receive(char* buf);, als man hat buf in der hand und die anzahl der gelesenen daten. um dann mit std::string große verarbeitungen zu machen, muß man die substrings alle kopieren (und ::new wird oft aufgerufen). hier kann es schon schneller sein, mal bei c zu bleiben.

kann? fakt ist, daß man hier mit c praktisch immer schneller ist. fakt ist auch, daß man mit c++ noch schneller sein könnte. und daß sich keiner in c++ ne string-lib baut, die auf nicht-eigenem speicher operiert. (oh, trauer. die oft gepriesene wiederverwendbarkeit, das oo-werbe-argument überhaupt, ist irgendwie seifenblasig.)

wir haben in c++ viele jahre damit verloren, die templates zu kapieren. in der zwischenzeit sind uns die java-leute im design um 5 jahre davongelaufen. das ist so peinlich, daß nur noch dumme und unverbesserliche sich ehrlich zu c++ bekennen. wir mit c++ haben das www-geschäft verpaßt. sachen wie php kamen auf, obwohl c++ das viel besser getroffen hätte. ms hat java gecloned und läßt sich zur zeit offen, c++ abzuschießen.
mein aufruf: ok, leute, laßt mal die templates los. mit alexandescus buch sei ein meilenstein gesetzt. mehr mag mit nem c+++ gut sein. um ein c+++ bauen zu können, muß c++ gut kapiert sein, jetzt ran an die offenen sachen. die java-lib erstmal abkupfern. daraus lernen. besser machen. endlich wieder non-standrard-sachen verwenden. compilerbauer, die bestimmte entwurfsmuster in die sprache einbauen durch vermehrten kauf belohnen und so.

was c++ ausmacht, ist das (naja, kleine lüge hier) zero-cost-prinzip und die (und kleine lüge dort) verdammt hohe abstraktion.

(kl hier==c++-compiler benutzen vtbls. sie werden von eiffel-compilern mit bin-bäumen auch gerne mal abgehängt (eher ständig, wie ich höre). ausgerechnet von eiffel abgehängt zu werden, das seit jahren zu wissen, nee, das tut weh!)
(kl dort==die abstraktion hört mit den genormten sprachmitteln reichlich früh auf, neue sind nicht machbar, die viel älteren sprachen lisp oder forth lassen c++ da dreckig alt aussehen, da gibts abstraktion bis zum umfallen, sie lassen c++ wie ne sprache für den massenmarkt aussehen).

soll man in diesem kontext noch strlen() oder so verwenden?
ja, ja, ja, ja!
aus euch kleinen spritzern wird der nachwuchs, der uns mal aus der misere reißen wird. verliert bitte nicht den kontakt zur rumpelnden hardware. ein rennauto mit servolenkung wird nie sinnvoll sein.

nutze immer die c-sachen, wenn sie einfach und schnell sind. falls die c++-sachen lahmer sind, dann bleib bei c. falls nicht, wechsle nach c++ hoch. ich kann dir bestätigen, daß es eigentlich immer geht. manchmal hat man in c++ ne schlechtre implementierung erwischt. hab mir gerade zum testen ne implementierung von cout gebaut, die std::cout um faktor 6 abhängt. kein wunder, daß printf() oft schneller ist. aber das sind so sachen, die nur kurzzeitig ein problem sind. nimm cout, bald machen die compilerbauer was schnelles. im prinzip kann natürlich cout wegen der compilezeitpolymorphie schneller sein. und so auch mit dem rest von c++.

also mal forsch herausgesagt: c++ kann, gute progger vorausgesetzt, c immer einholen und oft überholen, was den speed angeht. die entwicklungszeit ist in c++ eh geringer. und meide die stl, die drückt nicht in der tat das aus, was sache ist, ein container ist nicht wirklich ein iteratorentupel.

[japro]

und meide die stl, die drückt nicht in der tat das aus, was sache ist, ein container ist nicht wirklich ein iteratorentupel.

*heul* wem soll ich jetzt glauben???
muss ich mir jetzt ne eigene lib bauen???

[Volker]

Volkard bist du jetzt C++ untreu geworden?

[Gerard]

Original erstellt von volkard:
**ms hat java gecloned und läßt sich zur zeit offen, c++ abzuschießen.
**

ms hat bei msvc 2003 viel arbeit in den iso-c++ compiler gesteckt, vielleicht ist es nur ein versucht die iso-c++ leute für .NET zu gewinnen (in msvc 2003 soll ja beides leicht mixbar sein)

Original erstellt von volkard:
**(kl hier==c++-compiler benutzen vtbls. sie werden von eiffel-compilern mit bin-bäumen auch gerne mal abgehängt (eher ständig, wie ich höre). ausgerechnet von eiffel abgehängt zu werden, das seit jahren zu wissen, nee, das tut weh!)
**

zeig mir ein punkt im standard wo gesagt wird das man virtuele methoden über vtbls implementieren muss?
oder gibt da etwas was vtbls vorraussetzt?

Original erstellt von volkard:
**hab mir gerade zum testen ne implementierung von cout gebaut, die std::cout um faktor 6 abhängt.
**

auch mit etwas vergleichbaren wie streambuf? (der möglichkeit die ausgabe auf etwas anderes umzuleiten)

Original erstellt von volkard:
und meide die stl, die drückt nicht in der tat das aus, was sache ist, ein container ist nicht wirklich ein iteratorentupel.

wenn ich wüste was du mit iteratorentupel meinst könne ich bestimt was dazu sagen

[HumeSikkins]

*heul* wem soll ich jetzt glauben???

Meine bescheidene Meinung dazu: Hör immer auf Volkard, es sei denn es geht um die STL. Zum ersten Halbsatz muss ich wohl nicht viel schreiben. Zum zweiten komme ich, da Volkards Abneigung gegen die STL in meinen Augen eine reine Bauchsache ist. Bauchsachen sind häufig gut. Sich aber nur auf die Bäuche fremder Menschen zu verlassen bringt einen nicht weiter.

und meide die stl, die drückt nicht in der tat das aus, was sache ist, ein container ist nicht wirklich ein iteratorentupel.

Die Aussage ist in meinen Augen geprägt von Oberflächlichkeit. Die STL behauptet nicht, dass ein Container ein Iteratortupel ist. Kein STL Experte dieser Welt (inklusive der Macher der STL) behauptet ein Container wäre auf ein Iteratortupel reduzierbar und damit austauschbar. Auch in der STL haben unterschiedliche Container unterschiedliche Eigenschaften und auch hier sollte man vorher wissen, was man braucht. Die STL bietet lediglich eine Sicht auf ein Iteratortupel und damit eine sehr elegante Möglichkeit Container mit Algorithmen zu verbinden. Diese Sicht ist eine Abstraktion (also eine Vereinfachung) die in vielen Situationen sinn macht. Diese Abstraktion ist aber nicht das Original und damit (wie jede Abstraktion) nicht immer für das Original ersetzbar. Auch die STL ist nicht die lange gesuchte "silver bullet".

Mein Tipp: Lerne die STL. Lese gute Bücher über die STL (z.B. Scott Meyers: "Effective STL"). Verstehe die STL. Erst dann ist es in meinen Augen ok auf Volkards Bauchgefühl zu hören oder eine eigene Containerlib zu schreiben.