Sind lambda-capture Variablen Member?

[happystudent]

kkaw schrieb:

Quasi ja. In deinem Fall sähe das ungefähr so aus:

Ach so, so wird das quasi kompiliert? Gut dann macht es Sinn, hatte mich schon gewundert^^

kkaw schrieb:

Was ich hier komisch finde, ist nur, dass Du vec statt vec_ bei add_up verwendest. Vielleicht wolltest Du vec gar nicht implizit "capturen" und nur mit vec_ arbeiten?

Die Initialisierungsmechanik habe ich mir hier mal mit "..." ausgespart.

Äh ja, das war nur ein Minimalbeispiel, kann gut sein dass das nicht so viel Sinn macht

Danke auf jeden Fall

[Columbo]

Lambdas haben einen sogenannten closure-Typ. Dieser ist eine Klasse, welche fuer alle gecaptureten Entitaeten einen entsprechenden Member haelt und einen ueberladenen operator() bereitstellt (seit C++14 gibt es polymorphe Lambdas, welche diesen Operator mit einem Template ueberladen).

Die Member haben demnach genau die Typen, die im lambda-capture auf sie zutreffen, je nachdem wie sie gecaptured wurden. In deinem Fall wurden sie implizit vom & gecaptured, demnach sind die entsprechenden Member Referenzen.

Spricht man bei einem Lambda überhaupt von "Membern"?

Nein, das tut man nicht.

Ach so, so wird das quasi kompiliert?

Lambdas sind keine Praeprozessoranweisungen o.ae., die Lambdas werden dazu umgeformt - also ja, praktisch wird es so im Endeffekt kompiliert. Wobei natuerlich der Compiler noch optimieren kann.

[happystudent]

Wieder was gelernt, das mag ich an diesem Forum

[kkaw]

apropos optimieren: eine naheliegende optimierung wäre, mehrere referenzen auf stackvariablen zu einer zusammen zu fassen (stack frame pointer) und dann die einzelnen Variablen per zur Compilezeit bekanntem Offset anspringen. Aber das macht AFAIK der Microsoft-Compiler noch nicht. Ob das in der 2013 Version besser ist, weiß ich nicht. Diese Optimierung reduziert dann auch die Größe eines solchen Lambda-Objekts. Wer VS 2013 hat, soll das mal bitte testen. Ich wüsst' gerne, ob die das inzwischen eingebaut haben.

[happystudent]

Hm, wenn du mir sagst wie man das testen kann, kann ich das gerne machen...

[kkaw]

http://ideone.com/DvqRQU

Der GCC scheint das auch noch nicht zu können. Die 12 lässt sich durch drei 32-bit-Zeiger erklären. Wenn es nur ein stack-frame-pointer gewesen wäre, würde man hier 4 oder 8 sehen (bei 32- oder 64-bit system).

[Arcoth_logoff]

Du weisst schon, dass sizeof die Groesse des referenzierten Typs zurueckgibt, ja?

[kkaw]

ja, weiß ich. wollte nur klar machen, was da passiert.

[hustbaer]

Ich denke Arcoth meint dass das remove_reference unnötig ist.
Die Referenzen werden aber anscheinend wirklich nicht zusammengefasst:
http://ideone.com/5LQfwE

[kkaw]

hustbaer schrieb:

Ich denke Arcoth meint dass das remove_reference unnötig ist.

Beides war mir bewusst (dass er das meinte und dass es so ist).

hustbaer schrieb:

Die Referenzen werden aber anscheinend wirklich nicht zusammengefasst:
http://ideone.com/5LQfwE

Echt schade; denn kleine Lambda-Objekte haben schon was. Sie würden z.B. eine Small-Funktion-Optimization bei std::function triggern.

[camper]

gcc hat ein bug dafür. Macht allerdings nicht den Eindruck, als ob jemand daran arbeitet.

[hustbaer]

Das wird schon werden.
Wenn ich mir so überlege was GCC und Clang in den letzten ~5 Jahren weitergebracht haben, das ist schon krass.
Lambdas sind ja doch noch relativ "neu" bei C++, und C++11 Feature-Complete bzw. C++14 Feature-Complete hatten vermutlich mal Vorrang.