C zu C++ - Einfacherer Übergang?

Tachyon

Dafür lässt sich leicht etwas bauen:

template<typename Stream, std::ios_base::openmode DefMode>
class ExceptionStreamAdapter : public Stream
{
public:
    ExceptionStreamAdapter( ){ }

    explicit ExceptionStreamAdapter
        ( char const * filename
        , std::ios_base::openmode mode = DefMode)
    {
        exceptions ( std::fstream::eofbit | std::fstream::failbit | std::fstream::badbit );
        open(filename, mode);
    }
};

typedef ExceptionStreamAdapter<std::fstream, std::ios_base::in> eifstream;
typedef ExceptionStreamAdapter<std::fstream, std::ios_base::out> eofstream;

//...

try
{
    eifstream reader("src.dat");
    oifstream writer("tgt.dat");
    copy(reader, writer);

}
catch(std::exception const & e)
{
    std::cerr << e.what() << '\n';
}

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. Ressourcenfreigabe im Fehlerfall bekommt man quasi freihaus. In C muss man für jeden Anwendungsfall alles neu schreiben, je nachdem in welcher Reihenfolge irgendwelche Ressourcen angefordert werden und was mit den Ressourcen passieren soll. Soviel erstmal zum Thema Wiederverwendbarkeit.

Außerdem lassen sich die davon instanziierten Objekte an jeder Stelle verwenden, an der auch andere Streamobjekte verwendet werden dürfen.

Zu guter Letzt sorgen Exceptions und RAII dafür, dass man sich um solche Dinge wie Ressourcenfreigabe nicht mehr kümmern muss.

Aber was rede ich: Die Wissenden wissen das eh schon, und die Indoktrinierten interessieren sich eh nicht für logische Argumente.

berniebutt

Da ist schon vieles sinnvolles und auch einiges weniger sinnvolle gesagt.

Du kommst von C und möchtest C++ ergänzen. Genau das war die Fragestellung für alle C-Programmierer als C++ als Erweiterung hinzu kam. Der Umstieg ging leicht,
weil alles bisherige behalten und man sich mit den neuen Dingen vertraut machen konnte. Hier ein Danke an die Entwickler von C++!

Vorschläge zum Übergang:
1. Die Benutzung der fertigen Stream-Klassen kann schon mal überzeugen.
2. Die Erweiterung von struct nach class ansehen, eigene Klassen schreiben.
3. Überlagerung von Funktionen und Operatoren ansehen.

Damit hast du bereits einen guten Einstieg nach C++. Für mehr bleibt alles offen. Du findest Geschmack und möchtest das mehr vielleicht auch einsetzen.

Leider ist das Für und Wieder von C und C++ hier im Forum ein heisses - oft kontrovers - geführtes Thema. Bitte nicht wieder eine fast religiös erscheinende Auseinandersetzung - hatten wir schon genug!

Mache es einfach wie ich und andere das auch gemacht haben. Dein C-Wissen kann nie schaden oder gar hinderlich sein! :p

berniebutt schrieb:

Vorschläge zum Übergang:
1. Die Benutzung der fertigen Stream-Klassen kann schon mal überzeugen.
2. Die Erweiterung von struct nach class ansehen, eigene Klassen schreiben.
3. Überlagerung von Funktionen und Operatoren ansehen.

4. C vergessen.

Es gibt nichts schlimmeres als einen Mix von C und C++.

namespace invader

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

volkard

namespace invader schrieb:

Aber ich sag jetzt besser nichts mehr dazu

Das glaube ich nicht.

Tachyon

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.

Shade Of Mine

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.

Nexus

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.

*john 0

DEvent schrieb:

Nö, da steht "TODO: Auto generated catch block". Es ist also auf meiner "TODO-Liste".

Todo Listen sind geduldig.

*john 0

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.

namespace invader

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.