pygccxml-development

Re: [pygccxml-development] skipping base classes

[Roman Y. <rom...@gm...>]

On Wed, Sep 17, 2008 at 4:06 PM, Ken McGaugh <ke...@dn...> wrote:
> Hello all,
>
> After reading through the archives, docs, and the source code I cannot
> find out a way to do the following.
>
> Say I have a class hierarchy like this:
>
>    class A
>      [...]
>
>    class B : public A
>      [...]
>
>    class C : public B
>      [...]
>
> I need to expose to python the classes A and C, but not B.  When writing
> the boost::python code manually I do this:
>
>    bp::class_<C, bp::bases<A> >("C")
>
> So that in python it thinks that C inherits directly from A and it all
> works.  But now that I'm using Py++ I cannot figure out a way to achieve
> the same thing and I have to expose the intermediate classes, which for
> various reasons I really don't want to do.
>
> So is there a way to do what I want in Py++?

I am not sure. I never tested such case. Try to exclude "B" and see
what happens.

If it doesn't work I will have to tweak Py++ to support such case. It
should not be too difficult.

One possible work around is to export class "B", but without any
members and to give it pretty ugly alias, starting with '__'.

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

[pygccxml-development] skipping base classes

[Ken M. <ke...@dn...>]

Hello all,

After reading through the archives, docs, and the source code I cannot
find out a way to do the following.

Say I have a class hierarchy like this:

    class A
      [...]

    class B : public A
      [...]

    class C : public B
      [...]

I need to expose to python the classes A and C, but not B.  When writing
the boost::python code manually I do this:

    bp::class_<C, bp::bases<A> >("C")

So that in python it thinks that C inherits directly from A and it all
works.  But now that I'm using Py++ I cannot figure out a way to achieve
the same thing and I have to expose the intermediate classes, which for
various reasons I really don't want to do.

So is there a way to do what I want in Py++?

Thanks.
--Ken

[pygccxml-development] Compilation problem

[Vincent F. <vin...@gm...>]

I've got some problems while generating a library from my wrappers.

The compilations work fine, but I got some fatal errors when I use
some functions.

These errors or due to a bad generation of the library from the
wrappers. (I've tried some very easy examples which worked perfectly
fine with the same inheritance scheme and a corresponding wrapper
generator using py++).
The constructeur of the class is never called, calling the constructor
of the super class instead (it should call both).

Is there any option in the compilation with gcc and boost.python I
could have forgotten?

Thanks in advance,
Vincent FERRIES

Re: [pygccxml-development] typedef member has no access_type?

[Gustavo C. <gjc...@gm...>]

Hm..  actually cls.get_members(access='public') helps solve my problem, so
never mind.

2008/9/15 Gustavo Carneiro <gjc...@gm...>

> Hi,
>
> I have some code like this:
>
>
>             for member in cls.get_members():
>                 if member.name.startswith('__'):
>                     continue
>                 if member.access_type not in ['public']:
>                     continue
>
> But I am getting an exception:
>
>     if member.access_type not in ['public']:
> AttributeError: 'typedef_t' object has no attribute 'access_type'
>
> I am not sure then how to find out the access type of a typedef defined
> inside a class.  Any ideas?
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[pygccxml-development] typedef member has no access_type?

[Gustavo C. <gjc...@gm...>]

Hi,

I have some code like this:


            for member in cls.get_members():
                if member.name.startswith('__'):
                    continue
                if member.access_type not in ['public']:
                    continue

But I am getting an exception:

    if member.access_type not in ['public']:
AttributeError: 'typedef_t' object has no attribute 'access_type'

I am not sure then how to find out the access type of a typedef defined
inside a class.  Any ideas?

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] cls.null_constructor_body bug?

[Roman Y. <rom...@gm...>]

Hi. I fixed the bug and now [copy|null]_constructor_body is just a
shortcut to constructor "body" property.

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

Re: [pygccxml-development] How to return a std::vector<std::string> to Python

[Roman Y. <rom...@gm...>]

