Erst C oder gleich C++ ???

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

[~fricky]

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

[Bulli]

namespace invader schrieb:

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

Dann benutze doch C++ einfach nicht. Oder wo ist jetzt der Haken?

[ermlol]

Shade Of Mine schrieb:

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

Genau diese Tatsache sollte doch einem zu denken geben, dass so viele Autoren von C++ Büchern den Quatsch selber nicht wirklich verstanden haben.

Das kann doch nicht effizient sein.

[Shade Of Mine]

namespace invader schrieb:

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.

Ist in einigen Sprachen so gang und gäbe.
und es ist _eine_ legitime lösung für das problem.
es gibt zig andere... jede hat vor und nachteile...

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.

selbes in java
(und ich wette du verstehst nicht warum es in java resourcen leaks geben kann, stimmts?)

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.

Andererseits erlauben sie C kompatibilität.

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.

Denkfehler.
Man nutzt bestimmte Features einen bestimmten Gründen nicht. zB kann es sein dass Exceptions auf der Zielplattform nicht effizient umsetzbar sind und deshalb mag man sie uU nicht nutzen.

aber zB laufzeit polymorphie dagegen ist ein feature dass man prinzipiell immer dann nutzt wenn es sinn macht. in java nutzt man es zB immer - auch wenn es keinen sinn macht.
natürlich ist es einfacher wenn man einen hammer hat alles als nagel zu behandeln, die frage ist wie sinnvoll es ist.

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

sag mir ein nicht durchdachtes feature von c++ und ich zeige dir ein feature dass du nicht verstanden hast.

natürlich sind in c++ eine menge kompromisse drinnen, aber fast jede sprache hat das. einmal gesetzte grenzen limitieren einen in der implementierung der sprache. zB ist java furchtbar durch das "alles erbt von object" und den bytecode definitionen behindert.

auch geht c++ oft einen kompromiss pro-praxis und contra-schönheit. nicht jede sprache kann so schön wie IO sein... aber schönheit ist subjektiv und daher nicht messbar.

[Shade Of Mine]

ermlol schrieb:

Shade Of Mine schrieb:

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

Genau diese Tatsache sollte doch einem zu denken geben, dass so viele Autoren von C++ Büchern den Quatsch selber nicht wirklich verstanden haben.

Das kann doch nicht effizient sein.

Effizient im Sinne von was?
Leicht zu lernen? Nein, da ist C++ sicher nicht gut.
Effizient im Sinne von Laufzeitperformance? Da hat C++ sicher die Nase vorne.

Niemand behauptet aber dass C++ leicht zu lernen ist.
Muss es leicht lernbar sein um gut zu sein?
Beispiel Quantentheorie: ist sie leicht lernbar? nein.
ist sie ein essentieller bestandteil der naturwissenschaften? ja.

[audacia]

Shade Of Mine schrieb:

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

Na komm. Sicher, er übertreibt, aber daß es sich bei vielen Aspekten C++ um gewaltige Leaky Abstractions handelt, zeigen doch Zahl und Art vieler Posts hier zur Genüge.

Daß man mit C++ auch vernünftige Software entwickeln kann, weiß ich auch. Aber gute C++-Programmierer (nicht "exzellente", sondern "gute" im Sinne von "ihren Aufgaben für die Alltagstauglichkeit hinreichend gewachsen") sind rarer und teurer als beispielsweise gute Java- oder C#-Programmierer.

Edit: Ah, wie ich sehe, geht dein letztes Posting in eine ähnliche Richtung. Dann sind wir uns ja einig

[volkard]

audacia schrieb:

Aber gute C++-Programmierer (nicht "exzellente", sondern "gute" im Sinne von "ihren Aufgaben für die Alltagstauglichkeit hinreichend gewachsen") sind rarer und teurer als beispielsweise Java- oder C#-Programmierer.

zweifellos. für einfache sachen darf man auch java oder c# nehmen. für die echt schwierigen sachen reicht das dann nicht mehr und man muss auch ein wenig mehr ausgeben. ich sehe da kein problem.

[Gregor]

volkard schrieb:

zweifellos. für einfache sachen darf man auch java oder c# nehmen. für die echt schwierigen sachen reicht das dann nicht mehr und man muss auch ein wenig mehr ausgeben. ich sehe da kein problem.

