Auswertungsreihenfolge

Ohhh, da habe ich noch einen riesigen Bock geschossen.
Ich pushe die konvertierten Argumente eines Funktionsaufrufes aus einem Variadic-Pack auf den Lua-Stack, und zwar folgendermaßen:

meta::expand_calls_hack((
 specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg)
,0)...);

Wobei Indices und arg die zusammengehörigen Variadic-Packs sind. Jetzt ist aber wahrscheinlich überhaupt nicht definiert, in welcher Reihenfolge die Aufrufe da getätigt werden und das spüre ich gerade am eigenen Leib: Die Argumente landen falschherum auf dem Stack.
Gibt es irgendeinen verwegenen Trick, ohne wieder auf rekursive Templates auszuweichen, um die Aufrufe in spezifizierter Reihenfolge durchzuführen?
Mir geht das so dermaßen auf den ****, mit C++-Templates Boilerplate-Code zu erzeugen, ich werd' noch verrückt.

Viele Grüße!

Columbo

Jetzt ist aber wahrscheinlich überhaupt nicht definiert, in welcher Reihenfolge die Aufrufe da getätigt werden und das spüre ich gerade am eigenen Leib: Die Argumente landen falschherum auf dem Stack.

Ja, das ist richtig. Funktionsargument-Auswertung ist unsequenced. Der GCC macht das AFAIR von Rechts nach Links.
Du musst sie irgendwo hinpacken, wo es definiert ist - beispielsweise eine Initialisierungsliste. Kannst du ein Array erzeugen, welches alle Rückgabewerte enthält? Dann kannst du dieses per indices auch wieder an meta::expand_calls_hack übergeben, Element für Element.

Hrmmm, leider nicht. Die Aufrufe sind alle void, geht alles nur in Richtung lua-Stack. Bevor ich jetzt aber anfange, der Sequenzierung halber überall einfach irgendetwas zurückzugeben, weiche ich dann doch lieber auf eine rekursive Formulierung der Sache aus. deci

Im Prinzip könnten die to_luas auch alle static sein, wollte ich nur kurz anmerken, der Ursprungscode stammt nur nicht von mir und das habe ich noch nicht über den verteilten Quellcode angepasst. Bei dem Code, mit dem ich angefangen habe, hat man nur nicht gesehen, wie schlecht er eigentlich ist, weil er wegen der Template-Magie und mangelnden Variadics einfach zu kompliziert war...

Und im Moment gewinne ich den Eindruck, dass Variadics einfach nur ein kolossales Fehldesign sind. Die taugen echt nur gut für die eine Sache: Das perfect Forwarding zu anderen C++-Funktionen. Ich frage mich, wie's eine Grammatik-Änderung, die nur in einem Fall überhaupt gut funktioniert, durch den Standardisierungsprozess geschafft hat.
Give me mixins, please!

Columbo

Die Aufrufe sind alle void

Aber wenn sie keine Rückgabewerte haben, dann nimm doch gleich eine Ausdrucksliste!

bool unused = (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg)..., false);

Bei Ausdruckslisten ist es garantiert, das alle Seiteneffekte des linken Ausdrucks vor dem rechten geschehen.

Hätte mir gleich einfallen müssen, ich habe das ,0) übersehen.

Oha! *ausprobier*

Arcoth schrieb:

Die Aufrufe sind alle void

Aber wenn sie keine Rückgabewerte haben, dann nimm doch gleich eine Ausdrucksliste!
bool unused = (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg)..., false);
Bei Ausdruckslisten ist es garantiert, das alle Seiteneffekte des linken Ausdrucks vor dem rechten geschehen.

Seit wann ist das garantiert?

camper

Arcoth schrieb:

Die Aufrufe sind alle void

Aber wenn sie keine Rückgabewerte haben, dann nimm doch gleich eine Ausdrucksliste!
bool unused = (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg)..., false);

Das ist keine Ausdrucksliste, sondern bloß ill-formed.

Columbo

N3337 §5.18/1 schrieb:

A pair of expressions separated by a comma is evaluated left-to-right [...]. Every value computation and side effect associated with the left expression is sequenced before every value computation and side effect associated with the right expression.

Das ganze trifft rekursiv auch auf Listen mit mehreren Elementen zu.

camper schrieb:

Arcoth schrieb:
Die Aufrufe sind alle void

Aber wenn sie keine Rückgabewerte haben, dann nimm doch gleich eine Ausdrucksliste!
bool unused = (specialized_converter_policy_n<Indices, Zeug>().to_lua(L,arg)..., false);
Das ist keine Ausdrucksliste, sondern bloß ill-formed.

Sind denn Pack-Expansions da nicht erlaubt?

In dem Fall geht natürlich auch

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

, hier ist dann (dank Initialisierungsliste) auch definiert, dass alles von Links nach Rechts ausgewertet wird.

~Edit: Begriff korrigiert.~

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.