On Wed, Sep 10, 2008 at 6:08 PM,  <bf...@co...> wrote:
> Hi,
>
> also after lengthy search on the net I could not find a working example for the following (probably common)  use case:
>
> I would like to expose a C++ function to Python which has as result type
>    std::vector<std::string>
>
> When invoking the exposed function from Python I get the message
>
>  File "test.py", line 15, in <module>
>    v = a.alias_to_account_list(al)
> TypeError: No to_python (by-value) converter found for C++ type: std::vector<std::string, std::allocator<std::string> >
>
> The function looks as follows:
>  vector<string> alias_to_account_list(string ali="SAP") {
>      set<string> accts = _tlib2->alias_to_account_list(ali);
>      cerr << "alias '" << ali << "' expands to that many accounts::" << accts.size() << endl;
>      copy(accts.begin(), accts.end(), ostream_iterator<string>(cerr, ","));
>      vector<string> res;
>      copy(accts.begin(), accts.end(), back_inserter(res));
>      return res;
>  }
>
> What can I do? Is there a way to construct native Python objects? Interestingly my code works when I return
>    std::vector<int>
>
> In this case I can access the elements of the vector from python with the [] notation. The object is no native python array, however, which I would prefer.
> I am only interested in return by value at this point, so I do not want to change the C++ vector from Python.
>
> This is what I want to do in Python:
>
>   for al in ["MAN","LHA","SIE25"]:
>       v = a.alias_to_account_list(al)
>       print "dir(v)= ",dir(v), len(v),v[0],v[1],v[2]
>
> Any hints are appreciated,

What indexing suite do you use?
If you use indexing suite that comes with boost.python than the
following code will register your vector correctly:

typedef std::vector< std::string > strings_t;



inline void do_nothing( const strings_t& ){}



inline strings_t get_names(){...}

namespace bp = boost::python;

typedef bp::class_< std::vector< std::string > > strings_t_exposer_t;
strings_t_exposer_t strings_t_exposer = strings_t_exposer_t(
"strings_t", "documentation" );
bp::scope strings_t_scope( strings_t_exposer );
strings_t_exposer.def( bp::vector_indexing_suite< ::std::vector<
std::string >, true >() );

Py++ should be able to generate the correct code, if not show me your
use case - I will improve it.

HTH

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

Re: [pygccxml-development] cls.null_constructor_body bug?

[Roman Y. <rom...@gm...>]

On Wed, Sep 10, 2008 at 9:53 PM, Roman Yakovenko
<rom...@gm...> wrote:
> On Mon, Sep 8, 2008 at 4:04 PM,  <bf...@co...> wrote:
>> I am trying out to insert code into the py++ generated code as described in
>>
>> http://www.language-binding.net/pyplusplus/documentation/inserting_code.html
>>
>> Here is the relevant part of my codebuilder file:
>>
>> def inject_code( cls ):
>>    constructors = cls.constructors()
>>    constructors.body = "// (STUFF FOR ALL CONSTRUCTORS)" #class instance registration code
>>    cls.null_constructor_body = "// NULL CONSTRUCTORS STUFF " #class instance registration code
>>    cls.copy_constructor_body = "//COPY CONSTRUCTOR STUFF" #class instance registration code
>>
>>    cls.add_wrapper_code("//WRAPPER STUFF" ) #destructor declaration and definition code
>>    cls.add_wrapper_code("//MORE WRAPPER STUFf") # the new class variable definition code
>>
>> x = mb.class_("MyClass")
>> x.include()
>> inject_code(x)
>>
>> The generated code does not contain the  "// NULL CONSTRUCTORS STUFF ", though (see below). Is this a bug?
>
> Yes. I will try to fix it tomorrow.

Sorry, forgot to provide work-around for you.

It depends on version you use, but the solution is not that different:
you can find out the constructor "type" and assign different code to
"body".


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

Re: [pygccxml-development] cls.null_constructor_body bug?

[Roman Y. <rom...@gm...>]

