If it's any consolation, MSVC 2010 apparently doesn't supply the function pointer conversion, so I need to amend my statement to include verbiage along the lines of "with standard conforming compilers...".

If it's any consolation, MSVC 2010 apparently doesn't supply the function pointer conversion, so I need to amend my statement to include verbiage along the lines of "with standard conforming compilers...".

To be honest, MSVC 2010 is before the C++11 standard was even finalized, and even now the C++11 standard as only just published a little while ago. So its not really appropriate to be complaining about it not being standards compliant with C++0x functionality when said standard didn't even exist.

That being said, the lack of a lambda => function pointer conversion for non-capture lambdas is kind of annoying, but not something I encounter overmuch, as I tend to avoid bare function pointers ANYWAYS.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.ScapeCode - Blog | SlimDX

The type of a lambda function is a unique anonymous functor type for every lambda function. Two separate lambdas that have the exact same definition in the exact same scope will have two separate types. As such, trying to get at the exact type of a lambda function is an exercise in futility. Just store the std::function by value.

I'm probably going to get bashed - again - for stating my thoughts but... why not to just autobox them to an appropriate std::function at this point?I mean, really, I feel that a bit rough. It's just me.

The type of a lambda function is a unique anonymous functor type for every lambda function. Two separate lambdas that have the exact same definition in the exact same scope will have two separate types. As such, trying to get at the exact type of a lambda function is an exercise in futility. Just store the std::function by value.

I'm probably going to get bashed - again - for stating my thoughts but... why not to just autobox them to an appropriate std::function at this point?I mean, really, I feel that a bit rough. It's just me.

In C++, what you don't use, you don't pay for. If you are not using std::function, and since it can't anyways as that's not in the language spec, you don't have to pay for std::function. Furthermore, if it DID do something silly like that (and it is quite silly) it would require an implicit inclusion of the <functional> header.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.ScapeCode - Blog | SlimDX

Note that the way std::function is defined more or less requires a heap allocation, so this additional cost would be non-trivial. Besides which, std::function does not have an implicit conversion to a function pointer in case of not capturing variables. That's not something you can add to std::function because it would require the type to have different static behavior based on dynamic information.