C++ oder doch C ?

[rubricanis]

Ich habe jetzt ca. ein halbes Jahr recht intensiv mit C++11 programmiert, habe einiges ausprobiert und auch angefangen ernsthaft an einem Projekt zu arbeiten. Ich denke ich habe die Grundlagen weitgehend verstanden, was nicht heißt dass da nicht noch eine Menge Lücken sind, vielleicht auch manches nur halb oder falsch verstanden. Mir gefällt an C++ eine ganze Menge: namspaces, smart ptr, exceptions, templates, das threading modell und maches mehr. Auf der anderen Seite bekomme ich zunehmend das Gefühl keine wirkliche Kontrolle über den generierten Code zu haben. Ich sitze oft da und frage mich was der Compiler da eigentlich macht: Welcher Konstruktor es denn ist der jetzt aufgerufen wird, wie gerade diese Ergebnis zustande kommt und u.Ä.m. Sicherlich findet man das dann immer irgendwann heraus, aber die Regeln sind doch sehr komplex, gelegentlich auch recht verwirrend. Und der Compiler scheint manchesmal so etwas wie eine eigene Auffassung der Welt zu haben. Klar, der Compiler hat immer recht, aber ...

Wenn man sich in einen neuen Bereich einarbeitet, hier eine neue Sprache, so bleibt das nicht ohne folgen für einen selbst. War ich Anfangs eher an Abstraktionsmöglichlkeiten interessiert, so stelle ich jetzt fest das ich zunehmend dazu tendiere ganz konkrete Klassen mit recht eng umschriebener Funktionalität zu schreiben. Ausgenommen hiervon sind Container bei denen in C++ nun eimal Templates das Mittel der Wahl sind. Aber auch hier neige ich eher zu Spezialisierung da mich die StdLib an einigen Stellen nicht zufrieden stellt. Hinzu kommt dass sich mein Interesse etwas in Richtung Hardware näherer Programmierung verschiebt was mir bislang eher fremd war.

Kurz und gut: Ich bin am überlegen ob ich nicht wieder auf C zurückgreife auch wenn ich einiges von dem was C++ bietet sicherlich vermissen werde. Mich würde interessieren was ihr hierzu denkt bzw. ob ihr evtl. ähnliche Erfahrungen habt und wie ihr dann damit umgegangen seit.

Peter

 

[darktrym]

Musst/Kannst du denn eines von beiden irgendwie beruflich einsetzen? Wenn nicht, würde ich ganz klar zu keinem von beiden raten. Nimm das, womit du produktiver bist.
Apropos, hab ich schon erwähnt das ich beruflich mit Delphi zutun hab, der alte Kram anno 1999.

 

[Yamagi]

Du wirst auf diese Frage eine Reihe Antworten bekommen und die meisten werden sehr individuell sein. Es gibt dort draußen große C-Fans, glühende C++-Verehrer sowie -Hasser, Unentschlossen und viele mehr. Darktrym sagt es, wobei ich es etwas enger ziehen würde: Nimm die Sprache, mit der du um jeweiligen Projekt produktiver bist.

Aber andererseits leben wir im Jahr 2015. Computer sind wahnsinnig schnell, vielleicht sogar unvorstellbar schnell und sie haben mehr RAM, als man zählen kann. Geschwindigkeit und das letzten Bisschen Speichereffizienz sind in vielen Fällen nicht mehr relevant. Ich würde heute, zumindest wenn es irgendwie möglich ist, immer den einfachen Weg nehmen. Ein schlankes Kernprogramm in C oder C++ schreiben. Es macht den ekligen Kram. Performancerelevante Dinge, die Netzwerkkommunikation und ähnliches. Es integriert einen Sprachinterpreter, die eigentlichen Mengen Code werden in diesem geschrieben. Python, Lua, vielleicht Ruby. Da entwickelt man einfach um ein Vielfaches schneller als in C oder C++, viele dort alltägliche Probleme gibt es erst gar nicht. Daher solltest du die Frage vielleicht gleich anders stellen: "C plus X, C++ plus X oder vielleicht ganz etwas anderes?"

 