On Mon, Sep 8, 2008 at 4:04 PM,  <bf...@co...> wrote:
> I am trying out to insert code into the py++ generated code as described in
>
> http://www.language-binding.net/pyplusplus/documentation/inserting_code.html
>
> Here is the relevant part of my codebuilder file:
>
> def inject_code( cls ):
>    constructors = cls.constructors()
>    constructors.body = "// (STUFF FOR ALL CONSTRUCTORS)" #class instance registration code
>    cls.null_constructor_body = "// NULL CONSTRUCTORS STUFF " #class instance registration code
>    cls.copy_constructor_body = "//COPY CONSTRUCTOR STUFF" #class instance registration code
>
>    cls.add_wrapper_code("//WRAPPER STUFF" ) #destructor declaration and definition code
>    cls.add_wrapper_code("//MORE WRAPPER STUFf") # the new class variable definition code
>
> x = mb.class_("MyClass")
> x.include()
> inject_code(x)
>
> The generated code does not contain the  "// NULL CONSTRUCTORS STUFF ", though (see below). Is this a bug?

Yes. I will try to fix it tomorrow.

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

[pygccxml-development] How to return a std::vector<std::string> to Python

[<bf...@co...>]

Hi,

also after lengthy search on the net I could not find a working example for the following (probably common)  use case:

I would like to expose a C++ function to Python which has as result type 
    std::vector<std::string>

When invoking the exposed function from Python I get the message

  File "test.py", line 15, in <module>
    v = a.alias_to_account_list(al)
TypeError: No to_python (by-value) converter found for C++ type: std::vector<std::string, std::allocator<std::string> >

The function looks as follows:
  vector<string> alias_to_account_list(string ali="SAP") {
      set<string> accts = _tlib2->alias_to_account_list(ali);
      cerr << "alias '" << ali << "' expands to that many accounts::" << accts.size() << endl;
      copy(accts.begin(), accts.end(), ostream_iterator<string>(cerr, ","));
      vector<string> res;
      copy(accts.begin(), accts.end(), back_inserter(res));
      return res;
  }

What can I do? Is there a way to construct native Python objects? Interestingly my code works when I return
    std::vector<int>

In this case I can access the elements of the vector from python with the [] notation. The object is no native python array, however, which I would prefer.
I am only interested in return by value at this point, so I do not want to change the C++ vector from Python.

This is what I want to do in Python:

   for al in ["MAN","LHA","SIE25"]:
       v = a.alias_to_account_list(al)
       print "dir(v)= ",dir(v), len(v),v[0],v[1],v[2]

Any hints are appreciated,
Bernd

[pygccxml-development] cls.null_constructor_body bug?

[<bf...@co...>]

I am trying out to insert code into the py++ generated code as described in 

http://www.language-binding.net/pyplusplus/documentation/inserting_code.html

Here is the relevant part of my codebuilder file:

def inject_code( cls ):
    constructors = cls.constructors()
    constructors.body = "// (STUFF FOR ALL CONSTRUCTORS)" #class instance registration code
    cls.null_constructor_body = "// NULL CONSTRUCTORS STUFF " #class instance registration code
    cls.copy_constructor_body = "//COPY CONSTRUCTOR STUFF" #class instance registration code

    cls.add_wrapper_code("//WRAPPER STUFF" ) #destructor declaration and definition code
    cls.add_wrapper_code("//MORE WRAPPER STUFf") # the new class variable definition code 
    
x = mb.class_("MyClass")
x.include()
inject_code(x)

The generated code does not contain the  "// NULL CONSTRUCTORS STUFF ", though (see below). Is this a bug?

Bernd

struct MyClass_wrapper : MyClass, bp::wrapper< MyClass > {

    MyClass_wrapper(MyClass const & arg )
    : MyClass( arg )
      , bp::wrapper< MyClass >(){
        // copy constructor
        //COPY CONSTRUCTOR STUFF
    }

    MyClass_wrapper( )
    : MyClass( )
      , bp::wrapper< MyClass >(){
        // null constructor
    // (STUFF FOR ALL CONSTRUCTORS)
    }

