Muss ich, nur weil ich Objekte benutze...

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