On 23/08/10 13:07, Lorenzo Caminiti wrote:
I think the main different between using Boost.Phoenix or Boost.Lambda and using Boost.LocalFunction is that in Boost.LocalFunction the local function body completely retains C++ syntax (a part from using `this_` instead of `this`... which is not ideal...).
That's not all: - Defining a LocalFunction must be done at statement level, while Phoenix can define functions at expression level, - Local classes may not have template member functions, which prevent LocalFunction from defining polymorphic functions. Those two limitations are pretty huge and severely impact the usefulness of LocalFunction.
Now this might or it might not be a problem. For example, in my Boost.Contract application I need the users to write the local function body and pass it to a macro so it is a requirement for that body to be written in usual C++ because I cannot request Boost.Contract users to learn Boost.Phoenix or Boost.Lambda. However, for other applications using Boost.Phoneix or Boost.Lambda might be fine.
Having your macro take a function object does not require the user to use one specific tool or another to generate it.
I think C++0x lambdas will be a valid option in replacing Boost.LocalFunction but they are only part of *new* C++ standard and not supported by all compilers.
Right, it doesn't offer anything more than C++0x lambdas do (which are quite limited already).