    MyClass_wrapper(::std::string const & s )
    : MyClass( s )
      , bp::wrapper< MyClass >(){
        // constructor
    // (STUFF FOR ALL CONSTRUCTORS)
    }

    MyClass_wrapper(::search3::key const & k )
    : MyClass( boost::ref(k) )
      , bp::wrapper< MyClass >(){
        // constructor
    // (STUFF FOR ALL CONSTRUCTORS)
    }

Re: [pygccxml-development] uint32_t vs unsigned int, cygwin problems

[Gustavo C. <gjc...@gm...>]

Inspecting the gccxml XML output file I get the impression this is a bug in
gccxml itself.

I reported it as: http://www.gccxml.org/Bug/view.php?id=7572


2008/8/28 Gustavo Carneiro <gjc...@gm...>

> I am having a problem with (py)gccxml parsing of templated types, where a
> different type is being reported.
>
> For example, here:
>
> std::set<uint32_t> get_set ();
>
> With this code:
>
>         for fun in
> module_namespace.free_functions(function=self.location_filter,
>                                                    allow_empty=True,
> recursive=False):
>             if fun.name.startswith('__'):
>                 continue
>             for dependency in fun.i_depend_on_them(recursive=False):
>                 type_info = dependency.depend_on_it
>                 traits = container_traits.find_container_traits(type_info)
>                 if traits is None:
>                     continue
>                 print >> sys.stderr, "** type: %s; --->
> partial_decl_string: %r" % (type_info, type_info.partial_decl_string)
>
> It prints:
>
> ** type: std::set<unsigned int,std::less<unsigned
> int>,std::allocator<unsigned int> >; ---> partial_decl_string: '::std::set<
> unsigned int >'
>
> Yes, I know what you are thinking, it's ok, unsigned int and uint32_t are
> the same type after all.  Well, usually it is, sometimes it's not.  I
> received a report about generated code not compiling in cygwin, and I found
> out that it's because in cygwin uint32_t is typdefed as 'unsigned long int',
> instead of 'unsigned int'.  Yes, cygwin is broken, I know, but we have to
> live with it :|
>
> Is there anything that I can do to make this right?  I would like to avoid
> losing the type information and keep uint32_t around instead of unsigned
> int, else the generated code is not very portable.
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[pygccxml-development] uint32_t vs unsigned int, cygwin problems

[Gustavo C. <gjc...@gm...>]

I am having a problem with (py)gccxml parsing of templated types, where a
different type is being reported.

For example, here:

std::set<uint32_t> get_set ();

With this code:

        for fun in
module_namespace.free_functions(function=self.location_filter,
                                                   allow_empty=True,
recursive=False):
            if fun.name.startswith('__'):
                continue
            for dependency in fun.i_depend_on_them(recursive=False):
                type_info = dependency.depend_on_it
                traits = container_traits.find_container_traits(type_info)
                if traits is None:
                    continue
                print >> sys.stderr, "** type: %s; ---> partial_decl_string:
%r" % (type_info, type_info.partial_decl_string)

It prints:

** type: std::set<unsigned int,std::less<unsigned
int>,std::allocator<unsigned int> >; ---> partial_decl_string: '::std::set<
unsigned int >'

Yes, I know what you are thinking, it's ok, unsigned int and uint32_t are
the same type after all.  Well, usually it is, sometimes it's not.  I
received a report about generated code not compiling in cygwin, and I found
out that it's because in cygwin uint32_t is typdefed as 'unsigned long int',
instead of 'unsigned int'.  Yes, cygwin is broken, I know, but we have to
live with it :|

Is there anything that I can do to make this right?  I would like to avoid
losing the type information and keep uint32_t around instead of unsigned
int, else the generated code is not very portable.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] compiler generated declarations?

[Roman Y. <rom...@gm...>]

On Wed, Aug 27, 2008 at 5:04 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I am having a minor problem, pygccxml is reporting all type declarations as
> artificial.  To work around it, I only check for is_artificial for calldef_t
> declarations and now everything works.

