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@ens-lyon.org> 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...
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-t... Sent from the Boost - Dev mailing list archive at Nabble.com.