[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