Re : [local_function] any interest in a LocalFunction library?
Lorenzo Caminiti wrote :
Is there interest in a library that implement local functions for C++?
One year ago, I made a proposition for a boost.breakable. Some people were interested in the library, if I could widen it a little. David Abraham & Vicente Botet expressed interest in a macro local function that would work like scope exist. So I wrote a first implementation. But I have not posted back on this subject, because I was unsure about the macro interface, since a few variations on its interface (ex: passing this or not) could be done. Here I send 2 little examples of my tests. The 'V3' is almost the same as the one you posted. The 'V4' is a try wich uses only 1 macro call. Unfortunately, these 2 use currently __VA_ARGS__, and were only tested on visual 2008. But yes, there is an interest in a local function. Best, Pierre Morcello
On Mon, Aug 23, 2010 at 7:48 AM, Pierre Morcello <pmorcell-cppfrance@yahoo.fr> wrote:
Lorenzo Caminiti wrote :
Is there interest in a library that implement local functions for C++?
One year ago, I made a proposition for a boost.breakable. Some people were interested in the library, if I could widen it a little. David Abraham & Vicente Botet expressed interest in a macro local function that would work like scope exist.
So I wrote a first implementation. But I have not posted back on this subject, because I was unsure about the macro interface, since a few variations on its interface (ex: passing this or not) could be done.
Here I send 2 little examples of my tests. The 'V3' is almost the same as the one you posted. The 'V4' is a try wich uses only 1 macro call. Unfortunately, these 2 use currently __VA_ARGS__, and were only tested on visual 2008.
But yes, there is an interest in a local function.
I can implement Boost.LocalFunction macros, which are similar to your 'V3' macros, in pure C++ ISO standard (no __VA_ARGS__). I will study your code more. On Sun, Aug 22, 2010 at 9:27 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
On 8/22/2010 6:01 PM, OvermindDL1 wrote:
On Sun, Aug 22, 2010 at 11:18 AM, Mathieu -<ptr.jetable@gmail.com> wrote:
I might be totally wrong here but I don't see how it's different from lambdas...
What can it do differently from boost::phoenix? I am guessing you just create and instance a struct right there, but boost::phoenix would be more succinct.
Except Boost.Phoenix isn't as expressive as "real" C++, is it? E.g., local variables are somewhat clumsy (opinion) in the current incarnation of Boost.Phoenix.
Also, it seems reasonable to implement BOOST_LOCAL_FUNCTION in terms of lambdas if they exist, but perhaps one would want to use local functions on non-lambda-enabled compilers.
I am NOT an expert of Boost.Phoenix and Boost.Lambda so *please correct me if I am wrong*. 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...). 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. 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. -- Lorenzo
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).
participants (3)
-
Lorenzo Caminiti -
Mathias Gaunard -
Pierre Morcello