Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
C++11 Lambda expressions und Closures
25 views
Skip to first unread message
Martin Häfner
Feb 22, 2012, 5:33:08 AM2/22/12
to
Hallo,
ich würde gerne wissen ob es irgendwie möglich ist den Kontext einer
Lambda Funktion beim Aufruf eine freien Funktion zu konservieren ohne
ihn als expliziten Aufrufparameter angeben zu müssen. Beispiel:
int aVar;
void func()
{
// aVar ist immer vom globalen Kontext, nicht aus der Closure?!
}
auto f = [aVar](){ func(); };
f();
aVar ist innerhalb des Lambdaausdrucks eine Kopie, beim Aufruf von
func() springt man aber wieder auf die globale Variable?!
Danke,
Martin
ich würde gerne wissen ob es irgendwie möglich ist den Kontext einer
Lambda Funktion beim Aufruf eine freien Funktion zu konservieren ohne
ihn als expliziten Aufrufparameter angeben zu müssen. Beispiel:
int aVar;
void func()
{
// aVar ist immer vom globalen Kontext, nicht aus der Closure?!
}
auto f = [aVar](){ func(); };
f();
aVar ist innerhalb des Lambdaausdrucks eine Kopie, beim Aufruf von
func() springt man aber wieder auf die globale Variable?!
Danke,
Martin
Daniel Krügler
Feb 22, 2012, 4:49:56 PM2/22/12
to
beschreibe daher
einfach die Lage der Dinge: Wenn du einen Lambda-Ausdruck definierst,
sind
als Captures *nur* Variablen mit automatischer Speicherlebensdauer
zulässig.
Alle globalen Variablen werden *nicht* "eingefangen" oder kopiert. Es
ist
auch *ungültig*, diese damit einfangen zu versuchen.
So wie du deinen Lambda-Ausdruck geschrieben hast, sollte er ungültig
sein:
aVar ist eine globale Variable und daher nach aktuellen Sprachregeln
nicht
"einfangbar", [expr.prim.lambda] p10:
"each such lookup shall find a variable with automatic storage
duration declared
in the reaching scope of the local lambda expression."
Wenn du so die gleiche Wirkung erzielen willst, musst du dir in einem
lokalen
Kontext die globale Variable in einer lokalen Variablen abspeichern
und die
lokale Variable einfangen, z.B.
int aVar;
void func() {
int copy_of_aVar = aVar;
[copy_of_aVar] { /*..*/ }
}
Es wäre allerdings nicht möglich, einen Lambda-Ausdruck im Namensraum
zu definieren und dort eine *Kopie* einer anderen Namensraum-
Variablen
einzufangen. Wenn du tatsächlich so etwas vorhast, beschreibe doch
bitte
genauer deinen Anwendungsfall. Mir ist nämlich schleierhaft, was du
damit erreichen willst.
Besten Gruss aus Bremen,
Daniel Krügler
Daniel Krügler
Feb 23, 2012, 2:49:29 AM2/23/12
to
On 22 Feb., 22:49, Daniel Krügler <daniel.krueg...@googlemail.com>
wrote:
Variablen
auch noch 'this' einfangen kann, wenn man den Lambda-Ausdruck in einer
nicht-statischen Elementfunktion erzeugt. Diese Spezialregel ändert
aber nichts
an deinem Beispiel in Bezug auf Variablen im Namensraum.
wrote:
> Ich bin nicht sicher, ob ich deine Frage verstanden habe. Ich
> beschreibe daher einfach die Lage der Dinge: Wenn du einen Lambda-Ausdruck
> definierst, sind als Captures *nur* Variablen mit automatischer Speicherlebensdauer
> zulässig.
Als Nachtrag sei noch angemerkt, dass man neben automatischen
> beschreibe daher einfach die Lage der Dinge: Wenn du einen Lambda-Ausdruck
> definierst, sind als Captures *nur* Variablen mit automatischer Speicherlebensdauer
> zulässig.
Variablen
auch noch 'this' einfangen kann, wenn man den Lambda-Ausdruck in einer
nicht-statischen Elementfunktion erzeugt. Diese Spezialregel ändert
aber nichts
an deinem Beispiel in Bezug auf Variablen im Namensraum.
0 new messages