[C++-sig] Providing a default value for a pointer argument

Roman Yakovenko roman.yakovenko at gmail.com
Wed Mar 22 19:29:12 CET 2006


On 3/22/06, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
> --- Roman Yakovenko <roman.yakovenko at gmail.com> wrote:
> > Except of "luck of time", is there is an other reason (==technical) for not
> > supporting optional on "def"'s
>
> Interesting viewpoint. But note that you normally don't have to enumerate the
> function argument types when .def'ing a function. That's unavoidable only for
> constructors.

Enumerating function argument types has an advantage - developer can add an
overloaded method to the project and bindings will continue to compile.

Also if you export some template instantiation you have to specify function
signature.

> I guess if you want to enable optional<> for functions it would have to be
> embedded in some kind of equivalent of init<>, maybe
>
>   def("foo", signature<foo, int, optional<double> >())

Yes. I think that this approach is simple and readable.
Also in case of function user can specify only last N arguments that has default
values, but this is less readable.

void foo( int x, double d=2.3 ){...}

def( "foo", &foo, optional< double >() )

> Even if this is technically possible (?) it wouldn't buy you all that much
> compared to a combination of type cast and BOOST_FUNCTION_OVERLOADS,

In one of previuos post you already showed that I cann't use
BOOST_FUNCTION_OVERLOADS if function has overloads.

do_smth( int, double )
do_smth( std::pair< int, double > )

Or may be I've got you wrong? So the proposed approach can deal with
both cases.

> and in
> practice there are probably not many situations where the signature<> approach
> is necessary/useful.
>

It is really depends on library you are wrapping. From my point of
view, :-), the code
I need to write in pyplusplus to generate second approach is much, much simple.

> Cheers,
>         Ralf

Thank you.

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/



More information about the Cplusplus-sig mailing list