Was genau hälst Du für "echt schwierige Sachen"?

[~fricky]

volkard schrieb:

für einfache sachen darf man auch java oder c# nehmen. für die echt schwierigen sachen reicht das dann nicht mehr und man muss auch ein wenig mehr ausgeben. ich sehe da kein problem.

so lange die schwierigkeit in der aufgabe selbst liegt, und nicht im umgang mit dem werkzeug, sehe ich auch kein problem. aber gibt es irgendeine problemstellung, von der man sagen kann: 'dafür C++ die einzig richtige wahl', wofür weder java noch C, noch python, noch php, noch sonstwas geeignet wären? ich kenne nur eine: wenn man ein programm für eine umgebung schreiben will, in der es bereits eine grosse c++ infrastruktur gibt (wie etwa windows/mfc oder linux/kde), die man nutzen kann oder soll. für standalone c++-programme gibt es aber keinen vernünftigen grund.

[audacia]

volkard schrieb:

Shade of Mine schrieb:

sag mir ein nicht durchdachtes feature von c++ und ich zeige dir ein feature dass du nicht verstanden hast.

So rhetorisch das war: wenn Volkard das jetzt schon inklusive Rechtschreibfehler in seine Signatur übernimmt, gehe ich mal darauf ein.

Ich fange mal an mit typeid und std::type_info. Hier handelt es sich um eine undurchdachte Notlösung:

• std::type_info::name() ist nahezu unbrauchbar, da compilerspezifisch. Dabei hätte man es einfach mangled_name() nennen und zusätzlich eine standardisierte Demangled-Variante einführen können. Wird die nicht benötigt, wird sie nicht dazugelinkt. Und schon wäre das ganze viel nützlicher.
• Es bedarf erst eines Wrappers wie Loki::TypeInfo, um Typinformation vernünftig unterzubringen.
• Da man mit der dynamischen Variante von typeid() über einem Zeiger auf ein polymorphes Objekt an seine Typinformation gelangen kann, wird diese praktisch immer in einen VMT-Slot eingetragen. Es wäre also ohne zusätzlichen Aufwand möglich gewesen, die folgenden Erweiterungen aus der C++Builder-RTL zu standardisieren, da die nötige Funktionalität für dynamic_cast<> ohnehin vorhanden ist:

class   _TIDIST  __rtti type_info
{
    ...
/*  Extra Borland specific member functions and types.  This is for
    dynamic GUID translation and casting.
*/
    void *      __cdecl _internal_rtti_cast(void *srcObj, const type_info *srcType) const;

    template    <class  _SrcType>
    void *      __cdecl _rtti_cast(_SrcType *_src) const
    {
        // do the typeid() inline so the compiler will flag an error
        // if the _SrcType doesn't support rtti.
        return _internal_rtti_cast(_src, (const type_info*)& typeid(_SrcType));
    }
    ...

    struct _base_info
    {
            type_info *_type;
            void *_cookie;
    };

    struct _vbase_info : public _base_info
    {
            bool _indirect();
    };

    type_info const *_first_base(_base_info &) const;
    type_info const *_next_base(_base_info &) const;
    type_info const *_first_vbase(_vbase_info &) const;
    type_info const *_next_vbase(_vbase_info &_vb) const
    {
            return _next_base(_vb);
    }
    ...
};

Und schon wieder wäre type_info ein ganzes Stück nützlicher geworden.

Weiter fallen mir Exceptions ein, hier insbesondere die Tatsache, daß sich alles werfen läßt, nicht nur irgendwelche von std::exception abgeleiteten Objekte, die sinnvolle Grundvoraussetzungen erfüllen. Und bevor jemand hier argumentiert, es sei doch unschön, ein Sprachfeature (throw/catch) an ein Library-Feature (std::exception) zu binden: siehe typeid() und std::type_info.
Edit: Ein kleiner Nachtrag hier: die Exceptionspezifikationen sind unnütz. Daß eine Exception geworfen wird, die gar nicht geworfen werden dürfte, könnte prinzipiell sogar vom Compiler verhindert werden. Aber natürlich sind keinerlei derartige Vorschriften spezifiziert.

So, jetzt hätte ich gerne zwei Features von C++, die ich nicht verstanden habe.

