Custom calling conventions
Artur Skawina
art.08.09 at gmail.com
Tue Feb 21 04:30:55 PST 2012
On 02/21/12 12:03, Manu wrote:
> So I was thinking about this extern(language) thing, the obvious ones are supported, but it would be really nice to be able to implement custom conventions for other languages/scripting languages.
>
> For instance, I'm thinking about Android, I have JNI binding code everywhere, it's really ugly.
> I'd love to be able to declare:
> extern(Java) int someJavaFunc(int x, float y)
>
> And then use my function like any regular function, with the 'extern(Java)' bit handling the JNI business behind the scenes.
> I also regularly interact with javascript, lua, C#/mono, and these could all be implemented the same way.
>
> I'm imaging some mechanism to declare a calling convention (which would be resolved within the extern(...) statement), and define it with a template, something like:
>
> callconv Java
> {
> R call(T...)
> {
> // process tuple of args, make the call, return something?
> }
>
> R thisCall(Class, T...)
> {
> // also need a way to implementing methods... this might be enough.
> }
> }
>
> Some fancy code in there could conceivably call into any foreign language, and this would be great!
> Now when I: import java.jni;
> I have the jni interface, but I also have access to extern(Java), and that's awesome! :)
>
> The main benefit over using a template, for instance: jniCall!"functionName"(args...), would be the function name is not a string, or require custom code construct (facilitating later re-factoring or delegation to script without changing masses of existing code, something I have done often), and if it was seen by the language as a regular function call, you can mark it with all the usual stuff, const/pure/etc, and apply the expected set of optimisations to the call.
The function-name-is-not-a-string bit can be solved:
struct jni {
int opDispatch(string func, A...)(A a) {
return lookup_wrap_or_whatever(func, a);
}
}
This will let you do jni.functionName(args...).
But a way to specify non-std calling conventions is needed, yes.
artur
More information about the Digitalmars-d
mailing list