The problem comes from the gccxml itself. I think it worth to report
this problem to Brad King. It is also possible that I don't understand
its meaning.

Only few calldefs could be artificial:
* default constructor
* copy constructor
* operator=

pygccxml has few type traits which help to identify whether class:
* default constructable
* has available copy constructor/operator=

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

Re: [pygccxml-development] compiler generated declarations?

[Gustavo C. <gjc...@gm...>]

2008/8/27 Roman Yakovenko <rom...@gm...>

> On Wed, Aug 27, 2008 at 3:04 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > I have been trying latest gccxml and pygccxml trunk with pybindgen, and
> am
> > finding something new that is happening:
> >
> > /home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
> > Annotation 'automatic_type_narrowing=True' not used (used in
> > SomeObject::NestedClass &
> > SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
> > [member operator])
> >
> > This operator= method is generated by the compiler or pygccxml, yet it
> > appears to be a real declaration with a physical location.  As a side
> > effect, pybindgen will look for annotation comments and complain when the
> > found annotations cannot be used.
> >
> > Is there any way to distinguish between real definitions and synthetic
> ones?
>
> You are looking for declarations.is_artificial property
>
>
> http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#is_artificial


Sorry, I should look better in the documentation next time.

I am having a minor problem, pygccxml is reporting all type declarations as
artificial.  To work around it, I only check for is_artificial for calldef_t
declarations and now everything works.

Thanks!

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] compiler generated declarations?

[Roman Y. <rom...@gm...>]

On Wed, Aug 27, 2008 at 3:04 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I have been trying latest gccxml and pygccxml trunk with pybindgen, and am
> finding something new that is happening:
>
> /home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
> Annotation 'automatic_type_narrowing=True' not used (used in
> SomeObject::NestedClass &
> SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
> [member operator])
>
> This operator= method is generated by the compiler or pygccxml, yet it
> appears to be a real declaration with a physical location.  As a side
> effect, pybindgen will look for annotation comments and complain when the
> found annotations cannot be used.
>
> Is there any way to distinguish between real definitions and synthetic ones?

You are looking for declarations.is_artificial property

http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#is_artificial

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

[pygccxml-development] compiler generated declarations?

[Gustavo C. <gjc...@gm...>]

I have been trying latest gccxml and pygccxml trunk with pybindgen, and am
finding something new that is happening:

/home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
Annotation 'automatic_type_narrowing=True' not used (used in
SomeObject::NestedClass &
SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
[member operator])

This operator= method is generated by the compiler or pygccxml, yet it
appears to be a real declaration with a physical location.  As a side
effect, pybindgen will look for annotation comments and complain when the
found annotations cannot be used.

Is there any way to distinguish between real definitions and synthetic ones?

Thanks in advance.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[pygccxml-development] unsubscribe

[Kevin W. <kev...@gm...>]

Re: [pygccxml-development] how to run unit tests?

[Gustavo C. <gjc...@gm...>]

2008/8/26 Roman Yakovenko <rom...@gm...>

> On Tue, Aug 26, 2008 at 1:27 AM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > Therefore I propose a patch to let pygccxml search in PATH for gccxml, by
> > default, and let your case be the exception, not the rule.
> >
> > I mean, I don't mind making my case a special case, but thinking of other
> > users I would advise to make unit tests Just Work™ out of the box.  What
> do
> > you think?
>
> I agree with you. I just committed the fix to autoconfig.py
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev
>
> gccxml_configuration_t class will look for gccxml binary in the
> environment. in case the path was not set
>

I remembered one more suggestion: sys.path.insert(0, '..')

This way unit tests will always use the source tree pygccxml version, never
the installed one.  Most people believe this is the right thing to do, as
you usually want to test the pygcccxml you are about to install (or are
developing), not the one that is installed.

Regards,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Removing template default arguments?

[Gustavo C. <gjc...@gm...>]

2008/8/26 Roman Yakovenko <rom...@gm...>

