On 15/10/11 09:19, Piotr Beling [qwak] wrote:
> W dniu 14.10.2011 23:14, Ben Stott pisze:
>
>> > Under VS, what (recent) feature of C/++*does* work?;-)
> I'am not a user, but I read that lambdas works (but always as objects).
>
From a "standard" argument (i.e. the c++ standard, not the argument
type) a lambda is converted into an object, so this is behaviour I'd
expect. MSVS 10 doesn't allow "capture groups" - i.e. the following:
typdef int (*function)();
function = [] () -> {return 4;};
function();
Because the "capture" (the []) doesn't contain anything specific, this
can be converted to a straight function pointer. MSVS 10 doesn't allow
this because it converts _everything_ to an object, but this is going to
be changed in MSVS 11, from all accounts.
>> > If anything, it'll be easier to use std::function - and if it really
>> > needs to happen this is more likely the option that would be looked at,
>> > as it does not require the use of any extra external libraries.
> But require TR1 or C++11 (or boost). But this is still good idea,
> because most compilers implements TR1 from longer time.
>
Yeah, it's part of C++11 - which is what the whole discussion here is about!
TR1 was never really a standard, and just about 90% of its features were
absorbed into C++11, so any compiler that has/had TR1 will fairly soon
have these features in the std namespace rather than std::tr1.
> Also signal/slot libs. shouldn?t be a big problem... most are header
> only libraries, some signal/slot libs are 1 (or 2) header(s) file only.
> Signal/slot libs gives one extra bonus: one than more call-back can be
> added at one time.
Hmm, I do like the last point. Perhaps to this end maybe you can submit
an RFE for multiple callbacks - one based on each different when()
condition (which is really the only use I can think of). One day one of
us will get around to it!
>> > The
>> > Callback typedef would only have to be modified to std::function<void
>> > (Widget*, void*)>, and everything should continue to work with the added
>> > bonus of lambdas now working, amongst other things.
> Yes, probably it will work in most cases.
>
> Probably it is better to finally have std::function<void(Widget*)>, or
> even std::function<void()>.
> Still it is possible to write callback(old_callback_type, void*) method.
>
> In all cases there is no way to get old_callback_type from
> std::function, so:
> old_callback_type callback()
> will be very hard to implement.
I suppose this is true - it would certainly make this job somewhat
difficult, though I suppose (if we're talking about c++11) the magic of
"auto" is such that this problem will disappear!
On 15/10/11 09:31, Ian MacArthur wrote:
> And really apropos of nothing...
Well, let's just consider this a hypothetical discussion ;-)
> There are already several alternate callback-replacement mechanisms extant
> specifically for fltk, several of which could easily be absorbed into the
> fltk core if we so wished, and which (in at least a few cases!) could be
> persuaded to work with lambda functions.
>
> If we want to go that way.
This is true, I guess. Though I suppose any "real" discussion on the
future of FLTK should be in fltk.general, and would have to be far more
thorough than what's going on above. This was really a question that's
beginning to get way out of hand!
> For my part, given my target architectures, I'm a long way from C++11
> support, for a few years yet.
>
> Let's get what we have working right, before we get too distracted by the New
> Hotness...
>
Most compilers are probably like this, to be honest. GCC is really the
only one that's close to any form of support.
Admittedly, there are still compilers out there that struggle to support
c++99, let alone c++11, so this discussion is a long way premature yet!
Ben
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
