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

[JLinus]

Andrew Ahnensaum schrieb:

Linus Dorfwalds schrieb:

D sucks - sorry but it does

Quelle?

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

[mein grund gegen d]

Mein Grund gegen

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

[9]

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

[yetanothertroll]

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

[free and pure]

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!!

[Ethon]

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

[mein grund gegen d]

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.

[research assistant]

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

[Columbo]

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?

[big boss]

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?

[big star]

--------------- schrieb:

big boss schrieb:

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

Wer wars denn vorher?

Hacker

[Columbo]

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.

[Nathan]

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

[Ethon]

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

[decimad]

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.

[Columbo]

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.

Wenn ich wieder bock auf TMP habe, ist das ein wirklich nützliches kleines Projekt. Nehme ich mir vor. (Momentan implementiere ich Rabbit, aber damit werde ich hoffentlich in den nächsten paar Tagen fertig)

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

Ersteres ist Unsinn - Mit URefs geht das jedoch wunderbar...
Und letzteres verstehe ich nicht ganz.

Aber solange man weiß was man tut, sind Templates ein zähmbares Biest.

[knivil]

Wenn man Metaprogrammierung in anderen Sprachen anschaut, dann sind Templates in C++ totale Steinzeit. Leider kenne ich mich mit D nicht aus, aber ich sach mal: Templates in D sind auch totale Steinzeit.

[decimad]

Keine Lust mich mit Dir darüber zu streiten, Sone, wenn Du in Frage stellst, dass C++-Templates ab einer gewissen Komplexität einfach nur noch unübersichtlich sind, ätzende Struktur-Static-Funktions-Wrapper, absolut unnötige Tag-Argumente benötigen die jeweils wieder ein paar Zeilen verschlingen, obwohl kaum einmal semantischer Inhalt für eine halbe Zeile enthalten ist.
Wenn constexpr erlauben würde, typabhängig-ungültigen Code in bedingten Anweisungen hinzuschreiben, von denen ja aufgrund der constexprness schon klar ist, dass sie niemals ausgeführt werden (und nicht kompiliert werden müssen), dann würde es sich für mich vielleicht nochmal etwas erwärmen. Darf man das?

[decimad]

Oder anders gesagt: Ab einer gewissen Komplexität und "Heterogenität" des Ergebnisses bevorzugt es mein Gehirn "imperativ" Code zu erzeugen, statt "deklarativ". Falls man das so ausdrücken darf. Da sieht man dann nämlich, was herauskommt und muss nicht an jeder Stelle den Template-Prozessor per Gehirn emulieren.