[Mono-dev] MonoBind - C++ bindings library [include Mono Patch]

[Paolo Molaro]

On 03/28/07 virgile.bello at free.fr wrote:
> As I worked on a C++ binding library for mono, very close to
> boost::python/luabind syntax, I had few minor modification to do in Mono
> sources. The patch is attached.
> 
> I was wondering if it was possible to include them in mono.
> The missing thing was the possibility to bind a pointer argument to an internal
> call. It is required in order to make all the C++ wrapper/proxy statically
> linked through template metaprogramming.
[...]
> Later, I would like the registration code to auto-generate C# header.

I think auto-generation is the only option, unless this is supposed to
be used for very few classes.

Anyway, I took a look at the code, but I don't see a reason why the core
of mono would need changes for this, you can do it all without any
mono changes.
What you basically are doing is that, given a icall method declaration,
to actually call a function with a different signature. Why not use the
correct signature in the first place?

[C code (or C-representation of the C++ ABI?)]
	void icall (void *this_ptr, void *hidden_arg, int a);

[Old C# code: mono core changes needed because the signature is incorrect]
	[MethodImplAttribute(MethodImplOptions.InternalCall)]
	extern public void Test (int a);

[New C# code: no core mono changes needed]
	[MethodImplAttribute(MethodImplOptions.InternalCall)]
	extern void Test (IntPtr hidden_arg, int a);
	
	static readonly IntPtr Test_hidden_arg;

	public void Test (int a) {
		Test (Test_hidden_arg, a);
	}

And you will initialize Test_hidden_arg as part of the binding startup
code with the embedding API or even with an icall in C#:

	static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig ("vi");

where "vi" means void for the return type and i is the first argument of
type int, though there are also other options, like (using params arrays):

	static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null, typeof (int));

This makes it much more flexible and also much easier to deal with if
you automatically generate the C# side.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better