[volkard]

Gregor schrieb:

volkard schrieb:

zweifellos. für einfache sachen darf man auch java oder c# nehmen. für die echt schwierigen sachen reicht das dann nicht mehr und man muss auch ein wenig mehr ausgeben. ich sehe da kein problem.

Was genau hälst Du für "echt schwierige Sachen"?

du erwartest gar nicht, daß das klar abrenzbar ist.

[volkard]

~fricky schrieb:

volkard schrieb:

für einfache sachen darf man auch java oder c# nehmen. für die echt schwierigen sachen reicht das dann nicht mehr und man muss auch ein wenig mehr ausgeben. ich sehe da kein problem.

so lange die schwierigkeit in der aufgabe selbst liegt, und nicht im umgang mit dem werkzeug, sehe ich auch kein problem.

jo. nen hammer darf jeder benutzen, für den gabelstapler muß man schon nen staplerschein haben. dem jetzt vorzuwerfen, daß er komplizierter als ein hammer ist, ist doch kein argument.

~fricky schrieb:

aber gibt es irgendeine problemstellung, von der man sagen kann: 'dafür C++ die einzig richtige wahl', wofür weder java noch C, noch python, noch php, noch sonstwas geeignet wären?

tausch "c++" durch irgend eine sprache deiner wahl aus und dein argument paßt auch. seltsam.

[Shade Of Mine]

audacia schrieb:

[list][*]std::type_info::name() ist nahezu unbrauchbar, da compilerspezifisch. Dabei hätte man es einfach mangled_name() nennen und zusätzlich eine standardisierte Demangled-Variante einführen können. Wird die nicht benötigt, wird sie nicht dazugelinkt. Und schon wäre das ganze viel nützlicher.

Äh, besser geht immer. typeid eignet sich nur fürs sortieren.
reflection wäre natürlich toll, keine frage.
aber wo ist name() jetzt undurchdacht? es ist die human readable form einer typeinfo.

ich sagte nicht dass c++ features perfekt sind, sondern dass sie einen zweck erfüllen. viele features in c++ könnten besser sein, keine frage.

Weiter fallen mir Exceptions ein, hier insbesondere die Tatsache, daß sich alles werfen läßt, nicht nur irgendwelche von std::exception abgeleiteten Objekte, die sinnvolle Grundvoraussetzungen erfüllen. Und bevor jemand hier argumentiert, es sei doch unschön, ein Sprachfeature (throw/catch) an ein Library-Feature (std::exception) zu binden: siehe typeid() und std::type_info.

Warum genau soll ich keinen int werfen dürfen?

So, jetzt hätte ich gerne zwei Features von C++, die ich nicht verstanden habe.

nein, du hast 1 feature von c++ dass dir nicht weit genug geht und eins wo wir unterschiedlicher meinung sind.

nicht durchdacht meine ich im sinne von:
wozu braucht man das?
bsp in php 5.0 gab es die automagische funktion __toString() - die aber nicht konsequent eingesetzt wurde. so dass sie manchmal aufgerufen wurde und manchmal nicht. das war undurchdacht und wurde mit php 5.1 oder so behoben (ka mehr von den genauen versions nummern).

[namespace invader]

Shade Of Mine schrieb:

Niemand behauptet aber dass C++ leicht zu lernen ist.
Muss es leicht lernbar sein um gut zu sein?

Ja. Eine Programmiersprache sollte elegant und einfach sein; denn die Probleme, die man darin lösen will, sind schon schwierig genug.

Beispiel Quantentheorie: ist sie leicht lernbar? nein.
ist sie ein essentieller bestandteil der naturwissenschaften? ja.

Das kann man nicht vergleichen; Quantentheorie ist so kompliziert wie sie ist, weil es keine einfachere Theorie gibt, die Beobachtungen genauso gut erklärt. Sobald jemand eine findet, wird man wohl die verwenden.

C++ ist unnötig kompliziert, weil zu viele Paradigmen hineingequetscht wurden und dann auch noch versucht wurde, zu C kompatibel zu bleiben.

Ich halte das für eine dumme Idee. Sprachen sollten ein oder wenige zusammenpassende Paradigmen konsequent umsetzen und besser dafür sorgen, dass die Anbindung an andere Sprachen problemlos möglich ist.