Linking in libraries written in C in your D projects is easy.

But what would be best practice for using dynamic libraries written in D, for other projects written in C.

As a whole my project have a very simplistic public API, but I forsee that as I continue with v2.0 the inner workings will grow exponentially. And I am considering reimplementing it using D, as I like programming languages that actually help the programmer write good code in huge projects. But I will have to keep backward compatbility with old clients, so dropping the C API is not an option (Wrappers for Java, .NET, Perl abd then some depends on them, and rewriting all of those from scratch would be expensive).

I guess I would have to thread carefully and anly excpose C-compatible types, and write a hyeader file by hand.

But is there more to it, and can someone who have already walked down that path give me some tips before I give it a more serious atempt?

regards
	Fredrik Olsson

In article <dctolj$q9r$1@digitaldaemon.com>, Fredrik Olsson says...
>
>Linking in libraries written in C in your D projects is easy.
>
>But what would be best practice for using dynamic libraries written in D, for other projects written in C.

D has a lot of drawbacks when it comes to writing dll's.  Thankfully, most of these issues are known and can be worked around.

Exporting functions and variables from a D-based dll requires knowledge of what
the various extern() types do for the exported symbols.  Stick to
extern(Windows) or extern(C) as these create readable export names.  The
default, extern(D) is difficult to use due to how D mangles exports.

Any top-level functions exported cannot, under any circumstances, throw an exception.  This is becuase the top-level exception handler, as compiled into the dll by DMD, has no way to bind to an external client.  The default behavior, is to terminate your program when one of your exports throws.  Simply catch everything at the top level, and set a flag to be gathered elsewhere if you must give exception information back to the dll's client.

The GC will not be aware of anything happening outside the dll.  If you are passing data from the dll back to the client, make sure that it has a reference held inside the dll so that data isn't prematurely collected.

D doesn't provide a way to export an entire class, so you'll have to work around this by exporting static methods and global functions instead.

Keep in mind that the dll's runtime type information is a completely separate set of structures in memory than the client's runtime type information.  If you are returning objects via exported functions, expect the client's attempt to cast those objects to fail miserably.

# // in the dll
# class Foobar{}
# export extern(C) Object foobar(){ return new Foobar(); }

# // in the client
# extern(C) Object function() FoobarExport;
# FoobarExport myFoobar = cast(FoobarExport)dll.getSymbol("foobar"); // gets the
export "foobar" from the dll
# Foobar foo = cast(Foobar) myFoobar(); //** this cast will fail **

This limitation applies for objects and types passed *to* the dll as well.

In light of this, stick to scalar data when defining your exports (this also helps with GC issues).  If you absolutely must pass a class, define your exports in terms of solitary interfaces (that don't inherit from other interfaces) to avoid casting; at least this way, you can reasonably expect an interface cast to fail.  Also, make sure that both the client and the dll are using the same version of that interface.

- EricAnderton at yahoo

This answer should be a FAQ/Wiki issue if it isn't already. A very good read indeed.

-- 
Niko Korhonen
SW Developer

In article <dcv3ek$1t37$2@digitaldaemon.com>, Niko Korhonen says...
>
>This answer should be a FAQ/Wiki issue if it isn't already. A very good read indeed.
>
>-- 
>Niko Korhonen
>SW Developer

Thank you.  Its now a part of the D Wiki:

http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices/DLL

I've added a little bit about shared GC's and how class v-tables are sensitive to dll unloading.

I came to be well-versed on the topic due to my project: DSP.  You may find my development 'journal' there of some help too, as I've spent over a year-and-a-half stumbling over all these little problems.

http://www.dsource.org/forums/viewtopic.php?t=677

On more than one occasion, I've outlined what it would take for D to overcome these pitfalls.  Sadly, they're way beyond the scope of this group as it would involve nothing short of advanced compiler changes and the current language spec.

- EricAnderton at yahoo

pragma wrote:
> In article <dcv3ek$1t37$2@digitaldaemon.com>, Niko Korhonen says...
> 
>>This answer should be a FAQ/Wiki issue if it isn't already. A very good read indeed.
>>
>>-- 
>>Niko Korhonen
>>SW Developer
> 
> 
> Thank you.  Its now a part of the D Wiki:
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices/DLL
> 
> I've added a little bit about shared GC's and how class v-tables are sensitive
> to dll unloading.
> 
> I came to be well-versed on the topic due to my project: DSP.  You may find my
> development 'journal' there of some help too, as I've spent over a
> year-and-a-half stumbling over all these little problems.
> 
> http://www.dsource.org/forums/viewtopic.php?t=677
> 
> On more than one occasion, I've outlined what it would take for D to overcome
> these pitfalls.  Sadly, they're way beyond the scope of this group as it would
> involve nothing short of advanced compiler changes and the current language
> spec.
> 
> - EricAnderton at yahoo

A very good read indeed. Now only SSL and database connectivity (To PostgreSQL) is left, and then I will have reimplemented the client parts of my project. In much less time then the original ANSI C version, and it is not only because it always goes faster the second time you go around to implement it :). D rocks, and so do the response from the comunity I have got so far as well!

regards
	Fredrik Olsson

In article <dd26vp$1dak$1@digitaldaemon.com>, Fredrik Olsson says...
>
>pragma wrote:
>> In article <dcv3ek$1t37$2@digitaldaemon.com>, Niko Korhonen says...
>> 
>>>This answer should be a FAQ/Wiki issue if it isn't already. A very good read indeed.
>>>
>>>-- 
>>>Niko Korhonen
>>>SW Developer
>> 
>> 
>> Thank you.  Its now a part of the D Wiki:
>> 
>> http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices/DLL
>> 
>> I've added a little bit about shared GC's and how class v-tables are sensitive to dll unloading.
>> 
>> I came to be well-versed on the topic due to my project: DSP.  You may find my development 'journal' there of some help too, as I've spent over a year-and-a-half stumbling over all these little problems.
>> 
>> http://www.dsource.org/forums/viewtopic.php?t=677
>> 
>> On more than one occasion, I've outlined what it would take for D to overcome these pitfalls.  Sadly, they're way beyond the scope of this group as it would involve nothing short of advanced compiler changes and the current language spec.
>> 
>> - EricAnderton at yahoo
>
>A very good read indeed. Now only SSL and database connectivity (To PostgreSQL) is left, and then I will have reimplemented the client parts of my project. In much less time then the original ANSI C version, and it is not only because it always goes faster the second time you go around to implement it :). D rocks, and so do the response from the comunity I have got so far as well!
>
>regards
>	Fredrik Olsson

In that case, take a look at DDBI for your databasing needs.  It might be what you need:

http://jeremy.cowgar.com/ddbi/

Where OpenSSL and D is concerned, I think that's virgin territory.  There was some talk about it last year, but nothing really came of it.  A binding to that library would be valuable to the community, so I urge you to consider contributing it to dsource.org in some fashion should you get something working. :)

Happy Hacking,

- EricAnderton at yahoo