Custom calling conventions
pjmlp at progtools.org
Tue Feb 21 11:03:31 PST 2012
I think this fails in the same trap as extern "language" in C++.
Besides C and C++, I think the only variation I saw so far for the
language part has been fortran, and cannot recall anylonger in what
compiler it was.
In C++'s case, since it is implementation defined, most compiler vendors
did not bother to support more than what the standard specifies (C and C++).
In you proposal, how to keep the feature portable across D implementations?
If you make it part of D language specification, which languages would
be the chosen ones to be made available in any D compiler?
How to garantee correct interoperability (ABI) with other languages?
After deciding the set of chosen languages, which compilers/runtimes
would be the lucky ones?
Am 21.02.2012 13:29, schrieb Manu:
> On 21 February 2012 14:13, Daniel Murphy <yebblies at nospamgmail.com
> <mailto:yebblies at nospamgmail.com>> wrote:
> Why can't you do that with existing language features?
> alias JniExternFunc!(void function(int)) someJNIFuncYouWantToCallFromD;
> mixin JniExportFunc!(&dFuncYouWantToCallUsingJNI);
> Where the templates generate the wrapper code/calling convention arg
> for each function.
> You could, but that's really ugly. I did make the point in my OP that it
> can be hacked right now, but I also listed the benefits of making it a
> proper feature:
> 1. It would be very neat and tidy. Clarity and readability is
> important for code longevity.
> 2. Ease of refactoring/delegation to scripts without refactoring all
> the calling code throughout your app (this is real, I have done this on
> many occasions)
> 3. Declaring functions in the regular way, and annotating them with
> various properties (const/pure/etc) allows all the usual type safety and
> optimisation potentials available to the language.
> As far as the compiler is concerned, it is a real and normal
> function call. All surrounding code gen/optimisations are still
> applicable, the language will simply substitute the marshalling function
> at the final step of the call.
> 4-ish. It actually seems relatively simple to implement... and it's
> not a breaking change. I can't really see any down sides.
More information about the Digitalmars-d