On 10/10/11 14:48, Ben Stott wrote:
> You might actually have a bit of difficulty using a lambda function as a
> callback, because to use some of their more powerful features (like
> taking variable callback data) I *think* the FLTK callback functions
> will have to be modified slightly. However, if I abuse the language for
> a little bit, something like this *should* work (read: code is
> completely untested and will not compile - it's an example and that is
> left as an exercise for the reader!):
>
> my_button1("Button!")
> my_button2.callback(<>(Fl_Widget* w) -> void {my_button1.label("No soup
> for you");});
>
> You probably couldn't use "auto" as the return type here (nor decltype),
> as I think FLTK explicitly expects void, but you can theoretically do
> anything you want if you twist the function in the right way. Note that
> you can use it to call my_button1.label because of the magic of lambdas
> (they're translated into objects to make this possible)
Cool.
I see, so although the above is untested, I take it the implication
is variables (and perhaps methods) within the scope of the
lambda's declaration will automatically be available whenever
the lambda is invoked?
So perhaps, if this code were all in a class, do you think the
lambda code would have access to the class instance's variables/methods
auto-magically? eg:
class MyClass : public Fl_Window {
Fl_Button *my_button1;
Fl_Button *my_button2;
..
MyClass() {
..
my_button2->callback( <>(Fl_Widget*w) -> void
{my_button1->label("xxx");} ); // <-- 'my_button1' visible?
..
}
};
If something like that works, I imagine the language handles
preserving 'this' so that it's set invisibly whenever the
lambda is called, which syntactically would be very neat-o.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
