Auswertungsreihenfolge

Ja naja, ich hatte eben schon ein Posting mit den entstehenden Fehlermeldungen vorbereitet, aber das hat sich jetzt wohl erübrigt. So bekomme ich das, auch nach Spielereien mit zusätzlichen Klammern, nicht kompiliert. Die Fehlermeldungen sind aber reichlich nichtssagend in VC++2013.
Ich warte besser kurz ab, was ihr da gerade ausklamüsert? Danke auf jeden Fall schon für die Mühen!

Columbo

Ja, natürlich, Pack-Expansions sind in so einer Situation nicht erlaubt.

Ich warte besser kurz ab, was ihr da gerade ausklamüsert?

Obige Variante mit dem Array wird definitiv funktionieren.

Edit: Es gibt eine Ausnahme: Es muss mindestens ein Element geben. Daher ergänze das am Besten zu

bool unused[]{ (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg), false)..., false };

decimad schrieb:

Ich warte besser kurz ab, was ihr da gerade ausklamüsert?

Da gibt es nichts zum ausklamüsern, der Sachverhalt ist absolut klar und bekannt. Es gilt halt wie immer, nicht auf Sone zu hören.

struct variadic_expression {
  template <typename... A>
  variadic_expression(A&&...) {}
};

variadic_expression{ (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg), false)..., };

Mit der Array-Variante habe ich auch gerade Probleme, er sagt mir, dass er kein konstantes Array mit Größe 0 erzeugen könnte, was ich jetzt aber so auch nicht ganz nachvollziehen kann, immerhin ist doch dort mindestens ein Element?

@loooool: Aber das ist doch jetzt wieder ein Aufruf eines Konstruktors mit der Eigenschafft, dass die Auswerungsreihenfolge der Argumente nicht spezifiziert ist?

Zumindest sieht es für mich gerade so aus, als wäre das genau, was meine expand_calls_hack-Funktion machte. Bringt hier der Einschluss in ein struct überhaupt irgendetwas?

decimad schrieb:

@loooool: Aber das ist doch jetzt wieder ein Aufruf eines Konstruktors mit der Eigenschafft, dass die Auswerungsreihenfolge der Argumente nicht spezifiziert ist?

Wenn der Konstruktor mit {} aufgerufen wird, ist die Auswertungsreihenfolge spezifiziert, sonst nicht. (Find ich total inkonsistent.)

Columbo

Es gilt halt wie immer, nicht auf Sone zu hören.

Hören wir lieber auf den Typen, der Ausdruckslisten nicht kennt.

@loooool: Aber das ist doch jetzt wieder ein Aufruf eines Konstruktors mit der Eigenschafft, dass die Auswerungsreihenfolge der Argumente nicht spezifiziert ist?

Doch, das ist es. Weil man hier Initialisierungslisten (die {}-Syntax) nutzt. Man kann aber auch (aus Versehen?) () verwenden, und es kompiliert durch. Das kann bei Arrays nicht passieren.

Mit der Array-Variante habe ich auch gerade Probleme, er sagt mir, dass er kein konstantes Array mit Größe 0 erzeugen könnte, was ich jetzt aber so auch nicht ganz nachvollziehen kann, immerhin ist doch dort mindestens ein Element?

So ist es, es ist völlig richtig.

template<int... i>
void foo()
{
	bool unused[]{ (i, false)..., false };
}

int main()
{
	foo<>();
}

Ist genauso legal.

Ist Arcoth = Sone? Wurde er gesperrt?

Columbo

out schrieb:

Ist Arcoth = Sone? Wurde er gesperrt?

Nein, wieso auch? :p Ich habe nur wegen den Wortwitzen den Account gewechselt.

Tjaja, jetzt hätte ich theoretisch eine Lösung des Problems, aber praktisch muss ich dann wohl doch die Rekursion verwenden. Auch wenn ich VC++ jetzt ganz klar die Schuld dafür gebe, so gebe ich C++ die Schuld dafür, dass man überhaupt solch dämlich kleinkarierten Regeln, die sich in irgendeinem Subparagraphen als Spezialisierung eines anderen Subparagraphen ergeben, ausnutzen muss, um X Aufrufe in Reihenfolge aus einem Variadic-Pack zu generieren...

Arcoth schrieb:

out schrieb:

Ist Arcoth = Sone? Wurde er gesperrt?

