C zu C++ - Einfacherer Übergang?

[...]

Welche aufwendig zu lernenden Konzepte und Vorgehensweisen von C sind denn in C++-Code garantiert nicht anzutreffen, so dass ein C++-Programmierer nichts davon wissen muss?

Z.B. die Fehlerbehandlung sollte in etwas größeren C++ Programmen anders gehandhabt werden als in C.

Ich würde die Frage aber anders herum stellen: Welche grundlegenden Konzepte und Vorgehensweisen aus C++ kommen aus C?

Nicht mal die fstreams funktionieren mit dem "Standard" C++ string.

Das verstehe ich ehrlich gesagt auch nicht. Gibt's da eine Erklärung für?

...

[Shade Of Mine]

namespace invader schrieb:

Welche aufwendig zu lernenden Konzepte und Vorgehensweisen von C sind denn in C++-Code garantiert nicht anzutreffen, so dass ein C++-Programmierer nichts davon wissen muss?

Resourcen Management, Fehlerbehandlung, Generizitaet, Schnittstellen Design, Anwendungs Design (Abstraktion)

[Nexus]

namespace invader schrieb:

Welche aufwendig zu lernenden Konzepte und Vorgehensweisen von C sind denn in C++-Code garantiert nicht anzutreffen, so dass ein C++-Programmierer nichts davon wissen muss?

Ich denke, viele Dinge aus dem Alltag. Die bereits genannte Fehlerbehandlung: In C prüfst du viel häufiger Rückgabewerte oder gehst per goto an eine Aufräumstelle am Ende der Funktion. Oder du implementierst Typunterscheidungen über Funktionszeiger, wo C++ler virtuelle Methoden einsetzen. Die Tendenz, in Objekten zu denken, ist in C vielleicht etwas weniger vorhanden. Du benutzt generell weniger Abstraktionsmechanismen und operierst häufiger direkt auf dem Speicher. Typsicherheit hat keinen so hohen Stellenwert wie in C++. Globale Variablen und Makros sind eher anzutreffen.

Aber "garantiert nicht" würde ich nicht sagen, schliesslich gibt es unterschiedliche Codestile. Aber grundsätzlich kann man in C++ auf viele Möglichkeiten aus C verzichten – was nicht heisst, dass man seinen Horizont nicht erweitern darf und C-Mittel strikt vermeiden soll.

ganzeinfach schrieb:

Nicht mal die fstreams funktionieren mit dem "Standard" C++ string.

Nur für den Dateinamen wird ein const char* benötigt (soll aber in C++0x geändert werden). std::string in Dateien schreiben/von Dateien lesen geht ganz gut.

[namespace invader]

Nexus schrieb:

Ich denke, viele Dinge aus dem Alltag. Die bereits genannte Fehlerbehandlung: In C prüfst du viel häufiger Rückgabewerte oder gehst per goto an eine Aufräumstelle am Ende der Funktion. Oder du implementierst Typunterscheidungen über Funktionszeiger, wo C++ler virtuelle Methoden einsetzen. Die Tendenz, in Objekten zu denken, ist in C vielleicht etwas weniger vorhanden. Du benutzt generell weniger Abstraktionsmechanismen und operierst häufiger direkt auf dem Speicher. Typsicherheit hat keinen so hohen Stellenwert wie in C++. Globale Variablen und Makros sind eher anzutreffen.

Trotzdem muss man als C++-Programmierer diese C-Dinge auch beherrschen. Nicht aller C++-Code verwendet durchgängig Exceptions und RAII. Irgendwann wird man mit C-artiger Fehlerbehandlung zu tun haben, sei es, weil man eine C-Bibliothek verwendet. Und wenn dann die Idee, dass Rückgabewerte auch Fehler anzeigen können, oder dass man bestimmte Dinge auch im Fehlerfall noch von Hand aufräumen muss, neu für einen ist, hat man erstmal ein Problem.

