[DotGNU]Strategy for dealing with C++ virtual functions in a managed binding.

[Adam Treat]

On Tuesday 03 December 2002 01:24 am, James Michael DuPont wrote:
> Here is the code for getting it from the dbxout.c
> you will notice that this information is stored in the tree structre.
> --------------------------------------------------------------------
> 	  /* This is the "mangled" name of the method.
> 	     It encodes the argument types.  */
> 	  const char *debug_name;
>
> 	  /* Skip methods that aren't FUNCTION_DECLs.  (In C++, these
> 	     include TEMPLATE_DECLs.)  The debugger doesn't know what
> 	     to do with such entities anyhow.  */
> 	  if (TREE_CODE (fndecl) != FUNCTION_DECL)
> 	    continue;
>
> 	  debug_name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (fndecl));
> --------------------------------------------------------------------

Is this from libiberty or something?

> Look at libjava/java/net/natPlainSocketImpl.cc
> void
> java::net::PlainSocketImpl::bind (java::net::InetAddress *host, jint
> lport)
>
> this is a clean an interface as you will get.

Ok, will have a look ;)

> do you have a spec of the output, I could output this directly from the
> gcc-introscptor

Sure ... here is some output from qwidget.xml

************ snip **************
<?xml version="1.0" encoding="us-ascii"?>
<API>
  <Namespace Name="Qt">
    <Class Name="QWidget">
      <Ancestor Name="QObject" />
      <Ancestor Name="QPaintDevice" />
      <Constructor Name="QWidget" Access="Public" Id="0">
        <Parameter Name="parent" Type="QWidget" Mode="Pointer" Default="0" />
        <Parameter Name="name" Type="char" Const="True" Mode="Pointer" 
Default="0" />
        <Parameter Name="f" Type="WFlags" Default="0" />
      </Constructor>
      <Constructor Name="QWidget" Access="Private" Id="1">
        <Parameter Name="arg1" Type="QWidget" Const="True" Mode="Reference" />
      </Constructor>
      <Destructor Name="QWidget" />
      <Method Name="winId" Access="Public" Id="0" Const="True">
        <ReturnType Type="WId" />
      </Method>
      <Method Name="setName" Access="Public" Id="0">
        <ReturnType Type="void" />
        <Parameter Name="name" Type="char" Const="True" Mode="Pointer" />
      </Method>
      <Method Name="style" Access="Public" Id="0" Const="True">
        <ReturnType Type="QStyle" Mode="Reference" />
      </Method>
      <Method Name="setStyle" Access="Public" Id="0">
        <ReturnType Type="void" />
        <Parameter Name="arg1" Type="QStyle" Mode="Pointer" />
      </Method>
      <Method Name="setStyle" Access="Public" Id="1">
        <ReturnType Type="QStyle" Mode="Pointer" />
        <Parameter Name="arg1" Type="QString" Const="True" Mode="Reference" />
      </Method>

******** snip **********

> Sorry for the ambigiguity. I mean the pnet internal calls.
> Well there are many files in the pnet that have a scary
> notice "dont touch, autogenerated"
> unfortually there is no statement about what program generated them.
> I will have to look into this.

We are using PInvoke for the binding so internal calls really aren't 
applicable.

> > Awesome!  I don't know what kind of info would be helpful
>
> 1. the spec for the xml description of the bindings
> 2. a single c+ header file with the class definitions that you want to
> call.

You can find our DTD for the XML representation in our cvs under 
/qtsharp/doc/dtd/api.dtd .  I can attach this to another private email if you 
want ...  You can look at qt-copy/include/qwidget.h for an example of the 
header file and some virtual functions ...

> You want to overwrite the c++ vtable so that you can call C# from c++,
> via the method table?

Yes, this is precisely what we need to do.  We need to be able to override C++ 
virtual functions in C# and then have the C++ native functions call the C# 
overrides where appropriate.  This is the only way to have full functionality 
in the binding.

> ok, this will require setting the function pointer of an existing
> method. Or involve a second interface.
>
> I would say that i need an exact example,
> assuming you could modify the make_thunk function from the gcc,
> then you call the c# code.
> the makethunk is used on the client side
>     fn = make_thunk (fn, delta, vcall_index);
> this is called in the function cp/class.c/build_vtbl_initializer
> int the gcc. There you could set the function pointers.

Hmm, an exact example would be to override the layout virtual methods in 
QWidget such as:

QWidget::sizeHint() returns the preferred size of the widget. 
QWidget::minimumSizeHint() returns the smallest size the widget can have. 
QWidget::sizePolicy() returns a QSizePolicy; a value describing the space 
requirements of the widget. 

so that we could implement a custom layout in Qt#.  This is the idea at least.  
The problem then is to associate a virtual method in Qt# with a virtual 
method in Qt/C++.

Cheers,

Adam