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

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.

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.

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?

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.

knivil

Mein Wunsch ist ja immer noch ein durch Templates generiertes Sortiernetzwerk a la (ref: http://stackoverflow.com/questions/4770651/what-is-the-fastest-sorting-algorithm-for-a-small-number-of-integers ):

#define CMP_SWAP(i, j) if (a[i] > a[j])              \
    { int tmp = a[i]; a[i] = a[j]; a[j] = tmp; }

void sort8_network(int *a)
{
    CMP_SWAP(0, 1); CMP_SWAP(2, 3); CMP_SWAP(4, 5); CMP_SWAP(6, 7);
    CMP_SWAP(0, 2); CMP_SWAP(1, 3); CMP_SWAP(4, 6); CMP_SWAP(5, 7);
    CMP_SWAP(1, 2); CMP_SWAP(5, 6); CMP_SWAP(0, 4); CMP_SWAP(1, 5);
    CMP_SWAP(2, 6); CMP_SWAP(3, 7); CMP_SWAP(2, 4); CMP_SWAP(3, 5);
    CMP_SWAP(1, 2); CMP_SWAP(3, 4); CMP_SWAP(5, 6);
}

Nur ist die Groesse halt zur Kompilezeit einsetzbar. Der Einfachheit halber koennen es wegen mir 1, 2, 4, 8, 16, 32, 64 ... sein.

Übersehe ich gerade einen offensichtlichen Grund, aus dem das nicht schon gehen würde?

knivil

decimad schrieb:

Übersehe ich gerade einen offensichtlichen Grund, aus dem das nicht schon gehen würde?

Es geht bestimmt, aber darum geht es nicht. Es geht darum, das mittels C++ Templates generisch fuer alle (naja, prinzipiell) Arraygroessen (Potenzen von 2) zu realisieren ... uebersichtlich.

Ach um Übersichtlichkeit geht's. Ja naja, wenn ein Compiler einfach den Quellcode für Compile-Zeit-Konstanten durchlaufen würde und sich dann nur noch diejenigen Anweisungen merkt, die von Runtime-Größen abhängen, dann könnte er praktisch den Algorithmus von Quelltextform in einen riesigen Code-Blob übersetzen, stimmt. Hat die Sache einen Haken?

Natürlich müsste man ihn per Attribut im Voraus davon überzeugen, dass der Algorithmus anhand der gegebenen Compile-Zeit-Größen terminiert. Ansonsten hätten einige Benutzer wohl zu klagen

knivil

Mach 's doch einfach anstatt mich mit allgemeinen Bemerkungen zu belehren ... Ich gebe mich auch mit einer unuebersichtlichen Loesung zufrieden. http://en.wikipedia.org/wiki/Bitonic_sorter

Columbo

knivil schrieb:

Mach 's doch einfach anstatt mich mit allgemeinen Bemerkungen zu belehren ... Ich gebe mich auch mit einer unuebersichtlichen Loesung zufrieden. http://en.wikipedia.org/wiki/Bitonic_sorter

Danke (für den Link). Jetzt geht es einfacher. (Habe schon angefangen)

Ich werd' einen Teufel tun und einen Compiler programmieren, der das könnte! Der schickt dir dann zwar den Code-Blob raus, wenn überhaupt, aber dieser Blob shuffelt dann statt zu sortieren, und das langsamer als Bubblesort ein Array sortieren würde, das nach jeder Iteration wieder geshuffelt wird.
Was willst Du denn von mir? Du sagtest sowas sollte möglich sein, ich drückte die Meinung aus, dass es schon möglich sei. Dann sagtest Du übersichtlich, also deutete ich, dass es Dir eher um die "Abstrakte" Möglichkeit geht, extrem expandiertet Code-Blobs zu erzeugen. Und nun soll ich Dir eigentlich das Template schreiben? Häh?

knivil

Ich werd' einen Teufel tun und einen Compiler programmieren, der das könnte!

Es geht nicht um einen neuen Compiler, Templates in C++ sind ausreichend, der Compiler ist schon da.

Was willst du von mir? Du hast dich doch hingestellt und meintest, dass sei moeglich. Tja, nur hat es noch nie jemand gemacht, in C++, in D in

Oder um deine Worte zu benutzen: Was wird wohl der ofizielle Grund sein? Merkste was?

Ich mein, das ist doch keine Kunst? Statt der Berechnungen der Indizes in den Variablen des gegebenen Pseudo-Codes, rechnest Du das halt direkt aus den Template-Parametern aus und statt einer Schleife generierst Du eine Variadic-Index-Liste und expandierst diese in entsprechend viele Calls auf die Zielfunktion. Dann noch das Array überall als Referenz durchflutschen und eine Spezialisierung als Rekursionsende, die eben das Compare-Swap durchführt. Und hinterher hoffen, dass der Compiler das alles in die Top-Level-Funktion inlined.

knivil schrieb:

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.

Templates in C++ sind Steinzeit im Vergleich zu D.

Aktuell sind es String Mixins, also die Möglichkeit, jeden "constexpr"-String in den Quellcode einzufügen. Und constexpr ist per default alles. AST Macros sind leider erst geplant.

knivil

Ich mein, das ist doch keine Kunst? ...

Und noch mehr allgemeine Belehrungen. Ich Weiss welche Schritte notwendig sind, machen werde ich es trotzdem nicht. Warum wohl ...

Templates in C++ sind Steinzeit im Vergleich zu D.

Und D im Vergleich zu Scheme, wo alles quasi AST ist?

knivil schrieb:

Und D im Vergleich zu Scheme, wo alles quasi AST ist?

Nicht ganz ebenbürtig, aber gleich mächtig.

Na, dass der Template-Code dafür nicht schön wird, damit rennst Du bei mir doch offene Türen ein. Ich sagte doch selber ein paar Posts davor, dass ich das allmählich zum Kotzen finde. Wo ich früher in C für jeden Typ wieder ne Linked-List geschrieben habe, schreibe ich inzwischen für jeden TMP-Algorithmus eine Template-Forward-Deklaration und X Spezialisierungen. Aber wenn man darüber jetzt noch versucht eine weitere Template-Abstraktionsschicht zu pflanzen setzt allmählich mein Gehirn aus.
Dein ursprünglicher Post klang nunmal aber so, als wärst Du der Meinung, es ginge gar nicht erst - obwohl es jetzt soooo aufwändig jetzt ja auch nicht ist, weil der Algorithmus recht handlich ist. Und Deine Antwort auf meine Antwort konnte ich dann nur noch so deuten, dass Du eine Lösung für das Problem suchst, das darin besteht, dass Template-Code für solcherlei Probleme viel zu kompliziert ist. Meine Antwort war darauf: Versichere dem Compiler, dass es terminiert, dann könnte der hypothetische Compiler das eigentlich, ohne dass man noch ein Deut an dem Code verändern müsste, der auch zur Laufzeit das gleiche tun würde. Fragt sich halt, wie oft man soetwas braucht. Aber so müsste man keine neue Template-Magie erfinden.