C++ oder C

Hi, ich programmiere seid 3 Monaten in C++, also ich finde die Sprache ja ziemlich gut und so weiter, aber irgendwie finde ich das man in C (ja ich weiss, was in C geht, geht auch (teilweise?) in C++) mehr machen kann.
Ich meine mal abgesehen davon findet man total viel Codebeispiele unter Unix,
alleine die binutils (heißen die jetzt anders?), wo so sachen wie wc, ls...
enthalten sind und alle mit code, da lernt man doch viel. Programmiert ihr in C oder C++, oder sind eure C++ Programme C Programme? Wenn ich wieder zu C zurückkehren würde, hätte ich Angst irgendwie was zu versäumen...ich weiss halt nur noch nicht was. Angenommen ich könnte C richtig gut, kann ich dann andere Programmiersprache schnell lernen? Ist C wirklich veraltet, ich meine bald kommt ja n neuer Standard. C++ ist mir einfach zu viel, viele sachen kommen mir auch endlos kompliziert vor. Ich stehe mir auf Hardwareprogrammierung und Socketprogrammierung, da braucht man doch eigentlich gar nicht den ganzen OO Kram? Sehe ich das falsch?

Alexander88

Also, ich setze auf das gute alte C. C++ liegt mir einfach nicht und ich will es auch nicht lernen. C Forever!

Helium

Hi, ich programmiere seid 3 Monaten in C++, also ich finde die Sprache ja ziemlich gut und so weiter, aber irgendwie finde ich das man in C (ja ich weiss, was in C geht, geht auch (teilweise?) in C++) mehr machen kann.

LOL!!! Mach mal ein Beispiel.

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

Die meisten Mainstreamsprachen sin OO. Also nein.

Ist C wirklich veraltet, ich meine bald kommt ja n neuer Standard.

Nein der kam 99.

Shady

aber irgendwie finde ich das man in C (ja ich weiss, was in C geht, geht auch (teilweise?) in C++) mehr machen kann.

C++ kann im Prinzip alles was C kann (weshalb die Aussage auch blödsinnig ist )

Ich selber hab früher auch fast nur C-Techniken verwendet, aber mittlerweile verwend ich sehr gern den "ganzen OO Kram".
Wenn du Schwierigkeiten hast polymorphie und sowas zu verstehen , hilft es dir vielleicht auch eine leichte OO-Sprache wie Java zu lernen und dann wieder auf C++ umzusteigen(war bei mir so)

c++eus

Oder kaufe dir das Buch: http://www.c-plusplus.net/titelanzeige.php?ISBN=3826629841
Objektorientierte Programmierung für Dummies | ISBN: 3826629841

Artchi

Damals als ich noch Assembler programmiert habe, habe ich auch nicht verstanden was ich denn mit C++ soll. Ja, es kam mir auch alles sinnlos vor, dieser ganze OO-Kram. Ich habe mich gesträubt, obwohl ich mir freiwillig ein C++-Einsteigerbuch reingezogen habe.

Heute würde ich sagen, ich sah darin keinen Sinn, weil ich es nicht verstanden habe! Dabei ging es nicht mal um die Syntax oder sowas, sondern wirklich um das OO-Prinzip. DAS ist der Punkt!

Aber seit dem Moment, an dem es bei mir "klick" gemacht hat und ich OO verstanden habe (das war von einem Moment auf den anderen!), habe ich nur gesagt "Boh, das ist ja echt genial!!!". Heute kann ich garnicht mehr ohne OO.

Wie mein Beispiel und auch das vieler andere hier zeigt, ist es wirklich nicht so einfach umzudenken. Denn es ist ein Umdenken! Und wenn man dann auch noch die neue Syntax von C++ lernen muß, kann es einen schon erschlagen. Das ist ganz normal.

Natürlich kann man auch alle Probleme mit C oder Assembler lösen, aber C++ und andere OO-Sprachen bieten einem ein Werkzeug, mit dem man viel schneller und "schöner" ans Ziel kommt.

Aber ich kann dir nur sagen: alle anderen haben es auch verstanden, dann wirst du es auch irgendwann verstehen. Du mußt aber vorurteilslos an die Sache rangehen. Wenn du schon eine Abneigung hast, obwohl du es noch nicht mal verstanden hast, dann wird das natürlich nie was!

CMatt

Was hindert dich daran in C++ hardwarenah zu programmieren?? Dafür eignet sich C++ sogar hervorragend, da du den Aufbau deiner Hardwarekomponenten fast 1:1 als Objekte nachbilden kannst. Da gibts nen CGraphicProcessor, ne CGraphicCard die von CGraphicProcessor erbt, ne CAGP die von CGraphicCard erbt, .... besser gehts doch nimmer.
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++. Auf nem Controller mit 128kb RAM wirds schwer mit C++, da du zusätzlich zum normalen stack noch nen heap unterbringeng musst und dann wirds knapp.
Auf nen system wo genügend Speicher vorhanden ist und wo mehr als 500 codezeilen laufen sollen wäre es nonsens C zu verwenden (meine meinung...)

Da gibts nen CGraphicProcessor, ne CGraphicCard die von CGraphicProcessor erbt, ne CAGP die von CGraphicCard erbt

das ist ja wohl nicht dein ernst.

CMatt

hä? schrieb:

Da gibts nen CGraphicProcessor, ne CGraphicCard die von CGraphicProcessor erbt, ne CAGP die von CGraphicCard erbt

das ist ja wohl nicht dein ernst.

Das war ein beispiel...
Aber für dich noch eins..
Du hast ein System mit nem Board auf dem ein Prozessor und ein paar chips sind, nen LCD display und ne kleiner tastatur. In C artet das ziehmlich leicht in ein totales chaos aus wenn man net sehr strukturiert programmiert. In C++ hast die möglichkeit ne CDisplay klasse zu bauen, die ne PrintString oder PaintSimlie methode hat. Diese Display klasse erbt von ner CLCDHardawre klasse, welche die hardware steuerung übernimmt und klassen wie CInputDriver, CGraphicProcessor, CLuminancePWM, .... bündelt.
Aber wers net verstehen WILL verstehts halt net..

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?

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.