Elemente an Funktionspointer mit variabler Anzahl an Argumenten forwarden

Nathan

...richtig schwer einen passenden Titel zu finden.
Also, was ich habe ist folgendes:

template <typename Ret, typename ... Args>
            void trampoline_function(Ret (*fnc) (Args...), iterator iter)
{
   auto result = fnc(iter.get<Args>()...);
   ...
}

fnc wird mit den Argument aufgerufen, auf das iter zeigt. iterator ist dabei ein Iteratortyp, der über rohen Speicher iteriert und ihn dabei entsprechend dem Templateargument interpretiert*. Das Problem ist jedoch, dass der iterator bei jedem Aufruf von get bewegt wird. Und die Auswertungsreihenfolge von Funktionsargumenten ist dummerweise nicht spezifiziert, weswegen ich hier Probleme bekomme.
Wie mache ich das, dass der erste Aufruf von get() mit dem ersten Argument der Funktion übereinstimmt und der zweite mit dem zweiten etc.?
Ich muss die Argumente schätz ich mal i-wie in einem Tuple zwischenspeichern, dass ich dann initialisiere und dann wieder auspacke, oder? Aber dafür bin ich zu blöd.

*Auch wenn das jetzt nicht ganz so schön klingt: der Teil funktioniert einwandfrei.

ScottZhang

Wozu überhaupt dieser Iterator?

template <typename Ret, typename ... Args>
            void trampoline_function(Ret (*fnc) (Args...), Args&&... args)
{
   auto result = fnc(std::forward<Args>(args)...);
   ...
}

Oder darf trampolin_function nur zwei Argument haben?

Nathan

Nee, der Iterator ist leider notwendig. Mir liegen die Argumente nämlich nur in roher Speicherform vor. Ich muss die konvertieren und an die Funktion weiterleiten. Die Konvertierung erledigt der Iterator und die Weiterleitung die Trampolin-Funktion. Da hakts aber.

camper

Die Idee ist aber nicht verkehrt

template <typename Ret, typename ... Args>
            void trampoline_function(Ret (*fnc) (Args...), iterator iter)
{
   struct helper
   {
       helper(Ret (*fnc) (Args...), Args&&... args)
          : ret(fnc(std::forward<Args>(args)...))
       {}
       Ret ret;
   } help{iter.get<Args>()...};
   auto result = help.ret;
   ...
}

Nathan

Und dabei ist die Ausführungsreihenfolge garantiert?
Wenn ja, dann danke!

Columbo

Nathan schrieb:

Und dabei ist die Ausführungsreihenfolge garantiert?

Natürlich. Der Trick ist so einfach, ich dachte, da wärst du locker selbst drauf gekommen - in Initialisierungslisten ist es klar definiert, unabhängig vom Kontext:

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.
[ Note: This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the initializer-list are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the arguments of a call. — end note ]