"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:cf26tn$1n01$1@digitaldaemon.com...
> Instead, all communication with other language runtimes should happen via extern(...) interfaces. However, one could think of disigning another extern interface to standardize a link-compatible interface to D features, where performance is not essential.

I think the extern(C) fills that role adequately. The C calling convention is the lingua franca on most platforms, another one is not needed.

In article <cf3275$22h3$1@digitaldaemon.com>, Walter says...
>"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:cf26tn$1n01$1@digitaldaemon.com...
>> Instead, all communication with other language runtimes should happen via extern(...) interfaces. However, one could think of disigning another extern interface to standardize a link-compatible interface to D features, where performance is not essential.
>
>I think the extern(C) fills that role adequately. The C calling convention is the lingua franca on most platforms, another one is not needed.

So I guess this means you will always have to use extern(C) when making shared
libraries?

Nick

Walter wrote:
> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message
> news:cf26tn$1n01$1@digitaldaemon.com...
> 
>>Instead, all communication with other language runtimes should happen
>>via extern(...) interfaces. However, one could think of disigning
>>another extern interface to standardize a link-compatible interface to D
>>features, where performance is not essential.
> 
> 
> I think the extern(C) fills that role adequately. The C calling convention
> is the lingua franca on most platforms, another one is not needed.

So why did you invent extern(D)? If you should use extern(C) to create interoperable libraries, it is kinda stupid to have extern(D) as default.

Lars Ivar Igesund

Lars Ivar Igesund wrote:
> Walter wrote:
> 
>> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message
>> news:cf26tn$1n01$1@digitaldaemon.com...
>>
>>> Instead, all communication with other language runtimes should happen
>>> via extern(...) interfaces. However, one could think of disigning
>>> another extern interface to standardize a link-compatible interface to D
>>> features, where performance is not essential.
>>
>>
>>
>> I think the extern(C) fills that role adequately. The C calling convention
>> is the lingua franca on most platforms, another one is not needed.
> 
> 
> So why did you invent extern(D)? If you should use extern(C) to create interoperable libraries, it is kinda stupid to have extern(D) as default.
> 
> Lars Ivar Igesund

I'm trying to understand that, too. I guess it's supposed to be more efficient. Maybe the name extern(D) should be renamed to extern(DMD) if it's going to be proprietary and undocumented. I don't know whether studying the public front end code would be enough to explain what makes extern(D) special.

Perhaps Walter is saying:
Use extern(C) for now [but later when extern(D) is documented and standarized, you could probably use it, too].

(I don't know that he's stated the important bracketed part yet, but this topic is pretty much over my head.)

So there's no problem right now (we can use the C way) and the situation will even improve in the future when the D way becomes an option. We can hope anyway. :)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Lars Ivar Igesund wrote:
> Walter wrote:
> 
>> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message
>> news:cf26tn$1n01$1@digitaldaemon.com...
>>
>>> Instead, all communication with other language runtimes should happen
>>> via extern(...) interfaces. However, one could think of disigning
>>> another extern interface to standardize a link-compatible interface to D
>>> features, where performance is not essential.
>>
>>
>>
>> I think the extern(C) fills that role adequately. The C calling convention
>> is the lingua franca on most platforms, another one is not needed.
> 
> 
> So why did you invent extern(D)? If you should use extern(C) to create interoperable libraries, it is kinda stupid to have extern(D) as default.
> 
> Lars Ivar Igesund


Well, because the D calling convention, as Walter stated, uses the EAX register for the last parameter.  Since the majority of functions will have 0-1 arguments, this is a pretty decent speed increase since most of the time, the argument will already be there from a previous operation.

Since D's default behavior is interacting with other D applications, it makes sense that extern(D) should be the default so as to default to the increased speed.  If you're interoping with something that can't take advantage of that, then you use the extern(C) to use the standard C calling convention.

As a point of note, creating a DLL that actually exports extern(D) code is a major pain in the rear since you have to figure out the mangled name of your method and put THAT into your .def file.  So having to use extern(C) to interop with .NET makes life easier in other ways as well.

-Deja

Deja Augustine wrote:

> As a point of note, creating a DLL that actually exports extern(D) code is a major pain in the rear since you have to figure out the mangled name of your method and put THAT into your .def file.  So having to use extern(C) to interop with .NET makes life easier in other ways as well.

This is not a problem. Prefix all exported symbols with 'export' in code and you can omit the symbols from the .def file altogether.

Lars Ivar Igesund