Erst C oder gleich C++ ???

Kenner der Wahrheit schrieb:

Auch kein Wunder, da ihr ein und die selbe Person seid!

es ist absolut nicht vorstellbar, dass auch andere eine ähnliche meinung haben, ne? aber hey, so schnell wird man mal wieder zum sündenbock erklärt, dabei hab' ich nur meine zustimmung zu einer ziemlich eindeutigen äusserung gegeben.

_matze

JustAnotherNoob schrieb:

Sagmal fricky, was machst du eigentlich in diesem Forum? Ich kann mich nicht erinnern von dir jemals einen sinnvollen Beitrag gelesen zu haben - soll heißen einen anderen Beitrag als "C++ ist Mist" gelesen zu haben.
Eine ziemlich traurige Forenexistenz..

Wie wärs, wenn du mal mehr als 3 Beiträge in diesem Forum liest? Denn mehr können es nicht gewesen sein, wenn du zu einer solchen Aussage kommst...

wie "es gibt keine Vorzüge von C++" ??

C++ war die erste Sprache, die

Sprachkompatibilität mit C und gleichzeitig
OO-Features ohne zwingenden Verlust an Performance
bot. Damit ist C++ nach wie vor mit erste Wahl für Resourcenkritische größere Projekte.

Wenn man natürlich C++ benutzt, um ein GUI mit 3 Knöpfen für ein Kommandozeilentool zu schreiben oder einen Terminkalender, und sich dann wundert, daß die Programmierung zeitaufwendig und überkompliziert ist, hat man wohl die falsche Sprache ausgewählt - so etwas geht mit Tcl/Tk oder Python mit weniger als 100 Zeilen und in einem Bruchteil der Zeit.

u_ser-l schrieb:

Damit ist C++ nach wie vor mit erste Wahl für Resourcenkritische größere Projekte.

klar, wenn alle team-mitglieder mindestens 10 jahre programmiererfahrung und einen IQ von wenigstens 170 haben.

namespace invader

u_ser-l schrieb:

Sprachkompatibilität mit C und gleichzeitig

Von "Sprachkompatibilität" zu sprechen halte ich für übertrieben. Siehe http://yosefk.com/c++fqa/picture.html#fqa-6.11

OO-Features ohne zwingenden Verlust an Performance
bot. Damit ist C++ nach wie vor mit erste Wahl für Resourcenkritische größere Projekte.

Je mehr von den vermeintlichen Vorzügen von C++ man tatsächlich nutzt, desto größer wird der Performanceverlust. Die erste Wahl für ressourcenkritische Projekte ist nach wie vor C. Und auch für größere Projekte ist C nicht ungeeigneter als C++. Eher im Gegenteil.

audacia

namespace invader schrieb:

Von "Sprachkompatibilität" zu sprechen halte ich für übertrieben. Siehe http://yosefk.com/c++fqa/picture.html#fqa-6.11

Theorie != Praxis. Und in der Praxis läßt sich fast sämtlicher existenter C-Code auch mit einem C++-Compiler übersetzen, vielleicht mit geringfügigen Anpassungen beispielsweise im Header.

namespace invader schrieb:

Je mehr von den vermeintlichen Vorzügen von C++ man tatsächlich nutzt, desto größer wird der Performanceverlust. Die erste Wahl für ressourcenkritische Projekte ist nach wie vor C.