[CrimsonKing]

C ist die Variante mit deutlich weniger Overhead. Rein ethisch würde ich zu C raten. Allerdings ist C++ doch deutlich komfortabler..
Warum muss es denn "entweder - oder" sein?

 

[Rakor]

Nunja, ich denke das wichtigste ist, dass du dich in der Sprache wohl fühlen solltest. C++ bietet sehr viele Möglichkeiten, die muss man aber natürlich nicht alle nutzen. Je abstrakter eine Implementierung wird um so schwerer wird sie auch für einen "fremden" sie nachzuvollziehen. Schreibst du allgemeingültige Libs, dann ist es natürlich sehr anzuraten stark zu abstrahieren um deinen Code flexibler nutzen zu können.
Wenn du jedoch spezifische Anwendungen schreibst ist es lediglich von akademischer Schönheit über das notwendige Maß hinaus zu abstrahieren.

Hardwarenah programmieren kann man mit beiden Sprachen, so es sich um halbwegs aktuelle Rechnerhardware handelt (und nicht um irgendwelche µController) sehe ich da keine Probleme.

 

[rubricanis]

Darktrym sagt es, wobei ich es etwas enger ziehen würde: Nimm die Sprache, mit der du um jeweiligen Projekt produktiver bist.

Nein beruflich habe ich mit Programmierung nichts zu tun, ich bin Amateur. Und um Produktivität geht es mir auch nicht. Wenn es mir darum ginge würde ich Erlang benutzen oder Lua + das bißchen C was ich kann, produktiver geht es kaum.

Es ist aber auch nicht so einfach zu sagen um was es mir geht: Irgendeiner der Klassiker hat einmal sinngemäß gesagt "programming languages shape the way we think". Und darum geht es mir wohl, herauszufinden wie es das Denken über eine Sache, über Computer und Prgrammiersprachen verändert. Erst nachdem ich mich mit C++ beschäftigt habe wurde Laufzeiteffizens und Kontrolle des gesammten Prozesses für mich überhaupt erst ein ernsthaftes Thema. Das macht ja auch den Reiz von C++/C aus. sicherlich, auch in Lua, Erlang oder was auch immer denkt man darüber nach, aber eben ganz anders, innerhalb des jeweiligen von der Sprache vorgegebenen Kontextes.

Sorry, zu früh abgeschickt, Fortsetzung folgt...

 

[rubricanis]

Aber andererseits leben wir im Jahr 2015. Computer sind wahnsinnig schnell, vielleicht sogar unvorstellbar schnell und sie haben mehr RAM, als man zählen kann. Geschwindigkeit und das letzten Bisschen Speichereffizienz sind in vielen Fällen nicht mehr relevant.

Das ist einerseits richtig, andererseits kommen zunehmend Energie- und Resourcen schonende Techniken in den Blick. Ich werde das Gefühl nicht los dass unsere heutigen Computer so etwas wie Dinosaurier sind, Millionen von Zeilen für das OS mit vermutlich hunderttausenden von Fehlern die bei der jeweils nächsten Version in Teilen ausgebügelt, zugleich aber andere produziert werden. Die Frage ist ob das Überlebensfähig ist...

Aber auch dieses Thema stellt sich mir erst seitdem ich mich mit C/C++ beschäftige und in Verbidung damit angefangen habe mich für die Implementierung des OS zu interessieren. Das FreeBSD-Buch ist da wirklich instruktiv. Es ist in meinen Augen ein Wunder dass das alles dennoch recht gut funktioniert.

 

[rubricanis]

C ist die Variante mit deutlich weniger Overhead.

