Re: [boost] [local] Help for the Alternatives section

Subject: Re: [boost] [local] Help for the Alternatives section
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-05-02 17:33:34

Mathias Gaunard-2 wrote:
> 
> On 02/05/2011 01:03, Lorenzo Caminiti wrote:
>> On Sun, May 1, 2011 at 6:46 PM, Mathias Gaunard
>> <mathias.gaunard_at_[hidden]>  wrote:
>>> On 26/03/2011 23:19, Lorenzo Caminiti wrote:
>>>>
>>>> Hello all,
>>>>
>>>> I am updating Boost.Local docs and I could use a some help in getting
>>>> the Alternatives section right
>>>>
>>>> http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html
> 

BTW, I have reduced Boost.Phoenix compile-time by #including only the
specific headers that I needed:

#include <boost/spirit/home/phoenix/statement/sequence.hpp>
#include <boost/spirit/home/phoenix/core/reference.hpp>
#include <boost/spirit/home/phoenix/core/argument.hpp>
#include <boost/spirit/home/phoenix/operator/arithmetic.hpp>

Boost.Phoenix still takes longer to compile but the comparison looks better
now.

>>>   - does not require listing all variables to bind from the scope
>>
>> This is captured under "Bind variables in scope" that for Boost.Lambda
>> reads "No (but variables in scope are accessible as usual within
>> expressions)." and for Boost.Phoenix the same plus "Yes (using let
>> which also allows to bind by constant reference)."
> 
> That's not what let is for.
> let is to declare new variables local to the function [*]. All variables 
> in scope are automatically caught as they're accessed with both 
> Boost.Lambda and Boost.Phoenix.
> 
> It should be Yes for all cases here, and whether the library requires to 
> user to explicitly list all variables or not should be made a separate 
> point.
> 

Yes, I am using let to create a local variable _f that binds factor as a
constant reference. Otherwise, variables are accessible as usual within
expressions.

I have changed the table row title to "Access variables in scope".
* For Boost.Phoenix reads "Yes (variables in scope are accessible as usual
within expressions). In addition, boost::phoenix::let can be used to bind by
constant reference".
* For Boost.Lambda reads "Yes (variables in scope are accessible as usual
within expressions)".
* For Boost.Local it reads "Yes. The variable names are repeated in the
function declaration so they can be bound by value, constant value,
reference, and constant reference (the object this can also be bound)".
* The Local and Global Functor approaches are the only one that cannot
access the variables in scope (programmers need to manually create member
variables to reference to the variables in scope in this case). 

> int BOOST_LOCAL_FUNCTION(int a1, bind int i)
> {
>     return a1 + i;
> }
> BOOST_LOCAL_FUNCTION_NAME(foo);
> 

You don't need to specify the bound variable type (that's automatically
deduced using Boost.Typeof like Boost.ScopeExit does):

int BOOST_LOCAL_FUNCTION(int a1, bind i)

>>> There is also the polymorphism thing: functions generated by Boost.Local
>>> are
>>> necessarily monomorphic, unlike Boost.Phoenix and global functors.
>>
>> Do you have a reference for this--like a WiKi page. I don't understand
>> this topic and I'd need to study it more before adding to the docs.
>> Thanks a lot.
> 
> Simply put, the function cannot take its arguments as template 
> parameters, and also requires that the types of the arguments be
> specified.
> 

As I mentioned, Boost.Local does not require to specify the bound variable
types (but you do have to specify the types of the normal function
parameters). For example:

double BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor,
            bind& sum) {

    BOOST_CONCEPT_ASSERT((Addable<BOOST_LOCAL_TYPEOF(sum)>));
    BOOST_CONCEPT_ASSERT((Multiplicable<BOOST_LOCAL_TYPEOF(factor)>));

    return sum += factor * num;
} BOOST_LOCAL_FUNCTION_NAME(add)

Question: Does this make Boost.Local local functions polymorphic in the
bound variables but monomorphic in function parameters? (Does this make any
sense... I don't know...)

> You might want to know that I plan on proposing allowing template member 
> functions in local classes for a future C++ standard TR (and polymorphic 
> lambdas, too).
> I think it is of utmost importance to be able to have polymorphic local 
> functions.
> 

I also think this feature would be valuable. Do you have any specific use
case in mind?

Thanks a lot.
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/local-Help-for-the-Alternatives-section-tp3408469p3491059.html
Sent from the Boost - Dev mailing list archive at Nabble.com.