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