www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Linking dynamic D library with C.

reply Fredrik Olsson <peylow gmail.com> writes:
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
Aug 04 2005
parent reply pragma <pragma_member pathlink.com> writes:
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.








export "foobar" from the dll


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
Aug 04 2005
parent reply Niko Korhonen <niktheblak hotmail.com> writes:
This answer should be a FAQ/Wiki issue if it isn't already. A very good 
read indeed.

-- 
Niko Korhonen
SW Developer
Aug 05 2005
parent reply pragma <pragma_member pathlink.com> writes:
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
Aug 05 2005
parent reply Fredrik Olsson <peylow gmail.com> writes:
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
Aug 06 2005
parent pragma <pragma_member pathlink.com> writes:
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
Aug 06 2005