Hmm, vermutlich würden dir Compiler-Bauer widersprechen. Das hängt wohl damit zusammen dass Arrays in C eben schlichte Pointer sind und damit kaum zu optimieren. Jedenfalls steht irgendwo bei LLVM das es eine sehr schlechte Idee ist eine Sprache zu implementieren indem man sie nach C übersetzt. Ob das wirklich so ist oder Propaganda, entzieht sich meiner Kenntnis.

Ich vermute mal das ein guter C++ Programmieren (ich bin keiner!) nahezu jeden Overhead eliminieren kann, was aber sicherlich einiges an Arbeit erfordert. Die Frage stellt sich allerdings dann ob man dann nicht besser gleich C verwendet.

Rein ethisch würde ich zu C raten.

Unter dem Gesichtspunkt habe ich mir das noch garnicht angeschaut. Geb mal hierzu einige Stichpunkte.

Warum muss es denn "entweder - oder" sein?

Interessante Frage die ich mir konkret noch nicht gestellt habe. Von C++ nach C ist ja kein Problem, aber wie sieht es umgekehrt aus? Das "namemangling" ist m.E. eines der größten Hüden von C++ hinsichtlich Interoperationalität.

 

[rubricanis]

Wenn du jedoch spezifische Anwendungen schreibst ist es lediglich von akademischer Schönheit über das notwendige Maß hinaus zu abstrahieren.

Ich bezweifele ja das gerade "Schönheit" eine akademische Disziplin ist. In der praktischen Programmierung gibt es da sehr kontroverse Meinungen zu. Ich gehöre zu denen die Schönheit in der Tat für wichtig halten. Manchesmal denke ich Stunden- oder auch Tagelang über den richtigen Namen einer Funktion oder Klasse nach und wenn ich den nicht gefunden habe werde ich das Gefühl nicht los die Sache nicht richtig verstanden oder ausreichend faktorisiert zu haben. Na ja, für einen Profi dürfte das kaum möglich sein, ich kann mir das aber glücklicherweise erlauben.

 

[CrimsonKing]

Jedenfalls steht irgendwo bei LLVM das es eine sehr schlechte Idee ist eine Sprache zu implementieren indem man sie nach C übersetzt. Ob das wirklich so ist oder Propaganda, entzieht sich meiner Kenntnis.

Mir scheint, GCC und LLVM haben unterschiedliche Zielgruppen.

Unter dem Gesichtspunkt habe ich mir das noch garnicht angeschaut. Geb mal hierzu einige Stichpunkte.

Abstrakt dargestellt: C++ ist C für Faulenzer. (Das ist stark vereinfacht, zugegeben.)

 

[rubricanis]

Abstrakt dargestellt: C++ ist C für Faulenzer. (Das ist stark vereinfacht, zugegeben.)

Der ist gut! Aber Faulheit kann man auch als Tugend ansehen ...

 

[-Nuke-]

Was ich an C++ gegenüber C halt "praktischer" finde ist, dass man ziemlich klar definieren kann was eine Methode darf und was nicht. Und auch die Hinweise für den Compiler wo er optimieren kann und wo nicht. Weiterhin mag ich es, dass man Algorithmen gut generisch definieren kann und das dann gleich auf allen Datentypen funktioniert die deine benutzten Operatoren implementieren.

Also zum Beispiel dieses C++14 Beispiel:

auto add(auto a, auto b) {
  return a+b;
};

Klar kann man jetzt sagen: "Da weiß ich ja auf den ersten Blick gar nicht was ich da reinstecken kann", aber das ist halt das tolle an generischen Methoden -> Alles was den Plus-Operator implementiert. Nur mit dem Unterschied, dass dir das im Notfall zur Compilezeit um die Ohren fliegt und nicht erst zu Laufzeit wie bei all den Skriptsprachen.

Bei 08/15 Programmen und Tools merkt man aber schnell die Probleme von C++. Das ganze drum herum. In Python schreibst du einfach Code und führst ihn aus. Dazu hast du eine massiv große Sammlung von Funktionen für fast alles. Und das was im Standardumfang fehlt, holst du dir einfach mit pip.

