Erst C oder gleich C++ ???

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

[audacia]

Shade Of Mine schrieb:

aber wo ist name() jetzt undurchdacht? es ist die human readable form einer typeinfo.

Hätte man "human-readable" standardisiert, wäre es plötzlich viel nützlicher, meinst du nicht? Wem nützt die gegenwärtige Variante? Außerdem ist std::type_info::name() eigentlich nur beim C++Builder "human-readable"; bei MSVC gibt es, wenn ich mich recht erinnere, offenbar der Optimierung dienende "Verschönerungen", und GCC gibt einfach die vollständig dekorierte Variante zurück.

Jedenfalls fallen sämtliche Features, die man leicht und ohne Zusatzaufwand auf der Grundlage des Vorhandenen hätte implementieren können (siehe meine type_info-Beispiele), für mich ebenso unter "undurchdacht".

Shade Of Mine schrieb:

Warum genau soll ich keinen int werfen dürfen?

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

Dann sage mir bitte: wozu in aller verbliebenen Götter Namen muß man einen Integer werfen können?

Für dein konkretisiertes "wozu braucht man das" hätte ich auch gleich noch ein etwas aktuelleres Beispiel:

enum class MyEnum : float { pi = 42 / 13.37 };

Auch die Sache mit den Default-Kopierkonstruktoren ist mehr als unschön. Barry Kelly hat das, finde ich, recht schön dargelegt.

[Shade Of Mine]

namespace invader schrieb:

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

Deine persönliche Meinung.

Ich persönlich sehe das anders. Ich will dass mir eine Sprache die Tools gibt um die Probleme die ich habe ideal zu lösen. Wenn sie mir nur Hämmer gibt, tu ich mir beim Schraubendrehen schwer - deshalb mag ich es, wenn ich einen ganzen Werkzeugkoffer bekomme.

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.

Dann nimm einen Prozessor her. Ist ein Prozessor ein komplexes Gerät das sehr schwer zu durchschauen ist? Ja, denn es ist zB nicht mehr möglich Prozessoren komplett auf Fehler zu testen. Sinnlos kompliziertes Zeug. Aber irgendwie doch praktisch.

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

Und ich würde sagen dass C++ aus genau dem Grund toll ist.

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.

Du bist dir bewusst was das bedeuten würde. Du müsstest aus Java dann die Generics entfernen und die statischen Klassen/Methoden. Ob dann anonyme klassen noch erlaubt sein dürfen ist dann auch so eine sache - da die meistens im funktionalen stil gebraucht werden...

wäre ne ziemlich beschissene sprache dann.

[rüdiger]

audacia schrieb:

Shade Of Mine schrieb:

aber wo ist name() jetzt undurchdacht? es ist die human readable form einer typeinfo.

Hätte man "human-readable" standardisiert, wäre es plötzlich viel nützlicher, meinst du nicht? Wem nützt die gegenwärtige Variante? Außerdem ist std::type_info::name() eigentlich nur beim C++Builder "human-readable"; bei MSVC gibt es, wenn ich mich recht erinnere, offenbar der Optimierung dienende "Verschönerungen", und GCC gibt einfach die vollständig dekorierte Variante zurück.

Da sehe ich nicht das Problem. Es gibt im C++-Standard einige Dinge die der Implementierung überlassen werden. Aber wenn ich type_info::name() benutze, dann ist das entweder beim debuggen oder um eh platformspezifische Hacks zu bauen (wie zB Introspection, in dem man die Infos aus den Symbolen der sharedlib liest).

[~fricky]

volkard schrieb:

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

wieso? viele sprachen haben gewisse alleinstellungsmerkmale und sind daher nicht beliebig austauschbar. um mal einige zu nennen:
PHP - man kann dynamische webseiten, ohne viele vorkenntnisse, in rekordzeit entwickeln.
Java - bringt eine riesige, plattformunabhängige infrastruktur mit
C# - 'besseres' Java für windows-rechner
C - schlank, schnell, sehr gut geeignet für maschinennahe programmierung, microcontroller, etc.
ADA - low-level, sehr gute typsicherheit, laufzeitchecks d.h. extreme stabilität in einem.
^^usw. usw, um nur (sehr unvollständig) einige zu nennen.
aber wohin gehört c++? gibt es eine lücke, die c++ füllen kann?

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

wenn du schon so fragst: wieso gibt es delete und delete[]?

[asc]

Shade Of Mine schrieb:

Ich will dass mir eine Sprache die Tools gibt um die Probleme die ich habe ideal zu lösen. Wenn sie mir nur Hämmer gibt, tu ich mir beim Schraubendrehen schwer - deshalb mag ich es, wenn ich einen ganzen Werkzeugkoffer bekomme.

Oder kurz gesagt: Für jede Aufgabe sollte man das passende Werkzeug verwenden. In manchen Fällen ist dies eine Scriptsprache, in anderen C++...

Wobei ich hoffe das meine gefühlten Hauptmankos an C++ sich tatsächlich mit C++09 und dem danach folgenden TR (TR2?) erledigen... (Und wer C++ garnicht mag soll es halt nicht einsetzen).

cu André

[Shade Of Mine]

audacia schrieb:

Hätte man "human-readable" standardisiert, wäre es plötzlich viel nützlicher, meinst du nicht? Wem nützt die gegenwärtige Variante? Außerdem ist std::type_info::name() eigentlich nur beim C++Builder "human-readable"; bei MSVC gibt es, wenn ich mich recht erinnere, offenbar der Optimierung dienende "Verschönerungen", und GCC gibt einfach die vollständig dekorierte Variante zurück.

Ich sehe das Problem nicht.
Ja, es könnte besser sein - da widerspricht dir ja niemand. aber ist type_info::name() nicht verwendbar? Es ist praktisch zur Ausgabe. Nicht mehr nicht weniger.

Ich würde es toll finden wenn es reflection gäbe, keine frage.

Jedenfalls fallen sämtliche Features, die man leicht und ohne Zusatzaufwand auf der Grundlage des Vorhandenen hätte implementieren können (siehe meine type_info-Beispiele), für mich ebenso unter "undurchdacht".

es wurde einfach keine restriktionen an die implementierung gegeben.
klar macht es das feature weniger nützlich.
aber weniger nützlich != undurchdacht

Dann sage mir bitte: wozu in aller verbliebenen Götter Namen muß man einen Integer werfen können?

Warum darf ich keinen werfen. Das würde mich mal interessieren.

Weil es keinen Sinn macht? Weil es unschön ist?

ich will aber einen int werfen als error code. unheimlich praktisch weil ich plötzlich keine allokationen brauche für das objekt.

Auch die Sache mit den Default-Kopierkonstruktoren ist mehr als unschön. Barry Kelly hat das, finde ich, recht schön dargelegt.

Der Artikel ist ja mal ziemlicher Käse.
Warum genau sind closures in C++ unmöglich?

Default CopyCtor ist etwas sehr sinnvolles: es erlaubt nämlich code ersparnis - man muss die großen 3 nur implementieren wenn man sie braucht. das erspart eine menge arbeit bei hilfsklassen wie zB eine list node.

und datenstrukturen aus c sind generell so leichter zu verwenden.

[Shade Of Mine]

~fricky schrieb:

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

wenn du schon so fragst: wieso gibt es delete und delete[]?

aus performance gründen