Dass man versteht, wie Makros und globale Variablen und das "Arbeiten auf dem Speicher" funktionieren und worauf dabei zu achten ist, ist auch für C++ entscheidend, auch wenn man diese Dinge dort vielleicht weniger aktiv verwendet.

Man wird sich mit diesen C-Mitteln beim Gleich-C++-Lernen nicht schon am Anfang befassen, sondern erst später, aber lernen wird man sie früher oder später so oder so. Dass man C (bzw. den für C++ relevanten Teil von C, was IMHO fast alles ist) mit C++ "gleich mit" lernt (was hier jemand gesagt hat) hört sich so an, als ob man diese Dinge, wenn man die Sprachfeatures und Vorgehensweisen von C++ gelernt hat, ohne zusätzlichen Aufwand ganz von alleine kann, aber das halte ich für Quatsch. Der Aufwand zum Lernen von C und C++ ist der selbe, egal was man zuerst lernt (auch wenn das C in C++ vom Umfang her natürlich nicht so stark ins Gewicht fällt, man vergleiche nur mal die Seitenanzahl von typischen C- und C++-Büchern). Wobei erst C und dann C++ zu lernen IMHO angenehmer und natürlicher ist und den Vorteil hat, dass man C und C++ dann besser auseinanderhalten kann.

[Janjan]

namespace invader schrieb:

Wobei erst C und dann C++ zu lernen IMHO angenehmer und natürlicher ist und den Vorteil hat, dass man C und C++ dann besser auseinanderhalten kann.

Die Realität sieht anders aus. Leute, die zuerst C gelernt haben, mischen C und C++ sehr sehr gerne..

[namespace invader]

Janjan schrieb:

Die Realität sieht anders aus. Leute, die zuerst C gelernt haben, mischen C und C++ sehr sehr gerne..

Das liegt dann aber vielleicht auch daran, dass sie, wenn sie beides können und objektiv vergleichen können und nicht nur in ihrem C++-Buch gelesen haben, dass alles aus C veraltet und möglichst zu vermeiden wäre, _absichtlich_ auf die C-Dinge zurückgreifen, weil sie die besser und für irgendeinen Zweck nützlicher finden. Ob man nun die Operatur-Überladerei der stl bevorzugt oder doch lieber printf, ist nun mal Geschmackssache.

[Janjan]

namespace invader schrieb:

Janjan schrieb:

Die Realität sieht anders aus. Leute, die zuerst C gelernt haben, mischen C und C++ sehr sehr gerne..

Das liegt dann aber vielleicht auch daran, dass sie, wenn sie beides können und objektiv vergleichen können und nicht nur in ihrem C++-Buch gelesen haben, dass alles aus C veraltet und möglichst zu vermeiden wäre, _absichtlich_ auf die C-Dinge zurückgreifen, weil sie die besser und für irgendeinen Zweck nützlicher finden. Ob man nun die Operatur-Überladerei der stl bevorzugt oder doch lieber printf, ist nun mal Geschmackssache.

Das ist definitiv nicht so. Bestes Beispiel sind Makros, die von den "C-Hackern" gerne anstelle einer inline-Funktion benutzt werden.

[h???????????]

Shade Of Mine schrieb:

namespace invader schrieb:

Welche aufwendig zu lernenden Konzepte und Vorgehensweisen von C sind denn in C++-Code garantiert nicht anzutreffen, so dass ein C++-Programmierer nichts davon wissen muss?

Resourcen Management, Fehlerbehandlung, Generizitaet, Schnittstellen Design, Anwendungs Design (Abstraktion)

Warum sollte ein C++-Programmierer nichts davon wissen müssen?

[Shade Of Mine]

namespace invader schrieb:

Trotzdem muss man als C++-Programmierer diese C-Dinge auch beherrschen. Nicht aller C++-Code verwendet durchgängig Exceptions und RAII. Irgendwann wird man mit C-artiger Fehlerbehandlung zu tun haben, sei es, weil man eine C-Bibliothek verwendet. Und wenn dann die Idee, dass Rückgabewerte auch Fehler anzeigen können, oder dass man bestimmte Dinge auch im Fehlerfall noch von Hand aufräumen muss, neu für einen ist, hat man erstmal ein Problem.