> On Tue, Aug 26, 2008 at 5:09 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > Attached.
>
> Okey. There is no bug in pygccxml, if I look on your test case.
> I still don't understand how you get std::map< string, int >?
>
> I would like to explain few things, that I hope, will make clear to
> you what and how to use.
>
> declaration_t class has 4 different properties, related to its name
>
> I will explain them, using the following example:
>
> namespace ns{
>    std::vector< int > do_smth();
> }
>
> For do_smth return type:
>
> * name - the class name - vector< int, std::allocator< int > >
> * partial name - the class name without default template args - vector< int
> >
> * decl_string - full class name - std::vector< int, std::allocator< int > >
> * partial_decl_string - the full class name without default template
> args - std::vector< int >
>
> In most case, you want to use [partial_]decl_string, because it allows
> you to use the class in "other context".


partial_decl_string works perfectly.  Thank you!

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Removing template default arguments?

[Roman Y. <rom...@gm...>]

On Tue, Aug 26, 2008 at 5:09 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Attached.

Okey. There is no bug in pygccxml, if I look on your test case.
I still don't understand how you get std::map< string, int >?

I would like to explain few things, that I hope, will make clear to
you what and how to use.

declaration_t class has 4 different properties, related to its name

I will explain them, using the following example:

namespace ns{
    std::vector< int > do_smth();
}

For do_smth return type:

* name - the class name - vector< int, std::allocator< int > >
* partial name - the class name without default template args - vector< int >
* decl_string - full class name - std::vector< int, std::allocator< int > >
* partial_decl_string - the full class name without default template
args - std::vector< int >

In most case, you want to use [partial_]decl_string, because it allows
you to use the class in "other context".

HTH

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

Re: [pygccxml-development] Removing template default arguments?

[Roman Y. <rom...@gm...>]

On Tue, Aug 26, 2008 at 4:25 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Unfortunately I found a small problem with it:
>
> ************* register_container std::map< std::basic_string< char,
> std::char_traits< char >, std::allocator< char > >, int, std::less<
> std::basic_string< char, std::char_traits< char >, std::allocator< char > >
>>, std::allocator< std::pair< const std::basic_string< char,
> std::char_traits< char >, std::allocator< char > >, int > > >;
> element_type=int, key_type=string
>
> key_type should be 'std::string', not 'string', right?

Can you submit small test case that reproduce the problem?

Thanks

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

Re: [pygccxml-development] Removing template default arguments?

[Gustavo C. <gjc...@gm...>]

2008/8/26 Roman Yakovenko <rom...@gm...>

> On Tue, Aug 26, 2008 at 3:09 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > Thanks, Roman, it is indeed much faster now! :-)
> >
> > I have one more tricky question.   I am getting this key_type:
> >
> >     std::basic_string<char,std::char_traits<char>,std::allocator<char> >
> > [struct]
> >
> > Now, I know this is just a std::string type, but PyBindGen does not know
> > it.  Is there any way to convert this into a simpler std::string -like
> > definition.  That is because I register and lookup types by type
> expression
> > string, but if there are multiple definitions for the same type then
> things
> > won't match.
> >
> > Well, I guess one solution for me would be to register the
> > "std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
> > type string alongside std::string, but if there's anything better to do
> I'll
> > take it.
> >
> > I guess this is a generic question.  Given the simple test case I am
> working
> > on:
> >
> >    std::map<std::string, int>
> >
> > pygccxml reads this as:
> >
> >    std::map<std::basic_string<char, std::char_traits<char>,
> > std::allocator<char> >,int,std::less<std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> >
> >>,std::allocator<std::pair<const std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> >, int> > >
> >
> > Is there any easy way to just remove the template arguments that have the
> > same value as the template default template argument value?
> >
> > I am guessing the answer is no, but it doesn't hurt to ask :P
>
> Wrong guess:
> http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#partial_name
>

Awesome!

Unfortunately I found a small problem with it:

