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



  • Bist auf Windows?



  • Jup.



  • Linus Dorfwalds schrieb:

    D sucks - sorry but it does 🕶

    Quelle?



  • Nathan schrieb:

    Jup.

    Ouch.

    Bei mir klappt schon folgendes.

    template< typename Str >
    struct or_matcher
    {
    	using splitted = split_at<Str, Str::find('|'), false>;
    
    	template< typename Str2 >
    	struct matches :
    		std::integral_constant<bool,
    		                       find<type_list<get<splitted, 0>, get<splitted, 1>>, Str2 >::value != npos> {};
    };
    
    int main()
    {
    	using expr = STRING("a|b");
    
    	static_assert( or_matcher<expr>::matches<STRING("a")>::value , "" );
    	static_assert( !or_matcher<expr>::matches<STRING("foo")>::value , "" );
    }
    


  • Andrew Ahnensaum schrieb:

    Linus Dorfwalds schrieb:

    D sucks - sorry but it does 🕶

    Quelle?

    http://www.youtube.com/watch?v=Aa55RKWZxxI



  • Mein Grund gegen 😨

    Ich bin mit C und C++ voll und ganz zufrieden. Warum sollte ich also D verwenden?



  • Genau. C++ rockt!! Sorry but it does do!



  • Wer mit C und C++ zufrieden ist, ist sehr leicht zufriedenzustellen und damit auch mit D zufrieden.

    Bleibt ein letztes Argument: D kompiliert in einem Bruchteil der Zeit von C++.



  • yetanothertroll schrieb:

    Wer mit C und C++ zufrieden ist, ist sehr leicht zufriedenzustellen und damit auch mit D zufrieden.

    Bleibt ein letztes Argument: D kompiliert in einem Bruchteil der Zeit von C++.

    Troll!! 😡



  • @Sonnenhacker: Der zu matchende String sollte kein Compiletime-String sein müssen. Dafür gibt es kein Einsatzgebiet.
    Nur der RE-String selbst. Damit könnte man sich eben per TMP das Kompilieren des RE-Strings sparen können - super.



  • yetanothertroll schrieb:

    Bleibt ein letztes Argument: D kompiliert in einem Bruchteil der Zeit von C++.

    Mag sein, die Compilierzeit interessiert den Anwender aber nicht. Aber mich als Entwickler interessiert die Syntax und somit auch die Wartbarkeit von Software. D kann kein Mensch, d.h. man braucht spezielle Leute für das.

    Bei aller Nettigkeit, aber ich glaube nicht, dass sich D in nächster Zeit etablieren wird. Die meisten anderen Programmiersprachen seit Jahrzehnte alt und werden schon seit Jahrzehnten benutzt, sind somit also "Quasi-Standard".

    Es gibt sehr viele Bibliotheken für C und C++, wenn man D verwenden will, müsste man diese Bibiotheken umschreiben. Das ist ein zeit- und geldaufwändiger Prozess, den keiner machen will, denk ich mal.



  • D ist ein Forschungsprojekt und war nie für den Produktiveinsatz vorgesehen.



  • Ethon schrieb:

    @Sonnenhacker: Der zu matchende String sollte kein Compiletime-String sein müssen. Dafür gibt es kein Einsatzgebiet.
    Nur der RE-String selbst. Damit könnte man sich eben per TMP das Kompilieren des RE-Strings sparen können - super.

    Wieso bist du denn jetzt so stinkig?



  • unser kleiner star hat sich ja immer noch nicht umbenannt. langsam wird er zur plage



  • big boss schrieb:

    unser kleiner star hat sich ja immer noch nicht umbenannt. langsam wird er zur plage

    Wer wars denn vorher?



  • --------------- schrieb:

    big boss schrieb:

    unser kleiner star hat sich ja immer noch nicht umbenannt. langsam wird er zur plage

    Wer wars denn vorher?

    Hacker



  • big boss schrieb:

    unser kleiner star hat sich ja immer noch nicht umbenannt. langsam wird er zur plage

    Ich habe Markus die Mail geschickt! Jetzt warten wir noch ein, zwei Tage.



    • schrieb:

    Nathan schrieb:

    Jup.

    Ouch.

    Bei mir klappt schon folgendes.

    template< typename Str >
    struct or_matcher
    {
    	using splitted = split_at<Str, Str::find('|'), false>;
    
    	template< typename Str2 >
    	struct matches :
    		std::integral_constant<bool,
    		                       find<type_list<get<splitted, 0>, get<splitted, 1>>, Str2 >::value != npos> {};
    };
    
    int main()
    {
    	using expr = STRING("a|b");
    
    	static_assert( or_matcher<expr>::matches<STRING("a")>::value , "" );
    	static_assert( !or_matcher<expr>::matches<STRING("foo")>::value , "" );
    }
    

    Arrgh, verdammt, ich weiß meinen Fehler.
    Komplett falscher Ansatz. 😃



    • schrieb:

    Ethon schrieb:

    @Sonnenhacker: Der zu matchende String sollte kein Compiletime-String sein müssen. Dafür gibt es kein Einsatzgebiet.
    Nur der RE-String selbst. Damit könnte man sich eben per TMP das Kompilieren des RE-Strings sparen können - super.

    Wieso bist du denn jetzt so stinkig?

    Bin doch nicht stinkig.
    Nur möchte ich dass du etwas Cooles produzierst und keinen sinnlosen Proof-of-Concept. 🤡
    Und in der Realität ist der zu matchende String eben nie einen Compiletime-konstante.

    Aber du kannst den Regex-String zur Compilezeit verwursten. Das ist toll weil der dann nicht zur Runtime kompiliert werden muss UND der Compiler kann das Ganze auch noch optimieren.
    Ziemlicher Vorteil gegenüber konventionellen Ansätzen meiner Meinung nach. Also mach das so. 👍



  • Ich find die Compile-Time Code-Generierung echt genial, ich könnte über C++-Templates abkotzen, besonders nach den letzten Tagen. Die sucken so dermaßen um Code zu generieren, der darüber hinausgeht für alle Typen exakt gleich auszusehen), dass ich es kaum noch in Worte fassen kann und mir inzwischen eher überlege, externe Code-Generatoren zu basteln. Die basteln dann wenigstens auch "optimalen" Code, und scheitern nicht daran, dass RValue-Referenzen nicht an mutable LValue-Referenzen zu binden sind (und man aus Parameter-Packs keine Variablen-Liste erzeugen kann) und so ein Scheiß. In D hat man das gleich eingebaut.


Anmelden zum Antworten