Leider falsch.

Auch wenn du fehlerbehandlung über return codes machst, machst du resourcen management nicht über goto sondern über raii.

ich habe links gepostet die deine aussagen widerlegen und die von C und C++ groessen abgesegnet sind. Aber vielleicht bist du einfach schlauer als alle anderen?

C mit Klassen ist eine Krankheit, denn das vereint die Nachteile von C und C++. Das ist es auch was du als C++ zu kennst und kritisierst. Dort hast du nämlich unnötige komplexität und Probleme im resourcen management.

Echter C++ sieht anders aus.

[Nexus]

namespace invader schrieb:

Wobei erst C und dann C++ zu lernen IMHO angenehmer und natürlicher ist und den Vorteil hat, dass man C und C++ dann besser auseinanderhalten kann.

Angenehmer ist wohl Geschmackssache. Wie schon erwähnt scheinen mir die Nachteile aber nicht unbedeutend zu sein:

Nexus schrieb:

Das Problem, wenn man zuerst C lernt, besteht vor allem auch darin, dass der Grossteil des Codes weiterhin funktioniert. Man ist nicht gezwungen, die C++-Äquivalente zu verwenden, weil die C-Mittel immer noch auszureichen scheinen.

Und zumindest im C++-Forum sieht man ab und zu Umsteiger, die sich sehr schwer tun und denken, sie könnten bekannte Dinge ohne Einschränkungen weiterverwenden. Die Gefahr besteht nicht, wenn man direkt mit C++ anfängt. Denn gerade bei einem "C mit Klassen" kann man die beiden Sprachen nicht mehr gut auseinanderhalten.

h??????????? schrieb:

Shade Of Mine schrieb:

Resourcen Management, Fehlerbehandlung, Generizitaet, Schnittstellen Design, Anwendungs Design (Abstraktion)

Warum sollte ein C++-Programmierer nichts davon wissen müssen?

Es geht darum, dass sich die Konzepte beider Sprachen in diesen Punkten unterscheiden, nicht dass C oder C++ keine solchen Konzepte hat.

[veritySeeker]

Jungs, eure Argumente sind wenig stichhaltig:

Janjan schrieb:

Bestes Beispiel sind Makros, die von den "C-Hackern" gerne anstelle einer inline-Funktion benutzt werden.

Viele C-Compiler kennen auch inline-Funktionen. Funktionen in C werden sogar automatisch "ge-inlined", wenn der Compiler dies für erforderlich hält. Außerdem sind Makros nichts schlechtes, wenn man mit ihnen umzugehen versteht. Jedes Teil einer Programmiersprache kann man korrekt gebrauchen oder mißbrauchen.

Shade Of Mine schrieb:

C mit Klassen ist eine Krankheit, denn das vereint die Nachteile von C und C++.

C++ ist C mit Klassen, wenn man von Feinheiten wie Function-Templates mal absieht. Konzepte wie RAII werden in C++ durch Klassen erst möglich.
Oder anders ausgedrückt: Ein C++ Programm ohne Klassen unterscheidet sich kaum von einem C-Programm.

[Nexus]

veritySeeker schrieb:

C++ ist C mit Klassen, wenn man von Feinheiten wie Function-Templates mal absieht.

Genau, Feinheiten wie Templates, Exceptions, Namensräume, Funktions- und Operatorüberladung oder Referenzen, um ein paar zu nennen.

Natürlich sind Klassen ein sehr wichtiges Feature von C++ – aber bei Weitem nicht das einzige, das zu C hinzugefügt wurde. Ohne die restlichen neuen Features schöpft man nur einen kleinen Teil des Potenzials von C++ aus. Bibliotheken wie wxWidgets, die nur sehr eingeschränktes C++ verwenden, ist gut anzusehen, wie sowas herauskommt.

