Anonymous structs

I've been experimenting with putting a library through kludge. I believe the library is what is
referred to as a "pure C API", with some c++ wrapping.

In at least two places it uses anonymous structs. Anonymous structs "declare an anonymous
structure and create a typedef for it". (Full disclosure, I don't have a deep understanding of
this, I'm just reporting what I've gleaned from online research) These cause kludge generate

So what is the correct way to handle anonymous structs?



Here's some TL:DR psuedo code to show what happens for anyone interested in the details.
First the anonymous struct

typedef struct
  unsigned psuedoMemberA;
  float psuedoMemberB;
` unsigned psuedoMemberC;
} foo;

This would cause kludge discover to create the following lines in

ext_ = ext.add_owned_type('') 
ext.add_alias('foo', 'struct foo')

it would also cause these three lines to be added to

ext_.add_member('psuedoMemberA', 'unsigned int', visibility=Visibility.public)
ext_.add_member('psuedoMemberB', 'float', visibility=Visibility.public)
ext_.add_member('psuedoMemberC', 'unsigned int', visibility=Visibility.public)

Putting this through kludge generate would cause a failure when processing the
'ext.add_owned_type('')' line in

Commenting out that line allows to finish processing, but generate then
fails while going through when it hits the first 'ext_.add_member', reporting "NameError: name 'ext_' is not defined"


  • HelgeHelge Moderator, Fabric Employee Posts: 314 Fabric Employee

    Hey @JeffD,

    in this case I recommend to manually fix the kludge files. I've filed FE-8609 to fix this for a future release of Kludge.

    To fix this manually you can change the python code like so:

    extFoo = ext.add_owned_type('foo')
    extFoo.add_member('psuedoMemberA', 'unsigned int', visibility=Visibility.public)
    extFoo.add_member('psuedoMemberB', 'float', visibility=Visibility.public) 
    extFoo.add_member('psuedoMemberC', 'unsigned int', visibility=Visibility.public)

    I realize this is a hassle for now - so thanks for your patience and understanding.

    Let me know if you have any questions!


    Research Engineer @ Fabric Software

  • JeffDJeffD Posts: 20

    Hey @Helge

    I realize this is a hassle for now - so thanks for your patience and understanding.

    I've already been doing a lot of experimenting and fiddling with the discover python code, so no worries on that account :)
    And good news, after editing things per your example*, generate completed without error!
    (*with some minor changes: 1) Used discover's underscore syntax, i.e. ext_foo rather than extFoo. 2) One of the anonymous structs is doing some pointer voodoo so I used add_opaque_type for that one, instead of add_owned_type)
    Now, I haven't tried building the extension yet, because the log shows a lot of things are getting ignored that shouldn't be, so there's still stuff that needs to be un-fiddled or re-fiddled, and towards that end I've got a question.

    When using add_owned_type (or add_opaque_type) should it always be invoked like this,..

    ext_foo = ext.add_owned_type('foo')

    ...or are there times when this is the correct way to go?



  • scaronscaron Fabric for Houdini Posts: 171
    edited June 30

    Hey Jeff, I am not 100% sure but it seems if you want to add members or methods etc. you will want to return the type after adding it to the extension.

     ext_foo = ext.add_owned_type('foo')
     ext_foo.add_member('bla', 'bool', visibility=Visibility.public)
Sign In or Register to comment.