C++ oder C

[volkard]

nicht ernst. zum einen zeigt der präfix 'C', daß man den autor nicht ernst nehmen muß. zum anderen sagt mir meine erfahrung, daß übergenaue abbildung der außenwelt jedes projekt tötet. manchmal ist eine zigarre eben nur eine zigarre, oder so.
es ist kein vorteil von C++, daß man statt x=a+b schreriben kann

Ram.getInstance().set("x",Alu::getInstance().add(Ram.getInstance()["a"],Ram.getInstance()["b"]))

[volkard]

CMatt schrieb:

Der so ziehmlich einzige Grund warum in der Hardwareporgrammierung immer noch so viel C verwended wird, ist nicht weils mit C++ nicht geht, sondern einzige und allein, weil C nicht so mit heap-speicher um sich wirf wie C++.

seltsam. ich progge jetzt schon recht lange mit c++, aber daß es irgendeine sprachspezifische speicherplatzverschwendung gäbe, ist mir völlig neu. kannste die belegen?

[hä?]

Ich meinte nur deine Klassenhierarchie.

Ein Advanced Graphics Port ist doch keine Grafikkarte.

[CMatt]

volkard schrieb:

seltsam. ich progge jetzt schon recht lange mit c++, aber daß es irgendeine sprachspezifische speicherplatzverschwendung gäbe, ist mir völlig neu. kannste die belegen?