[Dravere]

veritySeeker schrieb:

Viele C-Compiler kennen auch inline-Funktionen. Funktionen in C werden sogar automatisch "ge-inlined", wenn der Compiler dies für erforderlich hält. Außerdem sind Makros nichts schlechtes, wenn man mit ihnen umzugehen versteht. Jedes Teil einer Programmiersprache kann man korrekt gebrauchen oder mißbrauchen.

Auch in C++ entscheidet der Kompiler ganz frei darüber, ob eine Funktion nun "ge-inlined" werden soll oder nicht. Und niemand sagt was gegen Makros, sie können gut eingesetzt werden und sind gerade in C oftmals sehr hilfreich. In C++ kann man aber auf verdammte viele Makros, welche in C verwendet werden, verzichten. Aber die C auf C++ Umsteiger machen dies meistens nicht und man sieht zum Beispiel Dinge wie:

#define MY_CONSTANT 200
// statt
int const MY_CONSTANT = 200;

#define MAX(a, b) ((a) > (b) ? (a) : (b))
// statt
template<typename T>
T max(T const& lhs, T const& rhs)
{
  return lhs > rhs ? lhs : rhs;
}

Das Problem von Makros ist ja, dass es nur eine dumme Textersetzung ist, welche sich überhaupt nicht bewusst ist, über den vorhanden Code. Zum Beispiel interessiert es die Makros überhaupt nicht, was ein Scope ist. Dadurch kann plötzlich riesen Unsinn passieren und man ist sich gar nicht bewusst wieso. Und in C++ definiert man auch nicht immer eindeutige Bezeichner im globalen Namensraum, sondern hat mehrere verschachtelte Namensräume, wodurch die einzelnen Bezeichner für Klassen und Funktionen meistens kurz sind. Und schon kommt es schnell mal zu Probleme mit den Makros. Typisches Beispiel ist dieser Fall:

#include <windows.h> // WinAPI
#include <limits>

int main()
{
  return std::numeric_limits<int>::max();
}

Kompiliert nicht wegen eines tollen C Makros.

Eben weil die Makros so gefährlich sind, sollte man wenn möglich auf sie verzichten. Und in C++ hat man deutlich mehr Möglichkeiten, auf die Makros zu verzichten, also sollte man dies auch tun. Ein C Programmierer fällt aber schnell auf die C Vorgehensweise zurück, weil er daran gewöhnt ist. In C ist das auch absolut in Ordnung, in C++ hätte man aber bessere Möglichkeiten. Die bekannte Macht der Gewohnheit.

veritySeeker schrieb:

Ein C++ Programm ohne Klassen unterscheidet sich kaum von einem C-Programm.

1. Wie willst du bei einem C++ Programm die Klassen wegnehmen und dann vergleichen? Bisschen unsinnige Aussage, nicht?
2. C++ fügt nicht nur Klassen zu C dazu. Das ist eine etwas sehr eingeschränkte Sichtweise.
3. Aber wahrscheinlich willst du sagen, dass man in C++ genau gleich programmiert wie in C einfach mit Klassen und diese Aussage ist definitiv falsch. Schau dir dazu einfach guter C++ und guter C Code an und du wirst sehen, wie sich die Dinge unterscheiden. Weil man eben andere Möglichkeiten hat, geht man die Dinge anders an. Man programmiert nicht prozeduralen Code und wirft den einfach in Klassen rein. Ein C und ein C++ Programm sind meistens völlig unterschiedlich aufgebaut und zwar wirklich grundlegend.

Aber ... irgendwo hat diese Diskussion echt keinen Sinn. Die Unterschiede sind so offensichtlich, es gibt so viel Literatur dazu, welche dies wunderschön aufzeigt, es wurde schon so viel dazu geschrieben (nicht nur in diesem Thread) und es gibt immer noch welche, die es nicht sehen. Gut, wenn man es nicht sehen will, sieht man es nicht. Ich hoffe einfach, dass ihr nie C++ programmieren werdet, da dabei einfach nur scheuslicher, fehleranfälliger und unsauberer C++ Code entstehen wird. Programmiert also bitte weiterhin in C und kommt nicht auf die Idee C++ Code zu erstellen. Ich ärgere mich jedesmal, wenn ich eine schlecht programmierte "C mit Klassen" Bibliothek sehe.

