[GCC-XML] Default parameter values in member functions of templated classes.

[Roman Yakovenko]

On Tue, Feb 26, 2008 at 3:59 PM, Brad King <brad.king at kitware.com> wrote:
> Roman Yakovenko wrote:
>  > On Tue, Feb 26, 2008 at 8:27 AM, Bryan Ischo <bji-gccxml at ischo.com> wrote:
>
> >>  Can you elaborate on the other limits in the expression-to-string
>  >>  conversion that people have encountered?  It would help me to know about
>  >>  these things instead of discovering them later on myself.
>  >>
>  >>  As to the utility of correct default attributes - I had wanted to use
>  >>  the text in the default attribute directly in generated C++ code, but it
>  >>  wasn't working for defaults like the problematic one I wrote about.  So
>  >>  I scrapped that, and instead just give the user the text string of the
>  >>  default value to do with what they will.  It's just for completeness of
>  >>  my API (the xrtti "extended runtime typing for C++" system) that I want
>  >>  to be able to provide programmatic representations of the defaults to
>  >>  the API users, not because I have any particular use case in which valid
>  >>  default values would be useful.  Perhaps I should submit a feature
>  >>  request in the gccxml bug database for better expression-to-string
>  >>  handling, especially with regards to default values?
>  >
>  >>From my experience only "very simple" default value expressions work.
>  > "Very simple" defined as POD, default constructor of non template class.
>
>  Roman is correct.  The default argument attribute is intended mostly for
>  human reference and possibly documentation generation.  Implementing
>  full support for default arguments would require full expression
>  dumping, which then gets most of the way to function body support.  It
>  is non-trivial and was not a design goal of gccxml.
>
>  You don't actually need the default arguments to generate bindings.
>  Just generate one binding for each function signature:
>
>   void f(int, int = 1);
>
>  gets wrapped with two interfaces.  Something like this:
>
>   if(num_args == 1)
>     {
>     f(convert_argument<int>(args[0]));
>     }
>    else if(num_args == 2)
>     {
>     f(convert_argument<int>(args[0]), convert_argument<int>(args[1]));
>     }
>
>  Then just include in the generated interface documentation that f()'s
>  second argument is optional and the default value is "<default-string>".

I think that the better solution is to dump default value as is, not
as gcc expression.
It will allow us to introduce simple rule, which will simplify the
user and developers life:

Rule: the "default value" string should be compiled in other context too.

Let me explain in code, cause my English is not as good as I want:

namespace xyz{
    struct data_t{...};
}

void do_smth( const data_t& d = xyz::data_t() );

In this example, "xyz::data_t()" expression could be compiled in any
context of the generated code.
Another example will not:

using xyz;
//or
typedef xyz::data_t MyData;

void do_smth( const data_t& d = MyData() );
void do_smth( const data_t& d = data_t() );

I guess, it is very easy to change the source code, so it will contain
only "fully specified" "default value expressions".
Of course there is a problem with templates, but somehow I fill that
this will be an improvement over existing situation.

P.S. Sometime ago, I tried to implement this change but failed - I
didn't find the API, and all my attempts and debugging got me nowhere.

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