************* register_container std::map< std::basic_string< char,
std::char_traits< char >, std::allocator< char > >, int, std::less<
std::basic_string< char, std::char_traits< char >, std::allocator< char > >
>, std::allocator< std::pair< const std::basic_string< char,
std::char_traits< char >, std::allocator< char > >, int > > >;
element_type=int, key_type=string

key_type should be 'std::string', not 'string', right?


>
> By the way, container_traits has "remove_defaults" functionality. Now,
> you know what it is for.


remove_defaults rocks as well, but has the same problem of removing the
std:: namespace prefix.


> This is a must functionality for a good code generator - the generated
> code should be as closed to "human written" as possible.


Agreed.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Removing template default arguments?

[Roman Y. <rom...@gm...>]

On Tue, Aug 26, 2008 at 3:09 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Thanks, Roman, it is indeed much faster now! :-)
>
> I have one more tricky question.   I am getting this key_type:
>
>     std::basic_string<char,std::char_traits<char>,std::allocator<char> >
> [struct]
>
> Now, I know this is just a std::string type, but PyBindGen does not know
> it.  Is there any way to convert this into a simpler std::string -like
> definition.  That is because I register and lookup types by type expression
> string, but if there are multiple definitions for the same type then things
> won't match.
>
> Well, I guess one solution for me would be to register the
> "std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
> type string alongside std::string, but if there's anything better to do I'll
> take it.
>
> I guess this is a generic question.  Given the simple test case I am working
> on:
>
>    std::map<std::string, int>
>
> pygccxml reads this as:
>
>    std::map<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >,int,std::less<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >
>>,std::allocator<std::pair<const std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, int> > >
>
> Is there any easy way to just remove the template arguments that have the
> same value as the template default template argument value?
>
> I am guessing the answer is no, but it doesn't hurt to ask :P

Wrong guess: http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#partial_name

By the way, container_traits has "remove_defaults" functionality. Now,
you know what it is for.

This is a must functionality for a good code generator - the generated
code should be as closed to "human written" as possible.

HTH

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

[pygccxml-development] Removing template default arguments?

[Gustavo C. <gjc...@gm...>]

2008/8/26 Roman Yakovenko <rom...@gm...>

> On Tue, Aug 26, 2008 at 8:28 AM, Roman Yakovenko
> <rom...@gm...> wrote:
> > On Tue, Aug 26, 2008 at 1:58 AM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> >> Sorry, I just discovered it's not a bug.  It's not infinite recursion,
> just
> >> very slow :P
> >
> > This is also bug. I would like to see your use case, so I can improve it.
> >
> > The first obvious think we can do is to add cache for element_type
> > method. This should dramatically improve the speed of your application
> > - or discover another bottleneck.
> >
> >> It turns out that
> >> pygccxml.declarations.container_traits.xxx_traits.element_type() is
> rather
> >> slow and I was calling it more often than I should.
> >>
> >> Now, I am left with the old problem of distinguishing between sequence
> and
> >> mapping containers... </hint>
> >
> > :-). I will work on this today.
>
> done.
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=1408
>
> I also added cache for element_type and key_type functionality. Let me
> know whether this change improved performance or not.


Thanks, Roman, it is indeed much faster now! :-)

I have one more tricky question.   I am getting this key_type:

    std::basic_string<char,std::char_traits<char>,std::allocator<char> >
[struct]

Now, I know this is just a std::string type, but PyBindGen does not know
it.  Is there any way to convert this into a simpler std::string -like
definition.  That is because I register and lookup types by type expression
string, but if there are multiple definitions for the same type then things
won't match.

Well, I guess one solution for me would be to register the
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
type string alongside std::string, but if there's anything better to do I'll
take it.

I guess this is a generic question.  Given the simple test case I am working
on:

   std::map<std::string, int>

pygccxml reads this as:

   std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >,int,std::less<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >
>,std::allocator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, int> > >

Is there any easy way to just remove the template arguments that have the
same value as the template default template argument value?

I am guessing the answer is no, but it doesn't hurt to ask :P

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert