C zu C++ - Einfacherer Übergang?
-
Tachyon schrieb:
Auf den ersten Blick hat man bei beiden Lösungen (C und C++) vielleicht etwa gleich viel Code. Den Aufwand für den Adapter hat man jedoch nur einmal.
Er bedeutet aber noch mehr Code Obfuscation. Denn jemand, der den Code verstehen oder reparieren will, wird erstmal dazu gezwungen, nachzugucken was die beiden typedefs sollen und dann die Klasse zu verstehen, und dann auch noch zu verstehen, was das Setzen der exception-Bits dann später im Rest des Codes bewirkt. Die einfache Logik, die im C-Programm sofort nachvollziehbar ist, ist bei der c++-Fassung weit verteilt und versteckt. In der Regel ist die Zeit, die zum Eintippen eines Stücks Code benötigt wird, nur ein Bruchteil der Zeit, die später zum Lesen, Verstehen, Debuggen und Ändern aufgebracht wird. Und da sind die von C++-Fanatikern propagierte Template-Orgien kontraproduktiv.
Abgesehen davon ist ein ein Armutszeugnis für C++, dass man trotz des gewaltigen Sprachumfangs trotzdem noch ständig einen Haufen Wrapper schreiben soll. Und das nicht nur für "alte" C-Bibliotheken, sondern auch für die STL selbst!
Und wieso lässt du eigentlich bei eof eine Exception werfen? Das mag sinnvoll sein, wenn man einen bestimmten Dateiinhalt erwarten kann, aber in dem Fall hier (Dateien Kopieren) führt es im besten Fall dazu, dass jedes mal mit einer ineffizienten Exception abgebrochen wird, im schlimmsten Fall wird das Ende der Datei unterschlagen.
Das könnte man natürlich leicht reparieren, aber dieser Fehler macht ein grundlegendes Problem unnötiger, selbstgebastelter Abstraktionen deutlich: Sie passen nicht so einfach auf alle Fälle. Und wenn man sie falsch verwendet, sind sie oft wesentlich schwerer zu debuggen. Soviel zum Thema Wiederverwendbarkeit.
Aber ich sag jetzt besser nichts mehr dazu, denn das bringt ohnehin nichts, solange die C++-Gläubigen hier nur am Thema vorbeidiskutieren, Argumente nicht verstehen und mit Unkenntnis- und Doppelmoral-Vorwürfen oder sonstwas um sich werfen wollen (oder einfach nur rumtrollen).
-
namespace invader schrieb:
Aber ich sag jetzt besser nichts mehr dazu
Das glaube ich nicht.
-
namespace invader schrieb:
[...]Und wieso lässt du eigentlich bei eof eine Exception werfen? Das mag sinnvoll sein, wenn man einen bestimmten Dateiinhalt erwarten kann, aber in dem Fall hier (Dateien Kopieren) führt es im besten Fall dazu, dass jedes mal mit einer ineffizienten Exception abgebrochen wird, im schlimmsten Fall wird das Ende der Datei unterschlagen.[...]
Eigentlich zeigt das nur, dass Du, wie ich bereits andeutete, keine Ahnung hast, wovon zu redest.
namespace invader schrieb:
[...schwall...]Aber ich sag jetzt besser nichts mehr dazu, denn das bringt ohnehin nichts, solange die C++-Gläubigen hier nur am Thema vorbeidiskutieren, Argumente nicht verstehen und mit Unkenntnis- und Doppelmoral-Vorwürfen oder sonstwas um sich werfen wollen (oder einfach nur rumtrollen).
Ist schon klar. Dein erster Post in diesem Thread zeigt ja schon, dass Du im höchsten Maße objektiv und unvoreingenommen bist. Auch wertende Aussagen benutzt Du so gut wie gar nicht.
Auch weiß natürlich nur ein C-Programmierer, was die Standardbibliothek tut. Ein C++-Programmierer hat hingegen keine Ahnung. Deshalb weiss er auch nicht, was bei den Standard-Streams die Exceptionbits bewirken.
Wie gut, dass Du ganz ohne Doppelmoral auskommst.
Es ist natürlich auch eine unglaubliche Obfuscation, ein Stück Code zu schreiben das überall wiederverwendet werden kann. Auch die Möglichkeit, Fehler immer auf die selbe Art behandeln zu können, erhöht die Unübersichtlichkeit nur.
Besser und klarer ist es natürlich, an möglichst vielen Stellen im Code eigene Fehlerbehandlungsroutinen zu schreiben. Noch besser mit möglichst viel Codewiederholung.
Auch schmeißen die Firmen gerne Unmengen an Geld mit unproduktivem C++-Code raus. Es geht ja schließlich nicht darum, möglichst kostengünstig Software zu produzieren, sondern nur darum, möglichst "kuhl" und "obfuscated" zu sein.
-
namespace invader schrieb:
Er bedeutet aber noch mehr Code Obfuscation.
dh du machst nicht gerne funktionen für wiederkehrende Probleme?
weil das ja obfuskation ist wenn es die funktion
save_settings()
gibt.
da lieber händisch jedesmal alle Daten korrekt in die settings datei speichern...das ist diese tolle doppel moral.
-
namespace invader schrieb:
Aber ich sag jetzt besser nichts mehr dazu, denn das bringt ohnehin nichts, solange die C++-Gläubigen hier nur am Thema vorbeidiskutieren, Argumente nicht verstehen [...]
Äh ja. Du hast nicht mehr auf unsere letzten Gegenargumente reagiert, sondern weichst erneut auf ein allgemeines C++-Bashing aus, weil dir nichts Konkretes mehr einfällt.
-
Warum reagiert ihr überhaupt auf namespace invader? Er ist ein Troll. Mehr nicht.
-
Cabanossi schrieb:
Ich hätte nur eine kurze Frage, undzwar hatte ich mir vorgenommen mich vorerst in C einzuarbeiten, und dann in ferner Zukunft, falls nötig, auf C++ umzusteigen. Würde mir der Übergang mit C Kentinssen leichter fallen als direkt C++ zu lernen, oder ist mein ganzer Plan im Prinzip Mist?
Ja, Dein Plan ist Mist.
Wenn Du C kannst, brauchst Du C++ nicht mehr.
Aber Du könntest danach C#, Java oder PHP lernen. Für den Einstig in diese drei Sprachen sind Kenntnisse der C-Syntax sicherlich sehr hilfreich.
-
CodingJoe schrieb:
Cabanossi schrieb:
Ich hätte nur eine kurze Frage, undzwar hatte ich mir vorgenommen mich vorerst in C einzuarbeiten, und dann in ferner Zukunft, falls nötig, auf C++ umzusteigen. Würde mir der Übergang mit C Kentinssen leichter fallen als direkt C++ zu lernen, oder ist mein ganzer Plan im Prinzip Mist?
Ja, Dein Plan ist Mist.
Wenn Du C kannst, brauchst Du C++ nicht mehr.
Aber Du könntest danach C#, Java oder PHP lernen. Für den Einstig in diese drei Sprachen sind Kenntnisse der C-Syntax sicherlich sehr hilfreich.Und wenn du C++ kannst, brauchst du C nicht mehr. Und hast dazu deutlich bequemere Möglichkeit Code zu schreiben.
Generischer Code in C ist eine Qual.
-
namespace invader schrieb:
C++ zu lernen, ohne vorher C zu können, dürfte umständlich, verwirrend und nicht zu empfehlen sein, einfach weil C++ keine in sich gut durchdachte, schöne Sprache ist, sondern der eher missglückte Versuch, alle möglichen nicht zueinander passenden Sprachfeatures in C einzubauen.
Wenn ich mal all das entferne, was für mich nach Flame-Bait bzw Vorurteile aussieht, bleibt folgendes übrig: "Ich glaube, dass es besser ist, vor C++ die Sprache C zu lernen, weil C++ auf C basiert und Sprachfeatures hinzufügt."
Dem kann man folgendes entgegensetzen: Zitat aus alt.comp.lang.learn.c-c++.FAQ:
19: Should I learn C before learning C++?
According to a number of C++ experts, including its creator Bjarne Stroustrup, and Marshall Cline (the author of the C++ FAQ), the answer is a firm no.
Look up the C++ FAQ to see why Cline thinks you do not need to learn C before C++. A post by Bjarne Stroustrup to comp.lang.c++ addresses this point too.
"Learning Standard C++ as a New Language" - a paper by Stroustrup available from http://www.research.att.com/~bs/papers.html - examines this much-debated issue in great depth, but the paper is aimed more at educators than at beginners.
namespace invader schrieb:
Wenn man schon C beherrscht, kann man C++ so halbwegs verstehen (soweit das überhaupt möglich ist), weil man dann die notwendigen unschönen Kompromisse zumindest noch nachvollziehen kann.
Je nach Definition für "verstehen". Dabei sollte es nicht darum gehen, die Regeln um jedes Feature zu kennen. Wichtig ist, dass man damit auch etwas anzufangen weiß. Du beschreibst C++ als lose Sammlung von schlecht zusammenpassenden Features. Eine Erklärung dafür wäre, dass Du C++ "nicht verstanden" hättest. Eine andere wäre, dass Du übertrieben hättest. Ich schätze, es ist mindestens ein bischen was von beiden.
namespace invader schrieb:
Am besten lernst du erstmal C, das ist ein guter Anfang,
Ich bin mir da nicht so sicher, ob es das "beste" ist. Zumindest kann man sich mal bei den Experten schlau machen.
-
DEvent schrieb:
Nö, da steht "TODO: Auto generated catch block". Es ist also auf meiner "TODO-Liste".
Todo Listen sind geduldig.
-
namespace invader schrieb:
Aber ich gebe ja zu, dass die Frage, was schöner, eleganter Code ist und wann man welchen schreiben sollte, subjektiv ist und auf eine Grundsatzdiskussion hinausläuft.
Einige Grundvoraussetzungen gibt es: zum Beispiel komplette Fehlerbehandlung. In vielen C Projekten fehlt diese und wird durch exit(EXIT_FAILURE) oder kurzer Hand abort() gelöst, und das Problem teilt C (z.B. Fortran) mit vielen anderen Sprachen ohne Exception-Handling.
-
krümelkacker schrieb:
Je nach Definition für "verstehen". Dabei sollte es nicht darum gehen, die Regeln um jedes Feature zu kennen.
Was aber essentiell wichtig ist, um C++ anzuwenden.
krümelkacker schrieb:
Du beschreibst C++ als lose Sammlung von schlecht zusammenpassenden Features. Eine Erklärung dafür wäre, dass Du C++ "nicht verstanden" hättest.
Eine weitere Erklärung wäre, daß zu der Zeit, zu der C++ entwickelt wurde, verzweifelt ein Weg aus der Software-Krise gesucht wurde. So hat man einfach C um wahllose Features erweitert. Ein Indiz für dieses chaotische Vorgehen ist IMHO, daß erste viele Jahre später C++ Techniken erfunden wurden, an die der Erfinder der Sprache nicht im Traum dachte.
krümelkacker schrieb:
Eine andere wäre, dass Du übertrieben hättest. Ich schätze, es ist mindestens ein bischen was von beiden.
Ein Funke Wahrheit steckt in allem davon. C++ kann besser sein als sein Ruf, aber das liegt vermutlich nur daran, daß sich haufenweise Enthusiasten darauf gestürzt haben, von deren Erkenntnissen wir alle zehren. Nachteil ist, daß C++ nur echten Könnern sein Potential offenbart. Dem Durchschnittsprogrammierer erscheint C++ als das, was es wirklich ist: ein willkürlicher Mix aus Erweiterungen, die C aufgestülpt wurden und vor deren korrekter Anwendung die Götter viel Erfahrung und eine schmerzliche Lehrzeit mit vielen Rückschlägen gesetzt haben.
-
ich denke c++ hätte viel mehr erfolg wenn man nicht versucht hätte es mit c zu mischen. dadurch entstehen sachen die a unschön und b verwirrend sind.
lg lolo
-
noobLolo schrieb:
ich denke c++ hätte viel mehr erfolg wenn man nicht versucht hätte es mit c zu mischen.
Dann wäre es wahrscheinlich so "erfolgreich" wie D. C++ hat ganz sicher stark davon profitiert, dass es die alten C Libraries verwenden konnte.
-
30.Spieltag schrieb:
noobLolo schrieb:
ich denke c++ hätte viel mehr erfolg wenn man nicht versucht hätte es mit c zu mischen.
Dann wäre es wahrscheinlich so "erfolgreich" wie D. C++ hat ganz sicher stark davon profitiert, dass es die alten C Libraries verwenden konnte.
Damals != Heute.
-
Oh, endlich wieder beim Thema zurück.
krümelkacker schrieb:
Wenn ich mal all das entferne, was für mich nach Flame-Bait bzw Vorurteile aussieht,
Na ich gebe ja zu, dass vielleicht etwas von meiner subjektiven Abneigung gegen C++ darin eingeflossen ist. Es es kann ja keiner ahnen, dass hier so viele C++-Fans lauern, die gleich so gereizt darauf reagieren...
bleibt folgendes übrig: "Ich glaube, dass es besser ist, vor C++ die Sprache C zu lernen, weil C++ auf C basiert und Sprachfeatures hinzufügt."
Ja genau. Zumindest dann, wenn man vorhat, beides zu lernen; und erst recht, wenn man (wie der OP) noch gar nicht weiß, ob man überhaupt auch C++ lernen will.
Wenn es vor allem darum geht, nur C++ zu lernen, und man von C wirklich nichts wissen will, kann man natürlich auch gleich C++ lernen. Darauf bezieht sich dein Zitat, wobei ich das auch nicht für ganz objektiv halte, es kommt ja von C++-Enthusiasten. Trotzdem halte ich das gleich-C++-lernen für keine gute Idee, denn
1. ist nicht so richtig einzusehen, warum jemand nur C++ und absolut nicht C lernen will (auch wenn C++-Fanatiker natürlich der Meinung sein werden, dass C++ ja die allerbeste Sprache überhaupt ist und man keine andere Sprache mehr braucht, sobald man C++ kann). C ist letztendlich "Grundwissen" und auch einfach und klein genug, um es relativ schnell zu lernen. Und wenn man anschließend C++ lernt, wird man das meiste von C ohnehin noch brauchen.
2. enthält C++ nunmal viele "alte" Sprachbestandteile aus C, es ist nicht aus einem Guss und enthält viele redundante Features. Also z.B. sowohl Pointer als auch Referenzen für Call-by-Reference, der Präprozessor denn man dann doch nicht nutzen soll, C-Strings und stl Strings, Strukturen und Klassen, malloc und new, und überhaupt die ganze C-Standardbibliothek und die stl, die genau das selbe macht. Wenn man C++ lernt, ohne C zu kennen, verwirrt einen das alles, weil man nicht nachvollziehen kann, was diese ganzen doppelten Features sollen und was sich die Sprachdesigner dabei gedacht haben. Lernen muss man sie trotzdem, denn man wird ja C++-Programmen begegnen, die sie verwenden. Schlimmstenfalls wird man sich angewöhnen, die aus C übernommen Features zu nutzen und nicht die passenden C++-Features, die sie eigentlich ersetzen sollen, einfach weil man nicht versteht, dass das nur die "Altlasten" von C sind, die nur aus Kompatibilitätsgründen in der Sprache sind.
Je nach Definition für "verstehen". Dabei sollte es nicht darum gehen, die Regeln um jedes Feature zu kennen. Wichtig ist, dass man damit auch etwas anzufangen weiß.
Ersteinmal geht es beim Lernen einer Sprache aber darum, die Sprachfeatures genau zu verstehen. Was man damit anfangen kann, sollte einem halbwegs intelligenten Menschen selbst klar werden, ggf. mit ein paar kleinen Denkanstößen.
Zumindest bei einer gut designten Sprache. Dass man die Unmengen von Features von C++, die teilweise auch noch redundant und unnötig kompliziert sind, als Anfänger gar nicht alle wirklich verstehen kann und damit gezwungen ist, die Benutzung der Sprachfeatures, also Herangehensweisen usw., in Form von den ganzen "C++ Idioms" zu erlernen und die dahinter verwendeten Sprachfeatures erst nach und nach zu verstehen, ist ein C++-spezifisches Problem.
In Endeffekt geht es aber darum, die Sprachfeatures zu verstehen. Und dabei hilfreich sind C-Kenntnisse einerseits, weil man dann die aus C übernommen Teile schonmal versteht, und andererseits, weil man, wenn man die Unzulänglichkeiten und Beschränkungen von C kennt, besser die Motivation der C++-Designer nachvollziehen und die dabei herausgekommen C++-Features besser verstehen kann.
Du beschreibst C++ als lose Sammlung von schlecht zusammenpassenden Features. Eine Erklärung dafür wäre, dass Du C++ "nicht verstanden" hättest. Eine andere wäre, dass Du übertrieben hättest.
Eine dritte Erklärung wäre, dass ich recht habe
-
namespace invader schrieb:
Und wenn man anschließend C++ lernt, wird man das meiste von C ohnehin noch brauchen.
Nein. Wenn man C++ richtig lernt, braucht man C nicht mehr.
namespace invader schrieb:
Schlimmstenfalls wird man sich angewöhnen, die aus C übernommen Features zu nutzen und nicht die passenden C++-Features, die sie eigentlich ersetzen sollen, einfach weil man nicht versteht, dass das nur die "Altlasten" von C sind, die nur aus Kompatibilitätsgründen in der Sprache sind.
Genau das passiert, wenn man zuerst C lernt. Wenn man gleich vernünftig C++ lernt, dann weiß man was man zu benutzen hat.
Structure und class sind übrigens nicht redundant, sondern lässt sich wunderbar für semantische Zwecke nutzen.
-
'typsicher zur Compile-Zeit' und 'objektorientiert' sind eben zwei Eigenschaften, die schlecht unter einen Hut zu bringen sind. Vor allem, wenn im Interesse des vollen Hardware-Zugriffs noch ein explizites Zeigerkonzept zu berücksichtigen ist.
Unverwässerte OO - "alles ist ein Objekt", einschließlich Code, Blöcke, Klassen - erfordert einen Grad an Selbstreflexion und somit an Formbarkeit des Systems zur Laufzeit, der wo mit statischer Typisierung schwer vereinbar ist.
Es sei denn, man läßt so weitreichend Teilaspekte der OO außen vor, daß man die verbleibende Rest-OO auf syntaktischer Ebene simulieren kann: "namespace feature".
Dann wird's erfahrungsgemäß syntaktisch kompliziert, weil man Laufzeit-Eigenschaften des Systems schon zur Compilezeit voraussagen muß. Stichwort Typ-Sicherheit zur Compile-Zeit.
-
namespace invader schrieb:
1. ist nicht so richtig einzusehen, warum jemand nur C++ und absolut nicht C lernen will
Aus dem selben Grund warum ich Visual Basic .NET lernen will ohne vorher Visual Basic 6 gelernt zu haben. Weil sie eben nicht nur unterschiedliche Sprachen sind, sondern auch unterschiedliche Denkweisen verlangen.
Bei der Programmierung geht es doch zu einem grossen Teil nur um Denkweisen. Wenn man Java programmiert muss man in Java denken, wenn man C programmiert muss man in C denken. Warum sollte ich nun lernen wie ich in C denke wenn ich garnicht in C programmieren will?
Und wenn man anschließend C++ lernt, wird man das meiste von C ohnehin noch brauchen.
Nur dass dann so Sachen wie RAII wie du ja an dir selber siehst problematisch werden.
2. enthält C++ nunmal viele "alte" Sprachbestandteile aus C, es ist nicht aus einem Guss und enthält viele redundante Features. Also z.B. sowohl Pointer als auch Referenzen für Call-by-Reference,
Diese Features sind nicht redundant. Aber ja C++ enthaelt eine Menge features - nur warum ist es wichtig zuerst die Untermenge zu lernen und dann einen Teil davon zu vergessen und dann die richtige Menge zu lernen?
zB Fehlerbehandlung in C, generizitaet ueber void* und makros, makros statt inline templates - eben eine komplett andere Denkweise -> wozu das lernen um es wieder zu vergessen?
Wenn man C++ lernt, ohne C zu kennen, verwirrt einen das alles, weil man nicht nachvollziehen kann, was diese ganzen doppelten Features sollen und was sich die Sprachdesigner dabei gedacht haben.
Deine private Meinung die leider unhaltbar ist. Da schon millionen Leute C++ ohne C vorkenntnisse gelernt haben und nicht verwirrt waren.
Zumindest bei einer gut designten Sprache. Dass man die Unmengen von Features von C++, die teilweise auch noch redundant und unnötig kompliziert sind, als Anfänger gar nicht alle wirklich verstehen kann und damit gezwungen ist, die Benutzung der Sprachfeatures, also Herangehensweisen usw., in Form von den ganzen "C++ Idioms" zu erlernen und die dahinter verwendeten Sprachfeatures erst nach und nach zu verstehen, ist ein C++-spezifisches Problem.
Nein. Man lernt immer Idiome. Idiome sind die anfassbaren Teile der Denkweise.
while(*trg++=*src++);Das ist ein Idiom in C dass jeder kennen muss. Genauso ist RAII ein Idiom in C++ das jeder kennen muss. Idiome sind die Ausdruecke der Denkweise.
Und dabei hilfreich sind C-Kenntnisse einerseits, weil man dann die aus C übernommen Teile schonmal versteht, und andererseits, weil man, wenn man die Unzulänglichkeiten und Beschränkungen von C kennt, besser die Motivation der C++-Designer nachvollziehen und die dabei herausgekommen C++-Features besser verstehen kann.
Und das alles ohne Smalltalk Kenntnisse? Wie soll man die C++ features ohne smalltalk verstehen? Oder Java ohne C?
Das macht keinen Sinn. Eine Sprache wird von vielen Seiten beeinflusst, es macht vielleicht aus akademischer Sicht Sinn alle Einfluesse genau zu kennen, aber aus pragmatischer Sicht sind die vollkommen uninteressant.
Lehre mal Leuten die C++ lernen wollen zuerst die Denkweise von C und dann die von C++ und schau was rauskommt. Du kannst das wunderschoen hier im Forum bestaunen. Naja, das Problem wird sein, dass du den Unterschied halt nicht verstehst, aber das Resultat ist dann eben ein C mit Klassen. Nur C mit Klassen ist eine Katastrophe.
Aus dem Naehkaestchen geplaudert:
Mein Tutorial ist zwar schon recht alt aber ich habe immer wieder unterhaltungen mit Leuten die es lesen um C++ zu lernen. Und da hat sich fuer mich klar rauskristallisiert (wie eben im Forum auch) dass C zuerst zu lernen eine schlechte Idee.Diese Meinung teilen uebrigens auch alle C++ groessen
Siehe zB: http://www2.research.att.com/~bs/learn.html
Oder auch die offizielle FAQ von alt.comp.lang.learn.c-c++: http://www.faqs.org/faqs/C-faq/learn/
Und bedenke, diese Meinung haben Leute die sowohl C als auch C++ sehr gut kennen, waehrend du nur C gut kennst und ueber C++ nur mutmassungen anstellst.Wem soll man mehr vertrauen?
-
und wie erklärt man das Öffnen eines Files in C++ ohne auf C-Spezialitäten wie char* zurückzugreifen ?
myIfstream.open(myFileName.c_str(),...)c_str() ist dann eine Methode, die einen string ... verzaubert
