|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-16 21:05:29
Hello,
Function has a testcase (libs/function/test/defarg_test.cpp in CVS) that
handles default arguments, and so far it appears successful. GCC, MSVC,
Borland, and Comeau all handle the following code correctly:
int foo(int x = 5, int y = 3, int z = 1) { return x-y-z; }
boost::function<int> f0(&foo);
boost::function<int, int> f1(&foo);
boost::function<int, int, int> f2(&foo);
assert(f0() == 1);
assert(f1(7) == 3);
assert(f2(10, 2) == 7);
Here is essentially how Function does it:
template<typename FunctionPtr>
int invoker(FunctionPtr f, int a1, int a2) {
return f(a1, a2);
}
assert(invoker(&foo, 10, 2) == 7);
Since &foo is the address of an overloaded function (taking 0, 1, 2 or 3
arguments), which overload of foo &foo refers to isn't resolved until the
call to f(a1, a2).
I don't know how far this can go, because it seems that the following
shouldn't be legal:
template<typename FunctionPtr>
int invoker1(FunctionPtr f, int a1) { return f(a1); }
template<typename FunctionPtr>
int invoker2(FunctionPtr f, int a1, int a2) { return f(a1, a2); }
template<typename FunctionPtr>
int invoke_both(FunctionPtr f, int a1, int a2)
{
return invoker1(f, a1) + invoker2(f, a1, a2);
}
invoke_both(&foo, 3, 5);
This would give &foo two different types within the same context, which can't
be legal. Unfortunately, this seems to be exactly what is needed for the
desired behavior from Boost.Python. And since default arguments are not part
of the type, one can't rely on a conversion of &foo from a function taking
three arguments to a function taking two arguments (see example in 8.3.6p9).
Sadly, I think that it isn't possible to split a function pointer into
separate function pointers based on default arguments.
Doug
On Monday 16 July 2001 04:37, you wrote:
> Hi Ralf,
>
> I'm not sure. I think you'd need some funky metaprogramming. Actually, on
> second thought, I don't see how to get it to work anymore - the default
> argument values can only be generated by code which tries to call the
> function directly AFAICT. I think Ulli and I discussed it long ago; maybe
> he remembers an approach.
>
> -Dave
> ----- Original Message -----
> From: <rwgk_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, July 16, 2001 1:58 PM
> Subject: [boost] Re: Boost:::python default function arguments
>
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > If someone was interested in adding this feature, it would be
> >
> > possible to
> >
> > > provide a different def() function overload which takes as a
> >
> > parameter the
> >
> > > number of default arguments and generates all of the neccessary
> >
> > Python
> >
> > > function overloads.
> > >
> > > -Dave
> >
> > I am! My Boost.Python module code is full of manually
> > generated overloads for member functions with default
> > arguments.
> >
> > David, how difficult is it to implement your suggestion?
> >
> > Thanks!
> > Ralf
> >
> >
> >
> > Info: http://www.boost.org Unsubscribe:
>
> <mailto:boost-unsubscribe_at_[hidden]>
>
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
> Info: http://www.boost.org Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk