3. Was würdet ihr an C++ verbessern?

Was würdet ihr an C++ verbessern?

  • V

    properties halte ich für unnütz. machen nur die syntax komplizierter.

    0
  • S

    volkard schrieb:

    properties halte ich für unnütz. machen nur die syntax komplizierter.

    Ist es nicht komplizierter jede Klasse um hunderte Zeilen aufzublasen für:

    class C {
        int _i;
        int _j;
    public:
        inline int getI() { return _i; }
        inline void setI(int i) { return _i = i; }

        inline int getJ() { return _j; }
};

vs

class C {
    property int i;
    property int j { get; }
}

    ? Auch im Hinblick auf Kommentare (oben 3x nötig, unten 1x, etc.)?

    MfG SideWinder

    0
  • A

    this->that schrieb:

    + Weg mit den Scheiss Headern

    Dafür würde ich private 1000 EUR an das Komitee bezahlen, damit die Headers im ISO-C++ deprecated werden! Das Geld wäre gut angelegt, da es mich Nerven und vor allem Zeit für mein restliches Leben sparen würde. Als Firma würde ich mehr investieren. Unglaublich was für ein Haufen unsinnigen Code-Kot man in seinem (kostbaren) C++-Leben schreiben muss. 😡

    this->that schrieb:

    + Enum Konstanten nur qualifizierbar mit Namespacenamen (gibts vermutlich ab C++0x)

    Nur logisch. Das erste mal, als ich Enums nutzen wollte, habe ich das intuitiv gemacht, und der Compiler hatte mich angemotzt. 😡

    this->that schrieb:

    + Hat nix mit der Sprache zu tun, aber gehoert dennoch in ihr Umfeld: Endlich eine gescheite Standard Library mit Threads, XML, Networking etc.

    Die Std-Library gehört mit zum Sprachstandard. Darf man hier ruhig nennen. Threads kommen ja definitiv mit C++0x. Für XML gab es einen Aufruf vom Komitee für den TR2. Wurde aber nichts eingereicht. Networking, da könnte boost.asio ein Kandidat werden. Aber das wird wohl noch 10 Jahre dauern. 😉

    0
  • F

    Ich als C# Nutzer finde Properties aber auch besser

    class CSharp
{
    public int Zahl { get; private set; } 
}

    Etc...

    0
  • A

    SideWinder schrieb:

    class C {
        int _i;
        int _j;
    public:
        inline int getI() { return _i; }
        inline void setI(int i) { return _i = i; }

        inline int getJ() { return _j; }
};

vs