Grüssli

[veritySeeker]

Nexus schrieb:

veritySeeker schrieb:

C++ ist C mit Klassen, wenn man von Feinheiten wie Function-Templates mal absieht.

Genau, Feinheiten wie Templates, Exceptions, Namensräume, Funktions- und Operatorüberladung oder Referenzen, um ein paar zu nennen.

Natürlich, aber Klassen (mit Konstruktoren und Destruktoren) sind das Entscheidende was C++ wirklich von C abhebt. C++ ohne Klassen wäre nichts wert.

Dravere schrieb:

#define MY_CONSTANT 200
// statt
int const MY_CONSTANT = 200;

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

[volkard]

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

[veritySeeker]

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

[Dravere]

veritySeeker schrieb:

C++ ohne Klassen wäre nichts wert.

Java ohne Klassen wäre nichts wert.
C# ohne Klassen wäre nichts wert.
usw.
Was ist dass denn für eine Aussagen? Können es auch auch so machen:
C ohne Zeiger wäre nichts wert.

Klar wenn du ein zentraler Bestandteil der Sprache wegnimmst, ist sie nicht mehr so viel wert! Aber deswegen zu sagen, dass der einzige Unterschied zwischen C und C++ nur die Klassen sind, ist eine ziemlich seltsame Schlussfolgerung, welche ich überhaupt nicht nachvollziehen kann. Sonst könnten wir ja auch sagen, dass der Unterschied zwischen Java, C#, usw. und C nur die Klassen sind, da Java, C#, usw. auch nichts wert sind ohne Klassen...

Grüssli

[volkard]

veritySeeker schrieb:

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

Alles von Dir ist Unsinn. Hier der Versuch, PI in einen enum zu stopfen. enum hat doch nicht den Zweck, const zu ersetzen. Wegcastbarkeit (mit undefiniertem Verhalten) ist auch kein Argument.

[veritySeeker]

volkard schrieb:

veritySeeker schrieb:

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

Alles von Dir ist Unsinn. Hier der Versuch, PI in einen enum zu stopfen. enum hat doch nicht den Zweck, const zu ersetzen. Wegcastbarkeit (mit undefiniertem Verhalten) ist auch kein Argument.

Zugegeben, Pi kann nicht per enum dargestellt werden. Hier hilft tatsächlich nur noch #define. Bevor jetzt jemand mit Typsicherheit kommt: #define M_PI 3.141592653589793238462643 hat einen Typ. Der Dezimalpunkt zeichnet die Konstante eindeutig als "double" aus.

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen. Und ein #define ... Literal, oder enum, wirst Du mit allen Casts der Welt nicht beschreibbar machen können.

Wie wir sehen, hat C++ gegenüber C in puncto Konstanten keine sinnvolle Neuerung gebracht, eher im Gegenteil: C++ hat, wie so oft, ein nichtvorhandenes Problem adressiert und damit eine zusätzliche Fehlermöglichkeit eingeführt, ohne auch nur das Geringste zu verbessern.

[Shade Of Mine]

veritySeeker schrieb:

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen.

Absichtlich Mistbauen kann man immer.
Aber du kannst ein const PI nicht verändern. Darum geht es doch. caste das const halt weg und weise zu - klappt eh nicht.

Genauso ist das mit #define doof:

#define PI 3

int main() {
  cout<<PI;
#undef PI
#define PI 2
  cout<<PI;
}

auch nicht wirklich const. Oder enum?

enum { PI=3; };
int main() {
#define PI 2;
  cout<<PI;
}

Das ist ein NULL Argument. Denn gegen boshaftigkeit kann man sich nicht schützen...