[cfe-dev] [GSoC] "C++0x Lambda functions implementation" proposal
Nicola Gigante
nicola.gigante at gmail.com
Wed Mar 30 15:15:37 PDT 2011
Il giorno 30/mar/2011, alle ore 20.59, Jonathan Sauer ha scritto:
>
> One one hand, it seems simple: Just transform a lambda into a local struct, turn captured variables into
> attributes and initialize them in the local struct's constructor. Finally create an anonymous instance of
> this struct and use it in place of the lambda (a bit like it is described here:
> <http://stackoverflow.com/questions/3218821/c0x-lambda-overhead>).
>
Yes, this is the main idea, and also the main attractive power of C++ lambdas when compared
with other languages: there's no runtime overhead.
> (just ignore interaction with ObjC blocks. They are too different from each other)
The semantics of the two are very incompatible, especially regarding object lifetime issues.
However, someone expressed in the past the need for them to be at least partially compatible
(for example, being able to pass a lambda where a block is expected), so I think it is at least
worth thinking about it.
> On the other hand, clang is a really complex system, and C++ is a grotesquely complicated language, so
> the integration of lambdas into the compiler will be a lot more difficult than the simple transformation
> I outlined above. Therefore I wonder if you will have enough time to complete your implementation,
> especially if you're not proficient in clang. OTOH, IMO even a partial, but working and well-documented
> implementation still is better than none.
I think that with a fair amount of help from my mentor and the other members of the community I will
be able to complete the job. Also, this will be my thesis work, so I should receive support from my
thesis relator here at the university.
>
> Finally, when I read your first announcement on this list, I was very excited, because although I realized
> that other C++0x features such as rvalue references were far more needed than lambdas (they are, after all,
> "just" syntactic sugar), they are still useful (but why, oh why couldn't they be polymorphic?).
>
> So I say: Go for it! :-)
>
This positive opinion is very good news for me. Thank you :)
Anybody else has comments or suggestions about the proposal? If you think it's good enough
I'll submit it to melange in the next days.
>
> Jonathan
Bye,
Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110331/49010307/attachment.html>
More information about the cfe-dev
mailing list