<![CDATA[Argumente weiterleiten]]>Hallo!
Ich möchte nur kurz zwischenfragen ob ich hier den richtigen Weg einschlage.
Ich habe eine (Template-)Funktion, die einen externen Aufruf tätigt, für den es bei bestimmten Typen keinen Sinn ergibt, nicht-const-Referenzen als Argumente zu übergeben. Damit fällt ja Perfect-Forwarding schonmal aus dem Rennen.
Drum kurz die Zwischenfrage: Es ist gängige und akzeptierte Praxis, in solch einem Fall die Argumente als Wert-Typen anzunehmen, und std::ref bzw. std::cref zu verwenden, falls der aufrufende Code per Referenz übergeben möchte, ja?
Zumindest habe ich das so bei std::bind und verschiedentlichen stl-Algorithmen, die Funktoren akzeptieren, beobachtet.
Möchte nur nicht, dass ich irgendjemanden überrasche, wenn ich das hier jetzt so implementiere.
Die alternative wäre, dass der Client-Code static_cast benutzt, um const-Referenzen zu erwirken.

Viele Grüße

]]>https://www.c-plusplus.net/forum/topic/320807/argumente-weiterleitenRSS for NodeThu, 23 Jul 2026 20:46:58 GMTSun, 13 Oct 2013 12:57:24 GMT60<![CDATA[Reply to Argumente weiterleiten on Sun, 13 Oct 2013 12:57:24 GMT]]>Hallo!
Ich möchte nur kurz zwischenfragen ob ich hier den richtigen Weg einschlage.
Ich habe eine (Template-)Funktion, die einen externen Aufruf tätigt, für den es bei bestimmten Typen keinen Sinn ergibt, nicht-const-Referenzen als Argumente zu übergeben. Damit fällt ja Perfect-Forwarding schonmal aus dem Rennen.
Drum kurz die Zwischenfrage: Es ist gängige und akzeptierte Praxis, in solch einem Fall die Argumente als Wert-Typen anzunehmen, und std::ref bzw. std::cref zu verwenden, falls der aufrufende Code per Referenz übergeben möchte, ja?
Zumindest habe ich das so bei std::bind und verschiedentlichen stl-Algorithmen, die Funktoren akzeptieren, beobachtet.
Möchte nur nicht, dass ich irgendjemanden überrasche, wenn ich das hier jetzt so implementiere.
Die alternative wäre, dass der Client-Code static_cast benutzt, um const-Referenzen zu erwirken.

Viele Grüße

]]>https://www.c-plusplus.net/forum/post/2359942https://www.c-plusplus.net/forum/post/2359942Sun, 13 Oct 2013 12:57:24 GMT<![CDATA[Reply to Argumente weiterleiten on Sun, 13 Oct 2013 13:16:59 GMT]]>Du verwechselst da was:
std::bind und so speichern die Argumente und leben potentiell länger als der Scope des Aufrufers. Deshalb darf da kein perfect forwarding geschehen.

In deinem Fall hingegen geschieht forwarding und da erwarte ich perfect forwarding. Wenn es schlimm ist, falls eine r-value übergeben wird (ist zwar unlogisch, weil rvalues an const-ref binden), dann mach ein static_assert.

]]>https://www.c-plusplus.net/forum/post/2359948https://www.c-plusplus.net/forum/post/2359948Sun, 13 Oct 2013 13:16:59 GMT<![CDATA[Reply to Argumente weiterleiten on Sun, 13 Oct 2013 13:45:13 GMT]]>Der Call geht in Lua rein und es gibt Konverter, die direkt auf native Lua-Typen konvertieren, das ist einfach ein Design-Tradeoff. Da Lua keine Referenzen unterstützt, habe ich es für die nativen Typen per static_cast unterbunden, dass diese beim Aufruf sowie bei gebundenen Funktionen als nicht-const-Referenzen in der Signatur auftauchen, weil ich niemals das umsetzen kann, was der C++-Kodierer im ersten Momente erwartet.
Mit allen anderen Typen kann Lua sowieso nichts direkt anfangen (außer halt per Meta-Table), daher ist hier die Übergabe per Referenz wunderbar möglich, Lua dient hier nur als "Mediator".

Das habe ich gemeint mit "es ergibt keinen Sinn". So wie es im Moment ist, packt der Aufrufer dort irgendein benanntes nativ-Objekt als Argument hin und ihm fliegt ein static_assert um die Ohren, falls er das Objekt nicht irgendwie so castet, dass beim perfect forwarding eine const-Referenz entsteht.

]]>https://www.c-plusplus.net/forum/post/2359954https://www.c-plusplus.net/forum/post/2359954Sun, 13 Oct 2013 13:45:13 GMT