class C {
    property int i;
    property int j { get; }
}

    ? Auch im Hinblick auf Kommentare (oben 3x nötig, unten 1x, etc.)?

    Hem, ist für mich echt ein konstruiertes Beispiel. Was ist, wenn neben dem reinen return und assignment noch was anderes passieren soll?

    0
  • M

    Regex-Literale. Reguläre Ausdrücke sind sowieso schon schwer zu lesen, da will ich nicht noch jedes zweite Symbol escapen müssen.

    0
  • F

    Artchi schrieb:

    SideWinder schrieb:

    ...

    Hem, ist für mich echt ein konstruiertes Beispiel. Was ist, wenn neben dem reinen return und assignment noch was anderes passieren soll?

    class CSharp
{
    private int zahl;
    public int PZahl
    {
        get
        {
            return zahl * 5;
        }
        set
        {
            zahl = value * 5;
        }
    }
}

    Letztendlich werden Properties auch zu getter und setter, sehen meiner Ansicht nach aber besser aus.

    0
  • I

    SideWinder schrieb:

    ipsec schrieb:

    SideWinder schrieb:

    Darf man zusammenfassen, dass ihr eine Art syntaktisches C# mit Template-Metaprogrammierung und STL wünscht?

    Auf keinen Fall! Die C#-Syntax finde ich teilweise nicht gelungen, in fast allen Fällen finde ich die C++-Alternative besser. Auch würde ich z.B. Properties syntaktisch nicht wie in C# umsetzen wollen.

    Nun aber raus mit der Sprache, Beispiele, Beispiele, Beispiele. Bitte 🤡

    MfG SideWinder

    Ich will das hier nicht zu einem C#-Bash-Thread machen, nur mal ein Beispiel, was ich bei C++ besser finde: Zugriffsmodifizierer wirken sich auf alle nachfolgenden Elemente aus.

    Bei sowas wie Networking in der Standardbibliothek sehe ich vor allem das Problem der Aktualisierung. Bei boost.asio z.B. werden auch heute noch Bugs gefixt. boost ist auch schnell mal aktualisiert, aber wie oft aktualisiert ihr eure Standardbibliothek? Bei den Containern und Algrithmen kann man nunmal nicht so viel falsch machen. Hinzu kommt, dass man dann jedesmal Jahre warten müsste, bis z.B. ein neues Netzwerkprotokoll in den Standard aufgenommen wurde, während andere Bibliotheken da viel flexibler sind.

    Raw-Strings kommen übrigens mit C++0x.

    0
  • C

    -Standard für socket
    -Standard für ein filesystem
    -Eigene operatoren hinzufügen können

    0
  • A

    ipsec! Der Standard definiert ja nicht die Implementierung einer Bibliothek! Du kannst doch jeder Zeit ein Bugfix-Release einer C++-Std-Lib nutzen. Alle Compiler-Hersteller liefern Bugfixes aus, wenn in deren C++-Standard-Library ein Fehler auftritt. Außerdem müsste die Network-Lib keine Hi Level Protokolle definieren. Aber es wäre einfacher überhaupt Hi Level Protokolle zu implementieren, wenn die Std-Lib wenigstens Low-Level-Protokolle anbietet. Meines Wissens hat boost.asio eh keine Hi Level Protokolle.

    0
  • M

    FreakY<3Cpp schrieb:

    Artchi schrieb:

    SideWinder schrieb:

    ...

    Hem, ist für mich echt ein konstruiertes Beispiel. Was ist, wenn neben dem reinen return und assignment noch was anderes passieren soll?

    class CSharp
{
    private int zahl;
    public int PZahl
    {
        get
        {
            return zahl * 5;
        }
        set
        {
            zahl = value * 5;
        }
    }
}

    Letztendlich werden Properties auch zu getter und setter, sehen meiner Ansicht nach aber besser aus.

    Hast du dein Beispiel mal ausprobiert?

    0
  • R

    Als erstes würde ich die Syntax komplett ändern. Die Sprache sollte einfach parsbar sein und zwar für Menschen und Maschinen. C++ ist extrem schwer zu parsen und das hat dafür gesorgt, dass es leider bei den Tools gegenüber anderen Sprachen zurück hängt. Vielleicht ändert sich dies jetzt, wenn man mit Clang ein sauber getrenntes Frontend hat. Zumindest sollte man Trigraphs komplett entfernen. Die machen das Parsen derzeit für alle extra schwierig und dabei benutzt die doch keiner mehr (außer vielleicht irgend ein paar eingestaubte IBM Mainfraimler. Aber die werden wohl eh keinen aktuellen C++0x Compiler haben). Idealerweise wäre natürlich ein Parser direkt ein Bestandteil der Standardbib.

    Ein Modulsystem wäre wirklich praktisch. Das include-Zeugs macht das kompilieren unnötig langsam und ist eine unnötige Fehlerquelle.

    Viele Dinge explicit machen und lieber ein implicit einfügen. Automatische Generierung von Copyctor/operator würde ich auch rausnehmen. Man könnte lieber explizit sagen, dass das generiert werden soll.

    Das Typsystem sollte strikter sein und idealerweise ähnlicher zu ADA als zu C. Design-by-Contract wäre vielleicht auch interessant. Oh und Concepts würde ich gerne haben.

    Michael E. schrieb:

    Regex-Literale. Reguläre Ausdrücke sind sowieso schon schwer zu lesen, da will ich nicht noch jedes zweite Symbol escapen müssen.

    User-defined-Literals haben sie wohl wieder abgeschafft :(.

    0
  • ?

    Also bei Properties sehe ich ehrlich gesagt den großen Vorteil gegenüber normalen Gettern und Settern nicht.

    ? Auch im Hinblick auf Kommentare (oben 3x nötig, unten 1x, etc.)?

    Wozu sind bei deinem Beispiel Kommentare nötig? Wenn es reine Getter und Setter sind braucht man sie nicht, wenn sie etwas mehr machen, braucht man die Kommentare in jedem Fall, egal ob C#-Getter/Setter oder normale C++ Methoden.

    Viele von den hier gewünschten Features kommen auch mit C++0x, z.B. Dateisystem, Raw-Strings, Threads, etc..
    Es geht also auf jeden Fall in die richtige Richtung.

    -Eigene operatoren hinzufügen können

    Das wäre wirklich sehr schick! Das würde die Entwicklung von EDSLs enorm erleichtern.

    0
  • I

    Vorteil der Properties: Lesbarkeit. Ich gebe zu, kein großer Vorteil, aber warum sollte man es verbieten? Was sind die Nachteile?

    Ich bin aber gegen eigene Operatoren. Ich sehe da den Trend, dass man dann auf normale Methoden komplett zu verzichten versucht und erstmal schaut, ob nicht irgendeine Sonderzeichenkombination entfernt auch den Zweck ausdrücken könnte. Außerdem läst sich sowas schwer mit generischem Code vereinen.
    Hinzu kommen sehr große Parseschwierigkeiten. Vor allem, wenn die eigenen Operatoren noch eigene Prioritäten o.ä. haben sollen.
    Außerdem gibt es da ein nicht unerhebliches Risiko, durch einen neuen Operator bestehenden Code zu invalidieren. Nicht selten kommen ja auch z.B. Sachen wie if(!*x) vor, wenn dann plötzlich jemand einen !* -Operator definiert, hat man im besten Fall einen Compilefehler, im schlimmsten Fall kompiliert das noch und ist ganz schwer zu finden.

    0
  • F

    Michael E. schrieb:

    Hast du dein Beispiel mal ausprobiert?

    Ja, funktioniert, wieso?

    0
  • A

    rüdiger schrieb:

    Als erstes würde ich die Syntax komplett ändern. Die Sprache sollte einfach parsbar sein und zwar für Menschen und Maschinen. C++ ist extrem schwer zu parsen und das hat dafür gesorgt, dass es leider bei den Tools gegenüber anderen Sprachen zurück hängt. Vielleicht ändert sich dies jetzt, wenn man mit Clang ein sauber getrenntes Frontend hat. Zumindest sollte man Trigraphs komplett entfernen. Die machen das Parsen derzeit für alle extra schwierig und dabei benutzt die doch keiner mehr (außer vielleicht irgend ein paar eingestaubte IBM Mainfraimler. Aber die werden wohl eh keinen aktuellen C++0x Compiler haben). Idealerweise wäre natürlich ein Parser direkt ein Bestandteil der Standardbib.

    Ich hatte mal einen Blog von einem C++-Komitee-Mitglied gelesen. (Frag mich nicht wo) Der meinte sinngemäß, das nur Leute die keinen C++-Compiler entwickeln, der Meinung sind, das ein C++-Parser schwer zu implementieren ist. Und das dieser Mythos ihm ziemlich auf den Senkel geht, weil diese Forderung komischerweise nur von den Leuten kommt, die keinen C++-Compiler entwickeln müssen. 😃

    Was die Tools angeht: das Problem hat MS mit MSVC2010 schon lange gelöst! Vorher gab es ein separates Tool für IntelliSense. Jetzt liefert der MSVC2010-Compiler die Infos für IntelliSense, und scheint ja jetzt auch super zu funktionieren. MSVC2010 zeigt einem sogar bei der Codeeingabe on-the-fly Compilefehler an, ohne das man einen Compile-Vorgang starten muß.

    D.h. der Weg war nur falsch. Das Parsen und Analyse des C++ Codes macht jeder C++ Compiler mit links.

    0
  • M

    FreakY<3Cpp schrieb:

    Michael E. schrieb:

    Hast du dein Beispiel mal ausprobiert?

    Ja, funktioniert, wieso?

    CSharp foo = new CSharp();
foo.PZahl = 1;
Console.WriteLine(foo.PZahl);
    0
  • V

    ipsec schrieb:

    Vorteil der Properties: Lesbarkeit. Ich gebe zu, kein großer Vorteil, aber warum sollte man es verbieten? Was sind die Nachteile?

    Kompliziertheit über Kompliziertheit. Kann man von einem Property die Adresse ziehen? Oder eine Referenz? Was macht der Operator+=? Was macht ein property, wenn es zu bool ausgewertet werden soll? Was macht std::forward damit? Können properties virtuell und pur virtuell sein? Was ergeben sizeof und decltype?

    Properties brauche ich nur, um meine Klassen so zu bauen, daß sie sich wie Microsoft-Klassen anfühlen. Stört es, vec.size() statt vec.size zu schreiben?

    0
  • F

    Michael E. schrieb:

    FreakY<3Cpp schrieb:

    Michael E. schrieb:

    Hast du dein Beispiel mal ausprobiert?

    Ja, funktioniert, wieso?

    CSharp foo = new CSharp();
foo.PZahl = 1;
Console.WriteLine(foo.PZahl);

    So sieht mein Programm ebenfalls aus, wo ist das Problem? Kommt wie erwartet 25 raus.

    0
  • ?

    Ja, funktioniert, wieso?

    Aber sicherlich nicht so wie er sich das vorgestellt hat.

    Ich sehe da den Trend, dass man dann auf normale Methoden komplett zu verzichten versucht und erstmal schaut, ob nicht irgendeine Sonderzeichenkombination entfernt auch den Zweck ausdrücken könnte.

    Wie kannst du einen Trend sehen, wenn eigene Operatoren nicht einmal erlaubt sind.

    Außerdem läst sich sowas schwer mit generischem Code vereinen.

    Warum das? Template-Argument-Deduction könnte doch auch wunderbar für eigene Operatoren funktionieren.

    Hinzu kommen sehr große Parseschwierigkeiten. Vor allem, wenn die eigenen Operatoren noch eigene Prioritäten o.ä. haben sollen.

    Das klingt alles so, als hättest du das schon implementiert. Ob der Operator + jetzt Built-In oder User-Defined ist, sollte doch keinen allzu großen Unterschied machen.

    Außerdem gibt es da ein nicht unerhebliches Risiko, durch einen neuen Operator bestehenden Code zu invalidieren. Nicht selten kommen ja auch z.B. Sachen wie if(!*x) vor, wenn dann plötzlich jemand einen !*-Operator definiert, hat man im besten Fall einen Compilefehler, im schlimmsten Fall kompiliert das noch und ist ganz schwer zu finden.

    Ich dachte im Thread ginge es darum sich erstmal nicht um Abwärtskompatibilität zu kümmern.

    Dass eigene Operatoren wunderbar funktionieren zeigt übrigens Haskell.

    0
Anmelden zum Antworten