sprachspezifische speicherplatzverschwendung? Wohl eher sprachen-programiererpezifische speicherplatzverschwendung. Ausser den new operator in all deinen Klassen private zu deklarieren, bleibt dir net viel überig nen begeistersten C++ coder drauf aufmerksahm zu machen, dass hier keine 1Gb RAM drin steckt... Habe das selbe schon hinter mir.. volle freude codeten wir in C++ los ( "schönes' C++, mit new und delete so wie es Herr Stroustroup empfiehlt) und dann, oh welch ein schreck, warum heiraten heap und stack bereits nach 10ms...

[CMatt]

volkard schrieb:

nicht ernst. zum einen zeigt der präfix 'C', daß man den autor nicht ernst nehmen muß. zum anderen sagt mir meine erfahrung, daß übergenaue abbildung der außenwelt jedes projekt tötet. manchmal ist eine zigarre eben nur eine zigarre, oder so.
es ist kein vorteil von C++, daß man statt x=a+b schreriben kann

Ram.getInstance().set("x",Alu::getInstance().add(Ram.getInstance()["a"],Ram.getInstance()["b"]))

in welcher sprache realisiertst du das x=a+b dessen gegenstück in c++

Ram.getInstance().set("x",Alu::getInstance().add(Ram.getInstance()["a"],Ram.getInstance()["b"]))

ist? musst mir zeigen, nehm ich auch.

[volkard]

CMatt schrieb:

in welcher sprache realisiertst du das x=a+b dessen gegenstück in c++

Ram.getInstance().set("x",Alu::getInstance().add(Ram.getInstance()["a"],Ram.getInstance()["b"]))

ist? musst mir zeigen, nehm ich auch.

in c++.
das lange gegenstück passiert nur allzu leicht, wenn man CGraphicProcessor, ne CGraphicCard die von CGraphicProcessor erbt, ne CAGP die von CGraphicCard erbt, und solche perfekten sachen macht.

[volkard]

CMatt schrieb:

Habe das selbe schon hinter mir.. volle freude codeten wir in C++ los ( "schönes' C++, mit new und delete so wie es Herr Stroustroup empfiehlt) und dann, oh welch ein schreck, warum heiraten heap und stack bereits nach 10ms...

tja. kann ich nicht nachvollziehen.

[CMatt]

volkard schrieb:

in c++.
das lange gegenstück passiert nur allzu leicht, wenn man CGraphicProcessor, ne CGraphicCard die von CGraphicProcessor erbt, ne CAGP die von CGraphicCard erbt, und solche perfekten sachen macht.

ich kann dir jetzt leider nicht folgen... ermöglich der einsatz solcher sachen net grad ein x=a+b, ohne solche sachen wärs dann doch ein
int *a = get_variable_adress_form_ram("a");
int *b = get_variable_adress_form_ram("b");
int *x = get_variable_adress_form_ram("x");
.. was den einsatz von c++ überflüssig macht.

[operator void]

CMatt schrieb:

volle freude codeten wir in C++ los ( "schönes' C++, mit new und delete so wie es Herr Stroustroup empfiehlt) und dann, oh welch ein schreck, warum heiraten heap und stack bereits nach 10ms...

Wo empfiehlt Struppi denn den exzessiven Einsatz von new und delete? IMHO sind die Möglichkeiten, in C++ auf dem Stack zu arbeiten, höchstens seit C99s VLAs schlechter...

[CMatt]

C++ verleiet von sich aus dazu. Kein C++ coder quält sich mit nem char-array wenns doch nen std::string gibts, ect...

Und ich bleib dabei! Bei systemen mit mirkrigen speichern fass ich kein C++ mehr an da könnt ihr mich net umstimmen, hab schon einmal wochen damit verbracht code von nen C++ künstler so hinzubiegen das für den stack mehr als 500 Byte überig blieben.. :p

[volkard]

CMatt schrieb:

C++ verleiet von sich aus dazu. Kein C++ coder quält sich mit nem char-array wenns doch nen std::string gibts, ect...

dann erfüllt es mich mit stolz, daß ich die einzige ausnahmen bin.
hab sogar mal code gebaut, der für embedded systems eingesetzt wurde. war ne hashtable für SNMP MIB-entries. also sowas wie "12.3.5.2.3.1.18.3" sollte speicherplatzsparend abgelegt werden und trotzdem schnell im zugriff sein. die offensichtlichen bäume waren unnett. die hashtable kam mit 2*sizeof(short)+sizeof(void*) pro knoten aus, indem ich dem eintrag für "12.3.5.2.3.1.18.3" den hashtableindex von "12.3.5.2.3.1.18" gegeben habe. eindeutiges finden war möglich, es war gar nicht so lahm und wurde wie gesagt eingesetzt. um den speicher hab ich mich nicht gekümmert. ist mir doch egal, ob der anwender nachher sich speicher mit new holt, oder auch mal die table ins rom brennt.
selbstverständlich war das in c++.

[CMatt]

Volkard, ist mir klar das dich c++ nicht daran hindert speicherplatzsparend zu programmieren, aber der dumme druchschnittscoder sieht in C++ als aller erstes mal die schöne große STL und das schöne new,.... All diese dinge verleiten doch sehr. Wenn ich den *.c files auf auge drücke kommt er gar net erst in versuchung mal eben nen schnell nen std::string zu verwenden, gibts net, aus, musst selber machen und da malloc mehr buchstaben sind als [] liegt da ne art krümel-spur richtung stack der nur mehr folgen muss.

[Bashar]

CMatt schrieb:

dumme druchschnittscoder

Ich denke, das schließt die Diskussion ab Eine Entscheidung für eine bestimmte Programmiersprache muss im Kontext getroffen werden.

[kernking]

Könntet ihr langsam mal wieder auf meine ursprüngliche Frage zurückkommen?

[Shade Of Mine]

kernking schrieb:

Könntet ihr langsam mal wieder auf meine ursprüngliche Frage zurückkommen?

Aber natürlich...

Wenn du keinen Sinn in der C++ Programmierung siehst, dann programmiere nicht in C++. Wenn dir C mehr liegt -> was spricht dagegen?

Angenommen ich könnte C richtig gut, kann ich dann andere Programmiersprache schnell lernen?

Kommt darauf an. OO Sprachen wirst du nicht gut lernen können, aber struktuierte vermutlich schon.

C++ ist mir einfach zu viel, viele sachen kommen mir auch endlos kompliziert vor.

Zwei Möglichkeiten:

1. du findest dich damit ab, dass du C++ nicht magst
2. du beschäftigst dich mit C++ und lernst verstehen, dass es uU nicht kompliziert ist

Ich stehe mir auf Hardwareprogrammierung und Socketprogrammierung, da braucht man doch eigentlich gar nicht den ganzen OO Kram? Sehe ich das falsch?

Den 'OO-Kram' braucht man sowieso nicht. Man kommt auch ohne ihn aus. Andersum braucht man aber auch nicht den ganzen 'Strukturierten Kram', man kommt ja auch mit OOP aus

Gerade aber bei Sockets, finde ich OO-Konzepte sehr passend. Aber man kommt auch ohne sie aus