Nein, wieso auch? :p Ich habe nur wegen den Wortwitzen den Account gewechselt.

Marcus kann einen auch umbenennen. Musst nur freundlich fragen.

camper

loooool schrieb:

decimad schrieb:

@loooool: Aber das ist doch jetzt wieder ein Aufruf eines Konstruktors mit der Eigenschafft, dass die Auswerungsreihenfolge der Argumente nicht spezifiziert ist?

Wenn der Konstruktor mit {} aufgerufen wird, ist die Auswertungsreihenfolge spezifiziert, sonst nicht. (Find ich total inkonsistent.)

gcc setzt das allerdings bis jetzt nicht um.

Columbo

Auch wenn ich VC++ jetzt ganz klar die Schuld dafür gebe

Du versuchst so etwas mit VC++ umzusetzen!?

gcc setzt das allerdings bis jetzt nicht um.

Ja, leider, selbst der neueste nicht:

#include <iostream>

struct A
{
	template<typename... Args>
	A(Args&&...){}
};

int main()
{
	int a = 0;
	A{++a, a*=2};
	std::cout << a;
}

Sollte eigentlich 2 ausgeben, es gibt jedoch 1 aus. Clang macht es richtig.

out schrieb:

Arcoth schrieb:

out schrieb:

Ist Arcoth = Sone? Wurde er gesperrt?

Nein, wieso auch? :p Ich habe nur wegen den Wortwitzen den Account gewechselt.

Marcus kann einen auch umbenennen. Musst nur freundlich fragen.

Hat er ja auch! Vorher war ich der *. Ich wollte nur Sone nicht umbenennen, da das zu viel Verwirrung bezüglich alten Threads gestiftet hätte.

@loooool: VC++ kompiliert das, aber setzt diese Regel genausowenig um

Hoffentlich kommt D irgendwann in Schwung, es wird Zeit! Im Moment frickeln sie ja noch an den Allokatoren und anderen grundlegenden Sachen herum, so richtig gesetzt hat sich die Sprache noch nicht.

Hab mal in der Bug-Database von Microsoft rumgeschaut, die werden das laut deren Aussage im gesamten VS 2013 Produkzyklus nicht ausbessern.

Columbo

decimad schrieb:

Hab mal in der Bug-Database von Microsoft rumgeschaut, die werden das laut deren Aussage im gesamten VS 2013 Produkzyklus nicht ausbessern.

Und die Variante mit dem Array lässt sich nicht "beheben"? Das false vielleicht an den Anfang setzen? Vielleicht zwei false einfügen?

Tatsächlich ist es aber ein völlig hirnloses Unterfangen, mit VC++ solche Templates zu verwenden. Das ist eine Totgeburt.

Edit²: Gut, ich werde dir nicht direkt Clang empfehlen, aber mindestens einen Compiler-Wechsel schon. Mit VC++ wirst du permanent gebremst werden.

MS kriegt den 2013er Compiler nicht mehr in den Griff. Zuviel gefrickelt - zu wenig Test-Cases

Ich seh' halt nur beide Seiten der Sache. Ja, die Jungs bei Microsoft sind ganz offensichtlich überfordert, nicht zwangsläufig intellektuell, aber mindestens mal an Man-Power. Aber das kommt eben auch dadurch, dass C++ einfach unverhältnismäßig viel Ballast mit sich rumträgt - wovon vieles schlechte Entscheidungen waren, sodass neue Zusätze immer komplizierter daherkommen, als sie für das Problem, das sie lösen sollen, sein müssten. Darunter haben aber nicht nur die Compiler-Entwickler zu leiden, sondern auch die Endanwender der ganzen Sache (zum Beispiel so Leute wie ich, die ohne eure Hilfe alle Paragraphen des Standards auswendig können müssten, um etwas total banales umzusetzen).

Ich werde morgen früh beim Kaffee eine halbe Stunde lang versuchen, das irgendwie mit der Array-Sache zum laufen zu bringen, danach gebe ich es auf, ich habe nicht endlos Zeit.

Wenn ich nicht gerade wegen dieser Entwicklung auf Windows und C++ festgenagelt wäre, genügend Zeit zur Einarbeitung hätte und neu anfangen könnte, dann würde ich nicht nur den Compiler wechseln, sondern auch die Sprache. Oder vielleicht auch die Branche Aber dazu ist's im Moment ein paar hundert tausend Codezeilen zu spät.