Erst C oder gleich C++ ???

_matze

Fred vom Jupiter schrieb:

Wozu Klassen gut sind habe ich verstanden

Den objektorientierten Ansatz kann man auch sehr gut in C verfolgen, ist gar kein Thema. Du musst halt nur auf solchen Kram wie Vererbung etc. verzichten...

JustAnotherNoob

Du musst halt nur auf solchen Kram wie Vererbung etc. verzichten...

Meines Wissens ist das mit GLib z.B. irgendwie möglich, wenn auch umständlich.

:full ack:
eine knappe und äusserst passende darstellung. mehr muss zu C++ einfach nicht gesagt werden.

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

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

Das mußt gerade du sagen, du machst deinem Namen alle Ehre. fricky~ gibt sehr oft hilfreiche und gute Ratschläge und es steht ihm wohl frei seine Meinung zu diesem Thema kundzutun, genau wie es die ganzen C++ freaks hier auch tun. ich stimme mit fricky~s meinung auch durchaus überein.

JustAnotherNoob schrieb:

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.

ich hab' auch schon mal geschrieben, dass visual basic mist ist, dass windows und linux mist sind, das autos von bmw mist sind, usw. also ganz so eindimensional, wie du denkst, bin ich nun auch nicht.

JustAnotherNoob schrieb:

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

Mit der Aussage, dass C++ Mist ist, hat er doch voll und ganz recht. Eine überflüssige Sprache, die sich nur wegen des hohen Verbreitungsgrades von C durchgesetzt hat. Damals war OOP halt was ganz neues. Und da praktisch jeder in C programmiert hatte, war bjarne stroustroup geschickt genug eine neue Sprache auf C Basis aufzubauen um ein breites Publikum anzusprechen.

Das ist der einzige Grund warum heutzutage C++ so weit verbreitet ist. Hat absolut nichts mit dessen Vorzügen zu tun. Es gibt nämlich keine.

ascda schrieb:

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

Das mußt gerade du sagen, du machst deinem Namen alle Ehre. fricky~ gibt sehr oft hilfreiche und gute Ratschläge und es steht ihm wohl frei seine Meinung zu diesem Thema kundzutun, genau wie es die ganzen C++ freaks hier auch tun. ich stimme mit fricky~s meinung auch durchaus überein.

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

Wahrscheinlich willst du mir auch gleich erklären, dass Lisp eine völlig bescheuerte Sprache ist, weil dir die Syntax nicht gefällt.
So ein schwaches Argument habe ich selten gehört.

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.