Boost logo

Boost :

Subject: Re: [boost] [local] Review
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-11-22 21:32:42

On 19/11/11 01:59, Lorenzo Caminiti wrote:
> On Fri, Nov 18, 2011 at 6:53 PM, John Bytheway
> <jbytheway+boost_at_[hidden]> wrote:
>> How feasible would it be to allow overload to be used without declaring
>> all the function types. So, your example:
>> boost::local::function::overload<
>> void (const std::string&)
>> , void (const double&) // Overload 1st param type.
>> , void (const double&, const char*) // Overload giving default
>> param.
>> , int (int, int) // Overload giving 2 params (from function
>> pointer).
>> > print(print_string, print_double, print_double, print_add);
>> might be written instead:
>> auto print = make_overload(print_string, print_double, print_double,
>> print_add);
> Yes, this should be possible. I will experiment with it and eventually
> provide make_overload for convenience.
>> (with suitable use of BOOST_AUTO for C++03). I guess this only works if
>> all the functors passed are monomorphic and expose (or could be made to
>> expose) their argument types, but that covers function pointers,
>> boost::function objects, and Boost.Local functions, which is a fairly
>> wide applicability.
>> Writing the above inspires me to ask: Do Boost.Local functions expose
>> their argument types and return types at compile time? If there is a
>> widely accepted way for monomorphic functors to do so, then they should.
>> If there is no such widely accepted way, then one should be created,
>> but that's probably not a job for you right now :).
> What do you mean? How would this feature look like for Boost.Local?
> (Sorry if I am not following...)

Note how a boost::function object defines a static const int arity, and
types arg1_type, ..., argN_type. You need this sort of information if
you are to implement something like the above make_overload and accept a
'generic' function object. I feel that there should be some widely
accepted way to present the interface of a monomorphic function object
for introspection. I don't particularly like the way that has been
chosen by Boost.Function. But I'm not aware of any other.

>> * Introduction
>> "the object this can be bound (eventually by constant value" - I don't
>> understand "eventually".
> It means that you can either "bind this" or "const bind this" (the
> second binds the object as constant within the local functions even if
> the object is non-const in the enclosing member function). I will make
> this text more clear.

As was pointed out elsewhere, I think this is a translation issue.
"eventually" doesn't make sense here. You might mean "possibly" or

>> "The maximum number of parameters that can be passed to a local function
>> (excluding eventual bound variables)" - I don't understand "eventual".
> It means that the max number of parameters does not include the
> bindings. In other words, if the max number of parameters is 5 then
> you can write local functions with up to 5 parameters and as many
> bindings as you want PARAMS(int a1, int a2, int a3, int a4, int a5,
> bind x1, bind x2, ..., bind x100). It says "eventual" because there
> might or not be binds. I will make this text more clear.

Here I'd say "any" instead of "eventual", or just nothing at all.

>> "Compilers have not been observed to be able to inline recursive local
>> function calls (not even when the recursive local function is also
>> declared inlined)." - do you mean "not only when"?
> I mean NAME(inline recursive f) still wasn't observed to inline.

Yes, your wording is correct. I misread it.

>> I don't understand the "Warning" at the bottom; can you expand?
> This works:
> template<typename K, typename V>
> void f ( std::map<K, V> m ) {}
> int main() {
> std::map<char*, int> m;
> f(m);
> return 0;
> }
> But this doesn't:
> template<typename K, typename V>
> void f ( typename BOOST_IDENTITY_TYPE((std::map<K, V>)) m ) {}
> int main() {
> std::map<char*, int> m;
> f(m);
> return 0;
> }
> In this case you have to explicitly write f<char*, int>(m); in main :(
> .. Note that this is never a problem for local functions because
> (unfortunately) they cannot be templates. However, given that
> IDENTITY_TYPE is shown here as a general purpose macro this is a
> limitation of the macro for the general case.
> I will add this example to the docs to clarify.

I see. Yes, the example will help.


Boost list run by bdawes at, gregod at, cpdaniel at, john at