Gebt doch endlich mal richtige Gründe gegen die Sprache D an!



  • Ich finde D sehr schön.



  • Weil?



  • D ist ein besseres C++, insbesondere mit viel besseren Compile-Time-Möglichkeiten.

    Nur verwendet keiner C++ wegen den vielen Möglichkeiten der Templates sondern aus Legacy-Gründen, denn wer das tut ist mit D besser beraten.

    Ich kenne Leute, die verwenden D, aber das sind dann Ein-Mann-Projekte.



  • mit viel besseren Compile-Time-Möglichkeiten.

    Was heißt das? Statische Polymorphie, TMP, usw.? :hechel:



  • Ich finde die Konstruktor-Syntax sehr nett:

    this() {
                    fiber = new Fiber(&run);
            }
    

    Kommt denn bei D der ganze "low-level"-Kram nicht zu kurz? Sieht mir sehr Java-orientiert aus.



    • schrieb:

    TMP

    Braucht es nicht, jede beliebige* Funktion kann zur Compile-Zeit aufgerufen werden. Die Funktion kann D-Code als string generieren, der dann in den Quellcode "eingemixt" werden kann.

    *Gibt ein paar Einschränkungen, es dürfen keine Dateien gelesen werden und so



    • schrieb:

    Weil?

    Ich mag C++ und finde das Design von C# schön.
    D ist irgendwo in der Mitte. Gefällt mir.
    Nativer Code, schöne generische Programmierung, man hat sich bemüht viele Dinge elegant zu lösen die bei C++ eher Hacks sind. Die Möglichkeit des GCs finde ich auch nett. Muss man nicht nutzen aber man kann.
    Hat nicht einer der C++-Gurus (denke es war Alexandrescu) maßgeblich an der Weiterentwicklung von D mitgearbeitet?



  • Jup, der liebe Alexandrescu wars.
    Ich blicke auch manchmal ein wenig neidisch auf die Compiletimesachen von D.
    Aber für mich gab es noch keinen wirklichen Grund mich mit D intensiv zu beschäftigen.
    Gut, TMP ist einfacher, es gibt schon Modules, builtin Invariants,... aber mit C++ kann man das (bald) auch.



  • aber mit C++ kann man das (bald) auch.

    Worauf spielst du an? Was genau ist denn an C++1y soviel besser?
    (Mir sind alle neuen Features bekannt, dennoch sehe ich da keinen evolutionären Schritt)



    • schrieb:

    aber mit C++ kann man das (bald) auch.

    Worauf spielst du an? Was genau ist denn an C++1y soviel besser?

    Das bald bezog sich nur auf die Module, alles andere kann man jetzt auch schon (zwar nicht so elegant wie in D, aber möglich).



  • Nathan schrieb:

    Das bald bezog sich nur auf die Module, alles andere kann man jetzt auch schon (zwar nicht so elegant wie in D, aber möglich).

    D hat Compile-Time-Regex. Da wird ein regulärer Ausdruck genommen und in bestmöglichen D-Code verwandelt und dann mitkompiliert.

    Mir wäre nicht bekannt, dass das in C++ praktisch umsetzbar wäre.



  • hreadv schrieb:

    Nathan schrieb:

    Das bald bezog sich nur auf die Module, alles andere kann man jetzt auch schon (zwar nicht so elegant wie in D, aber möglich).

    D hat Compile-Time-Regex. Da wird ein regulärer Ausdruck genommen und in bestmöglichen D-Code verwandelt und dann mitkompiliert.

    Mir wäre nicht bekannt, dass das in C++ praktisch umsetzbar wäre.

    Was genau meinste damit?



  • Finds ja toll, dass der GC angeblich optional ist. Nur hab ich noch nie jemanden gesehen, der D ohne GC verwendet. Ein Beispiel, wie das dann aussieht, waere also angebracht.



  • Wie kann Compilezeit-Regex missverständlich sein?

    http://dlang.org/regular-expression.html

    string phone = "+31 650 903 7158";
    auto phoneReg = ctRegex!r"^\+([1-9][0-9]*) [0-9 ]*$";
    auto m = match(phone, phoneReg);
    

    wird zur Compilezeit umgewandelt zu

    string phone = "+31 650 903 7158";
    if (phone[0]!='+')
      return false; // doesn't match
    if (!('0'<=phone[1]&&phone[1]<='9'))
      return; // doesn't match
    for (int i=2; i<phone.size() && '0'<=phone[i]&&phone[i]<='9'; ++i)
       ;
    ...
    

    und ist dementsprechend genauso schnell wie wenn man das von hand gecoded hätte.

    @GC: Soweit ich weiss gibt es einen Compiler-Switch den GC auszustellen, aber dann geht die Standardbibliothek nicht mehr. Und der GC ist ein Witz, der gibt praktisch nichts mehr frei.



  • Ist bestimmt gut debugbar.



  • D sucks - sorry but it does 🕶



  • hreadv schrieb:

    Wie kann Compilezeit-Regex missverständlich sein?

    Ich war mir nicht sicher, ob ich dich richtig verstanden hatte.
    Nun, Compiletimecodegenerierung gibts in C++ via Templates.
    Der einzige Nachteil ist, dass der Compiler da scheinbar schnell an seine Grenzen kommt (oder mein Versuch ist zu schlecht :D).
    Sternchen, oder wie auch immer du nun heißt, wär das nicht was für dich?
    Konstanten String durchlaufen, nach Steuerzeichen Ausschau halten und rekursiv verknüpfen?



  • Sternchen, oder wie auch immer du nun heißt, wär das nicht was für dich?
    Konstanten String durchlaufen, nach Steuerzeichen Ausschau halten und rekursiv verknüpfen?

    Den Namen lasse ich nun zu Arcoth ändern, da das Sternchen allgemeines Unbehagen heraufbeschworen hat. 🙂

    Der Vorschlag ist nicht schlecht! Ja, ich bin ein TMP-Fan und die Aufgabe wäre nett.
    Also, worum genau geht es? Zeig mal ein Beispiel, wie es im Endeffekt aussehen sollte.



  • Fang doch mal mit einem

    constexpr char const expr[] = "a|b";
    assert(re<expr>.match("a"));
    assert(!re<expr>.match("c"));
    

    an und schau wieviel du umgesetzt bekommst.

    (kA ob das mit den Stringliteralen so per TMP funktioniert, kann ja auch ein



    • schrieb:

    Sternchen, oder wie auch immer du nun heißt, wär das nicht was für dich?
    Konstanten String durchlaufen, nach Steuerzeichen Ausschau halten und rekursiv verknüpfen?

    Den Namen lasse ich nun zu Arcoth ändern, da das Sternchen allgemeines Unbehagen heraufbeschworen hat. 🙂

    Der Vorschlag ist nicht schlecht! Ja, ich bin ein TMP-Fan und die Aufgabe wäre nett.
    Also, worum genau geht es? Zeig mal ein Beispiel, wie es im Endeffekt aussehen sollte.

    Hab mal schnell meinen Code umgeschrieben, dass man nicht meine Bibliothek verwenden muss:
    https://ideone.com/qXmBYB
    War grad dabei | zu implementieren, Compiler bricht aber immer bei der Kompilierung ab.


Anmelden zum Antworten