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

Bryan Ischo bji-gccxml at ischo.com
Sun Feb 24 21:52:23 EST 2008

Brad King wrote:
> Nindi Singh wrote:
>> The default values look interesting. gccxml does pick up that there 
>> is a default value
>> for the second parameter of the constructor in both the templated and 
>> non-templated classes.
>> However  <gccxml-cast-expr> is something I do not understand, 
>> should it not be the same as egclass() ?
>> I am actualy using pygccxml and that does not pick up the fact there 
>> is actual a default value.
> You've encountered a work around for a previous bug.  Years ago I had 
> to disable dumping of GCC's "CAST_EXPR" types in default values 
> because GCC's expression-to-string conversion did not support it.  It 
> looks like this work around is no longer needed since the update to 
> the GCC 4.2 parser.  I've committed changes to remove the work around 
> and restore the intended behavior:
> /cvsroot/GCC_XML/gccxml/GCC/gcc/cp/xml.c,v  <--  xml.c
> new revision: 1.120; previous revision: 1.119
> If you update from CVS it should now be fixed.
> Thanks for the detailed report.  That made it easy to find the problem.

I'm not sure if what I am seeing is this same issue, or related, or 
maybe something different, or maybe isn't an issue at all and is just my 
misunderstanding of the C++ syntax involved.

Here is a simple sample header file to run through gccxml:

#include <string>

class Foo

    std::string s;

Now when I use the latest gccxml on this header (I just checked gccxml 
out today from CVS source), on a Fedora Core 5 system using GCC 4.1.1, I 
get a very big resulting XML file that I won't post all of here; but I 
will post this excerpt which is interesting:

  <Constructor id="_1826" name="basic_string" explicit="1" 
context="_1222" access="public" 
mangled="_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jj *INTERNAL* " 
std::char_traits<wchar_t>, std::allocator<wchar_t> 
std::char_traits<wchar_t>, std::allocator<wchar_t> > 
const&, unsigned int, unsigned int)" location="f64:196" file="f64" 
line="196" extern="1">
    <Argument name="__str" type="_2694" location="f64:196" file="f64" 
    <Argument name="__pos" type="_789" location="f64:196" file="f64" 
    <Argument name="__n" type="_789" location="f64:196" file="f64" 
line="196" default="std::basic_string<_CharT, _Traits, 

This context of this constructor is:

 <Struct id="_1222" 
>" context="_2" mangled="SbIwSt11char_traitsIwESaIwEE" 
std::char_traits<wchar_t>, std::allocator<wchar_t> >" 
location="f47:56" file="f47" line="56" artificial="1" size="32" 
align="32" members="<deleted for brevity>" bases=""/>

What I don't understand is, what the default value of the last argument 
in the Constructor represents.  The text is:

default="std::basic_string<_CharT, _Traits, _Alloc>::npos"

Which, de-escaped, is:

std::basic_string<_CharT, _Traits, _Alloc>::npos

I don't understand what I am looking at.  This is part of a template 
declaration, not a specific template instantiation; how is this valid 
for the default value of a constructor argument for an instantiated 
template?  It almost looks to me like in some cases (not all cases, 
because I am pretty sure that there are many other template constructors 
with default values for which this is working; the only one currently 
causing me trouble is the one for std::basic_string), gccxml is not 
replacing the template parameters with the parameterized values they 
should be assigned from the template instantiation in question.

Any clues?  If no one has any ideas I can try the gccxml version before 
the fix that Brad King mentioned above, and see what the difference is; 
that may provide some useful info.


More information about the gccxml mailing list