Bei C++ sitzt man erst mal da und schreibt sich für jede Zielplattform ein Build-Skript, dann muss man noch Abhängigkeiten suchen und entsprechend beim Compilieren mit linken. Denn die Standard-Library von C++ ist halt auch recht dünn im Vergleich zu allen anderen Sprachen. Aber das ist ja auch so gewollt. Für den Rest mag es Boost geben.... aber ist halt Boost, nech?

 

[CrimsonKing]

Das "auto"-Keyword ist m.E. eine der dümmsten Ideen, die je in C++ eingeflossen sind. Starke Typisierung ist klasse, optionale Aufweichung zerstört das Konzept.

 

[-Nuke-]

Das "auto"-Keyword ist m.E. eine der dümmsten Ideen, die je in C++ eingeflossen sind. Starke Typisierung ist klasse, optionale Aufweichung zerstört das Konzept.

Wird dir ja nicht weg genommen. Es erspart dir nur verdammt viel Template-Code, wenn du halt wirklich alles reinstecken willst.

 

[CrimsonKing]

Wenn ich nicht weiß, was reinkommt, dann hab' ich was falsch gemacht.

 

[-Nuke-]

Wenn ich nicht weiß, was reinkommt, dann hab' ich was falsch gemacht.

Wieso? Das ist ja der Sinn von generischen Methoden. Dass sie mit vielen Datentypen funktionieren. Der Anwender deiner Klasse oder Funktion kann dann bestimmen mit was er arbeiten will, ohne, dass er deine ganzen Funktionen kopiert und den Datentyp wechselt. Und das ohne die Einführung eigener Datentypen die dann per Header irgendwo umgewandelt werden.

Das ist zum Beispiel nützlich wenn man die Genauigkeit der Berechnung umstellen will. float vs double und so.

Anderes Beispiel sind die ganzen Pointer-Typen die C++ so bietet.

 

[CrimsonKing]

Bei Berechnungen wüsste ich schon gern, ob ich gerade mit float oder mit double rechne...

 

[-Nuke-]

Bei Berechnungen wüsste ich schon gern, ob ich gerade mit float oder mit double rechne...

Und warum ist das für den Algorithmus wichtig?

Du selbst als Anwender dessen weißt ja mit was du rechnest. Du legst es ja fest.

 

[rubricanis]

Starke Typisierung ist klasse, optionale Aufweichung zerstört das Konzept.

In C verwendet man dann void* und casts, was ist daran besser? Oder aber man schreibt für jede Struktur einen eigenen Container was ja auch nichts anderes ist als das was templates leisten. Wie immer man es dreht und wendet, aus den Problemen typisierter Sprachen kommt man nicht heraus es sei denn man verwendet eine typisierte High-Level Sprache wie ML oder Haskel, - aber dann ist man in einer ganz anderen Welt und muss mit deren Restriktionen und Problemen leben.

Eines dürfte klar sein: In jeder Sprache muss man wissen was man tut, in der einen weniger, in der anderen mehr...

 

[Kamikaze]

C ist die Variante mit deutlich weniger Overhead. Rein ethisch würde ich zu C raten. Allerdings ist C++ doch deutlich komfortabler..
Warum muss es denn "entweder - oder" sein?

Dem würde ich deutlich widersprechen. Das Standardbeispiel ist qsort(3), das im Vergleich zu std::sort() sehr langsam ist. Der Grund ist, das qsort einen Funktionspointer bekommt, dem zur Laufzeit für jeden Vergleich gefolgt werden muss. std::sort() hingegen ist ein Template, das einen Functor übergeben bekommt. Der wird vom Compiler geinlinet. Man spart also nicht nur einem Pointer zu folgen sondern auch das ganze Stack-Gepushe und Gepoppe das mit einem Funktionsaufruf einhergeht und unter C halt mit jedem einzelnen Vergleich passieren muss. Nebenbei sind unter C++ Casts auf void* überflüssig, das heißt std::sort() ist im Gegensatz zu qsort(3) auch noch typsicher.