Der Schluß ist vorschnell. C++ bietet die Flexibilität, einerseits eine Anwendung auf höherem Abstraktionsniveau zu konstruieren, andererseits aber bei der Implementierung der Algorithmen ganz nach Bedarf im C-Stil zu programmieren. (Natürlich ist das nicht auf C++ beschränkt; in Delphi geht das genauso, und teilweise sogar in C#. Aber das Einbinden von C-Code ist eben in C++ um Längen einfacher.)

Shade Of Mine

namespace invader schrieb:

u_ser-l schrieb:

Sprachkompatibilität mit C und gleichzeitig

Von "Sprachkompatibilität" zu sprechen halte ich für übertrieben. Siehe http://yosefk.com/c++fqa/picture.html#fqa-6.11

Die kompatibilität ist gegeben: du kannst C und C++ in einem Projekt mixen. Das reicht. Du brauchst die kompatibilität nicht in einer source datei...

Je mehr von den vermeintlichen Vorzügen von C++ man tatsächlich nutzt, desto größer wird der Performanceverlust. Die erste Wahl für ressourcenkritische Projekte ist nach wie vor C. Und auch für größere Projekte ist C nicht ungeeigneter als C++. Eher im Gegenteil.

C++ hat das Zero Cost Principle.
Sag mir etwas wo du in C schneller bist und das selbe erreichst wie in C++ und ich zeige dir schlechten C++ Code.

asc

Shade Of Mine schrieb:

Sag mir etwas wo du in C schneller bist und das selbe erreichst wie in C++ und ich zeige dir schlechten C++ Code.

Es gibt schon Dinge in C++ die im ersten Moment Laufzeiteinbußen mit sich bringen, beispielsweise:
* Exceptions
* RTTI

Im Gegenzug lässt sich natürlich darüber streiten ob dies wirklich Zeit kostet (wenn ich mir den Mehraufwand anschaue, den man ohne diese Features hätte).

Shade Of Mine

asc schrieb:

Es gibt schon Dinge in C++ die im ersten Moment Laufzeiteinbußen mit sich bringen, beispielsweise:
* Exceptions
* RTTI

Ah, und RTTI und Exceptions in C sind schneller als in C++?

Shade Of Mine schrieb:

C++ hat das Zero Cost Principle.

nirgends gibt's was geschenkt. c++ macht da auch keine ausnahme.

Shade Of Mine schrieb:

Ah, und RTTI und Exceptions in C sind schneller als in C++?

möglicherweise ja, weil man sich eigene, speziell zurechtgeschnittene implementationen machen kann, falls man sowas braucht. aber das geht mit c++ natürlich auch, wenn die eingebauten mechanismen zu langsam sind.

Shade Of Mine

~fricky schrieb:

Shade Of Mine schrieb:

C++ hat das Zero Cost Principle.

nirgends gibt's was geschenkt. c++ macht da auch keine ausnahme.

Habe ich nie behauptet dass es etwas geschenkt gibt.
weißt du was das zero cost principle aussagt?
du zahlst nur für das was du brauchst.

wenn ich bunds checking bei arrays will, *PENG* kann ich haben. wenn ich es nicht brauche *PENG* hab ichs nicht.

Shade Of Mine schrieb:

Ah, und RTTI und Exceptions in C sind schneller als in C++?

möglicherweise ja, weil man sich eigene, speziell zurechtgeschnittene implementationen machen kann, falls man sowas braucht. aber das geht mit c++ natürlich auch, wenn die eingebauten mechanismen zu langsam sind.

exakt. wenn ich kein RTTI brauche sondern nur simples typen aus einer liste erkennen, dann kann ich das in c++ genauso machen wie in C.

namespace invader schrieb:

Je mehr von den vermeintlichen Vorzügen von C++ man tatsächlich nutzt, desto größer wird der Performanceverlust. Die erste Wahl für ressourcenkritische Projekte ist nach wie vor C. Und auch für größere Projekte ist C nicht ungeeigneter als C++. Eher im Gegenteil.

in der Tat, man verliert etwas an Performance, wenn man bspw. Datentypen mit bounds check anstelle von arrays mit fester Größe verwendet, oder Klassen definiert, wo es auch eine C-struct mit manueller Konstruktion/Destruktion tun würde, oft sind ein Prozent Tempoverlust den Gewinn an Sicherheit gegen Speicherzugriffsfehler und den Gewinn an Wartbarkeit aber wert.

Mit die erste Wahl für resourcenkritische Projekte ab einer bestimmten Größenordnung ist nach wie vor C++ -- vor allem dann, wenn zu erwarten ist, daß sich die Spezifikation zukünftig ändern kann oder nicht alle Einzelheiten gleich am Anfang implementiert werden können, in solchen Fällen kann die OO-Programmiermethodik durch von Anfang an erzwungene Datenkapselung und "Interface-isierung" ihre Stärken voll ausspielen.

daß man eine Steuerung für einen 2K uController nicht mit C++ zu schreiben braucht, ebensowenig wie ein simples GUI oder ein Backup-Skript, braucht man nicht zu diskutieren. Dafür gibt's besser geeignete Sprachen.

namespace invader

Shade Of Mine schrieb:

du zahlst nur für das was du brauchst.

Und was mache ich, wenn ich mich dagegen entschieden habe, Exceptions zu verwenden, und dann in einem Konstruktur einen Fehler melden will? Es ist ja nicht so dass ich einfach NULL zurückgeben kann...

Abgesehen davon ist das Herauspicken von bestimmten Features nicht das, was ich mir unter der eleganten Nutzung einer Programmiersprache vorstelle. Aber bei den ganzen redundanten und teilweise unbrauchbaren Features von C++ geht es ja nicht anders.

Badestrand

namespace invader schrieb:

Und was mache ich, wenn ich mich dagegen entschieden habe, Exceptions zu verwenden, und dann in einem Konstruktur einen Fehler melden will?

Du hast das Zero Cost Principle wohl nicht ganz verstanden. Egal ob du Exceptions verwendest oder nicht und ob du sie einsetzt oder nicht - du bezahlst für das Exception-Handling nur/erst, wenn eine Exception real geworfen wird. Nochmal deutlich: Wenn keine Exception geworfen wird, bezahlst du auch nichts für's Exception-Handling.
In der Praxis ist es leider nicht ganz so, aber immerhin fast.

namespace invader schrieb:

Abgesehen davon ist das Herauspicken von bestimmten Features nicht das, was ich mir unter der eleganten Nutzung einer Programmiersprache vorstelle.

Du pickst dir auch nicht einfach was raus, von wegen Klassen verwendest du und Exceptions nicht und so weiter, sondern programmierst so vor dich hin, dass guter Code bei rauskommt. Und die Dinge, die du in deinem Code nicht verwendest, bezahlst du eben auch nicht. Z.B. bringt Polymorphie durch die Virtual Tables kleinen (winzigen) Overhead mit. Den hast du aber nicht, wenn du keine virtuellen Methoden verwendest (und zwar weil du sie nicht brauchst, nicht aus Prinzip o.Ä.). Und das meint Shade wohl mit "du zahlst nur für das was du brauchst.".

edit: Umformulierung.

namespace invader

u_ser-l schrieb:

oft sind ein Prozent Tempoverlust den Gewinn an Sicherheit gegen Speicherzugriffsfehler und den Gewinn an Wartbarkeit aber wert.

Sicherheit vor Speicherzugriffsfehlern gibt es in C++ genausowenig wie in C, eben weil die "unsicheren" Möglichkeiten immernoch zur Verfügung stehen. Natürlich kann man sie an bestimmten Stellen durch geeignete Container vermeiden, aber dann passieren die Fehler eben irgendwo anders, wo man sie nicht erwartet hat.

in solchen Fällen kann die OO-Programmiermethodik durch von Anfang an erzwungene Datenkapselung und "Interface-isierung" ihre Stärken voll ausspielen.

Gerade die Kapselung ist wohl kaum eine Stärke von C++, mit seinen privaten Membern in Header-Dateien. Das geht sogar in C besser (natürlich nicht "erzwungen", aber keine Programmiersprache kann verhindern, dass der Programmierer Unsinn treibt).

Dafür gibt's besser geeignete Sprachen.

Irgendwie gibt es für alles besser geeignete Sprachen als C++

Shade Of Mine

namespace invader schrieb:

Und was mache ich, wenn ich mich dagegen entschieden habe, Exceptions zu verwenden, und dann in einem Konstruktur einen Fehler melden will? Es ist ja nicht so dass ich einfach NULL zurückgeben kann...

Schau dir mal fstream an.

Abgesehen davon ist das Herauspicken von bestimmten Features nicht das, was ich mir unter der eleganten Nutzung einer Programmiersprache vorstelle. Aber bei den ganzen redundanten und teilweise unbrauchbaren Features von C++ geht es ja nicht anders.

willst du ernsthaft diskutieren oder nur trollen?

der punkt in c++ ist, dass du für ein feature nicht zahlst dass du nicht verwendest. in python zahlst du immer die ducktyping kosten und in java zahlst du immer die vtable kosten - egal ob du diese features nutzt oder nicht.

in c++ zahlst du nix wenn du feature X nicht brauchst. du willst keine exception verwenden, kein problem: wenn du sie nicht verwendest zahlst du nichtmal die kosten für die exception infrastruktur.

Shade Of Mine

namespace invader schrieb:

Sicherheit vor Speicherzugriffsfehlern gibt es in C++ genausowenig wie in C, eben weil die "unsicheren" Möglichkeiten immernoch zur Verfügung stehen. Natürlich kann man sie an bestimmten Stellen durch geeignete Container vermeiden, aber dann passieren die Fehler eben irgendwo anders, wo man sie nicht erwartet hat.

machiavelli versus murphy
c++ schützt vor murphy und vor machiavelli schützt dich niemand.

Gerade die Kapselung ist wohl kaum eine Stärke von C++, mit seinen privaten Membern in Header-Dateien. Das geht sogar in C besser (natürlich nicht "erzwungen", aber keine Programmiersprache kann verhindern, dass der Programmierer Unsinn treibt).

pimpl
aber das ist wieder ein machiavelli vs murphy problem.

Irgendwie gibt es für alles besser geeignete Sprachen als C++

natürlich. dsl -> domain specific language
es gibt auch für alles bessere sprachen als python, java, lisp,...

namespace invader schrieb:

Sicherheit vor Speicherzugriffsfehlern gibt es in C++ genausowenig wie in C, eben weil die "unsicheren" Möglichkeiten immernoch zur Verfügung stehen.

und nicht nur das. selbst die c++-eigenen möglichkeiten, also die, die nicht durch C eingeschleust wurden, bergen so viele fallstricke, dass es für einen mittelmässigen programmierer nahezu unmöglich ist, ein halbwegs stabiles programm auf die beine zu stellen. exceptions in konstruktoren hast du ja schon erwähnt.

Shade Of Mine

~fricky schrieb:

und nicht nur das. selbst die c++-eigenen möglichkeiten, also die, die nicht durch C eingeschleust wurden, bergen so viele fallstricke, dass es für einen mittelmässigen programmierer nahezu unmöglich ist, ein halbwegs stabiles programm auf die beine zu stellen. exceptions in konstruktoren hast du ja schon erwähnt.

Nur dumm dass du das nicht belegen kannst.

Schlechte C++ Bücher haben aber natürlich einen großen Teil dazu beigetragen dass C++ dieses Image hat. Keine Frage.

namespace invader

Shade Of Mine schrieb:

Schau dir mal fstream an.

Du meinst, bei einem Fehler das Objekt trotzdem erzeugen lassen und ein failbit setzen? Das halte ich für eine ziemlich hässliche und vor allem technisch unnötige Notlösung.

in c++ zahlst du nix wenn du feature X nicht brauchst. du willst keine exception verwenden, kein problem: wenn du sie nicht verwendest zahlst du nichtmal die kosten für die exception infrastruktur.

Man muss sich aber trotzdem damit auseinandersetzen, auch wenn man es nicht braucht. Wenn man sich selbst nicht um Exceptions kümmert, aber Code aufruft, der welche wirft, baut man (dank des fehlenden Garbage Collectors) mit ziemlicher Sicherheit Memory Leaks.

Die automatischen Kopierkonstruktionen und Zuweisungsoperatoren sind ein anderes Beispiel für Sprachfeatures, die Schaden anrichten, wenn man sie nicht braucht/sich nicht um sie kümmert.

Aber das ist nicht der Punkt. Eine vernünftige Sprache sollte einen überschaubaren Satz von gut abgestimmten und gut durchdachten Features enthalten; welche das sind hängt von der Zielsetzung der Sprache ab. Dann kommt auch niemand auf die Idee, bestimmte Features nicht nutzen zu wollen.

Der C++ Ansatz ist eher: "Hier hast du einen Haufen teilweise redundanter Sprachfeatures. Alle sind irgendwie scheiße, aber wenn sie dir nicht passen, benutze sie doch einfach nicht."