Erst C oder gleich C++ ???

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

[asc]

~fricky schrieb:

^^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?

C++ : Wie C sehr schnell, und auch für maschinennahe Programmierung geeignet. Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

Ich finde das C++ in jede Nische passt, die C erfüllt, wenn man gleichzeitig noch Funktionalitäten von Hochsprachen haben will. Sprich: In allen Projekten wo C möglich wäre, die Komplexität des Programmes aber mehr Abstraktion und Wartbarkeit erfordert (Meiner Meinung nach auch mehr Stabilität).

cu André

[Bulli]

namespace invader schrieb:

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.

Dann benutze doch einfach eine andere Sprache als C++. Oder wo ist der Haken?

[dfgdfgdfg]

asc schrieb:

C++ : [...] Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

cu André

Wow! Applaus! Soll jetzt jeder Luftsprünge machen?
Das was du da tolles für C++ vorstellst, ist das selbstverstöndlichste auf der welt.

C++ ruht sich auf Lohrbeeren aus, die schon seit ~30 jahren als etwas selbstverstäünliches in highlevelsprachen sind.

[~fricky]

Shade Of Mine schrieb:

~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

das verstehe ich nicht. in dem allozierten block ist doch schon die information gespeichert, wie gross er ist. ein zusätzliches delete[] müsste es doch gar nicht geben.

asc schrieb:

~fricky schrieb:

^^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?

C++ : Wie C sehr schnell, und auch für maschinennahe Programmierung geeignet.

trotzdem wird C++ in solchen bereichen eher selten verwendet, sondern stattdessen C. warum? aus unwissenheit, traditionsbewusstsein oder aus gutem grund?

[Walli]

Tradition wuerde ich tippen. Und weil man gut C++ koennen muss um zu wissen wo die Overheads stecken koennten. Auch die Verfuegbarkeit der Compiler koennte eine Rolle spielen.

[hellihjb]

wieso gibt es delete und delete[]?

aus performance gründen

das verstehe ich nicht. in dem allozierten block ist doch schon die information gespeichert, wie gross er ist. ein zusätzliches delete[] müsste es doch gar nicht geben.

delete[] fuehrt den Destruktor jedes einzelnden Elementes aus.
Das kann erwuenscht sein oder auch nicht - haelst Du fuer ueberfluessig?

[audacia]

Shade Of Mine schrieb:

~fricky schrieb:

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

aus performance gründen

Unfug. Der Allokator muß ohnehin Metainformationen über den Speicherblock unterbringen. Ob da jetzt auch noch eine Array-Dimension mitgespeichert wird, dadurch aber jeder Menge Laufzeitfehler vorgebeugt wird, macht doch nun keinen Unterschied in der Performance?
(@fricky: da zwischen Allokation und Konstruktion unterschieden wird, muß schon zusätzliche Information untergebracht werden. Aber trotzdem: vier Bytes im Tausch gegen eine vermeidbare Fehlerquelle!)

Shade Of Mine schrieb:

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.

Du weichst deiner eigenen Frage aus
Sage mir doch: wozu braucht man das?
Für das vermeiden von Allokationen aka Premature Optimization jedenfalls nicht. Du kannst auch ein std::exception-Derivat implementieren, das für what() ein Literal zurückgibt und auf dem Stack alloziert wird. Keinerlei Allokation vonnöten, dafür alle Vorteile der Polymorphie beim Exception-Handling vorhanden.

Shade Of Mine schrieb:

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

"This problem is hard. Let's make it an option and the user can decide!"

In obigem Falle mit std::type_info ist es aber so, daß die Features ohne Mehraufwand gewesen wären: niemand hätte VMTs vergrößern müssen, weil das Nötige eh schon drinsteht. Niemand, der die Funktionalität nicht benötigt, hat größere Executables. Nur die RTL-Programmierer haben ein paar zusätzliche Funktionen zu implementieren, die sich im Wesentlichen aus den Bestandteilen der Implementation von dynamic_cast<> zusammensetzen lassen.
Aufgrund des Fehlens solcher Features halte ich std::type_info schlicht für "undurchdacht".

Artchi schrieb:

Dann benutze doch einfach eine andere Sprache als C++. Oder wo ist der Haken?

Als Argument kein Stück besser als IYWTPICPPTPICPP

Edit: Typographie und Eile