Das "auto"-Keyword ist m.E. eine der dümmsten Ideen, die je in C++ eingeflossen sind. Starke Typisierung ist klasse, optionale Aufweichung zerstört das Konzept.

Auto ist stark typisiert und weicht gar nichts auf. Kann jedoch deutlich die Lesbarkeit verbessern:

// äquivalent
auto myInstance = MyClass{};
MyClass myInstance{};

// äquivalent
auto myPtr = std::make_unique<MyClass>();
std::unique_ptr<MyClass> myPtr{new MyClass{}};

// äquivalent
for (auto i = std::begin(foo); …
for (std::vector<int>::iterator i = std::begin(foo); …

 

[worldi]

Der Author von ZeroMQ kam zu dem Schluss, dass C++ für seinen Anwendungsfall suboptimal ist:

• Why should I have written ZeroMQ in C, not C++ (part I)
• Why should I have written ZeroMQ in C, not C++ (part II)

 

[goblin]

Im Ernst: es ist total egal.

Ich persönlich neige immer wieder zu C, das ist zwar nervig und umständlich, aber es wird wenigstens auch nicht behauptet der Wahrheit letzter Schluss zu sein.
An C++ nerven mich immer wieder diese 99 %-Features: in 99 % der Fälle klappt alles wunderbar, aber das letzte eine Prozent nervt unglaublich.
Beispiel gefällig? RAII, an sich ein geniales Konzept. Nur muss man Fehler durch Exceptions behandeln, weil Konstruktoren keine Rückgabewerte haben. Und wie behandelt man Fehler, die bei der Ressourcenfreigabe stattfinden? In der Praxis meistens leider garnicht... da wird dann halt das Programm weggeschossen oder so. Ich vermute dass übrigens genau das der Grund dafür ist, dass Google Exceptions und RAII im Allgemeinen im Styleguide verboten hat, zuverlässiger Code ist einfach anstrengend.

Für reine Produktivität würde ich übrigens trotzdem immernoch C++ nehmen, immerhin hab ich damit 99 % der Fälle gut abgedeckt! Und im letzten Prozent jammere ich, wünsche mir C, und arbeite halt damit

 

[rubricanis]

Hi Leute,

zunächst einmal herzlichen Dank für die Diskussion die mir reichlich Stoff zum Nachenken gibt! Insbesondere die Sache mit den Exceptions, die ich z.Z. überall verwende, scheint mir kritisch zu sein da es bei meinem angedachten Projekt nicht akzeptabel ist dass es abstürzt oder in einem undefinierten Zustand verbleibt.

Ich denke ich werde erst einmal das was ich bislang in C++ geschrieben habe in C umsetzen und werde dann sehen wie das läuft und wo die Haken sind.

Peter

 

[Kamikaze]

zunächst einmal herzlichen Dank für die Diskussion die mir reichlich Stoff zum Nachenken gibt! Insbesondere die Sache mit den Exceptions, die ich z.Z. überall verwende, scheint mir kritisch zu sein da es bei meinem angedachten Projekt nicht akzeptabel ist dass es abstürzt oder in einem undefinierten Zustand verbleibt.

Ich finde in den verlinkten Artikeln steht eine Menge Mist. Aber ich habe jetzt nicht den Atem das alles auseinander zu nehmen.

 

[rubricanis]

Ich finde in den verlinkten Artikeln steht eine Menge Mist. Aber ich habe jetzt nicht den Atem das alles auseinander zu nehmen.

Das ist wirklich schade, wäre sehr interessant! Aber vielleicht ein anderes mal, muss ja nicht "alles" sein und breit augewälzt werden. Fehlerbehandlung dürfte allerdings so oder so ein schwieriges Thema sein...

Ich denke es wird kein Fehler sein sich noch in C einzuarbeiten, auf was es dann letztendlch hinausläuft wissen allein die Götter.