Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
On 03/28/07 [EMAIL PROTECTED] 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
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Quoting Paolo Molaro [EMAIL PROTECTED]:
On 03/28/07 [EMAIL PROTECTED] 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.
Yes you're right, that's the first approach I took. It's just I felt it was
cleaner to do it the other way. But well, since those definitions are
auto-generated I suppose it's not a big deal doubling everything.
Thanks for the review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Hello, 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. (The only other possibility of doing it, using pointer to function member removed the possibility to deduce type of function arguments, resulting in a heavy syntax when declaring exported class in C++). You can check the binding library at : http://dev.kalimdor.org/entropia/node/10 It's still in development (like there is few non trivial to fix memory leak, i.e. the wrapping code that should stay alive when mono is running), but right now it works fine at exporting C++ class to C# and C# class to C++. Later, I would like the registration code to auto-generate C# header. By the way, I still have a mono debugger for embedded mono (more or less in pause, but if lot of people are interested in it, I could start working on it again). I think with all that Mono could be a really great scripting language, offering blazing speed compared to all the usual non-JIT script languages, with all the advantages of C#. Sincerely, Virgile Bello mono_internal_call_param.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
This is fantastic! I had just been working on my own C++ binding in the spirit of Boost-Python, but I think mine is not quite as far along as yours so I'll gladly drop it and use yours. Can you please tell us what the license is for yours though? It doesn't seem to say on the webpage or in the source files. / Cody On Wed, 2007-03-28 at 23:24 +0200, [EMAIL PROTECTED] wrote: Hello, 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. (The only other possibility of doing it, using pointer to function member removed the possibility to deduce type of function arguments, resulting in a heavy syntax when declaring exported class in C++). You can check the binding library at : http://dev.kalimdor.org/entropia/node/10 It's still in development (like there is few non trivial to fix memory leak, i.e. the wrapping code that should stay alive when mono is running), but right now it works fine at exporting C++ class to C# and C# class to C++. Later, I would like the registration code to auto-generate C# header. By the way, I still have a mono debugger for embedded mono (more or less in pause, but if lot of people are interested in it, I could start working on it again). I think with all that Mono could be a really great scripting language, offering blazing speed compared to all the usual non-JIT script languages, with all the advantages of C#. Sincerely, Virgile Bello ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Thanks for your comments ! Yes you're right, I didn't put any license, but I will very likely put it with an unrestrictive license, not sure of which one yet (BSD, zlib, LGPL, etc...). And I should make a real project page for it if some people start using it or contributing, that would look more serious. Virgile Quoting Cody Russell [EMAIL PROTECTED]: This is fantastic! I had just been working on my own C++ binding in the spirit of Boost-Python, but I think mine is not quite as far along as yours so I'll gladly drop it and use yours. Can you please tell us what the license is for yours though? It doesn't seem to say on the webpage or in the source files. / Cody On Wed, 2007-03-28 at 23:24 +0200, [EMAIL PROTECTED] wrote: Hello, 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. (The only other possibility of doing it, using pointer to function member removed the possibility to deduce type of function arguments, resulting in a heavy syntax when declaring exported class in C++). You can check the binding library at : http://dev.kalimdor.org/entropia/node/10 It's still in development (like there is few non trivial to fix memory leak, i.e. the wrapping code that should stay alive when mono is running), but right now it works fine at exporting C++ class to C# and C# class to C++. Later, I would like the registration code to auto-generate C# header. By the way, I still have a mono debugger for embedded mono (more or less in pause, but if lot of people are interested in it, I could start working on it again). I think with all that Mono could be a really great scripting language, offering blazing speed compared to all the usual non-JIT script languages, with all the advantages of C#. Sincerely, Virgile Bello ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
