Sorry if I haven't made myself clear enough. The main issue i'm worried about is memory leaks. I need to make sure the dll can be used by multiple threads and the gc be aware of each thread's memory.


On Tue, 14 Oct 2008 12:41:42 +1300, Christopher Wright <dhasenan@gmail.com> wrote:

> Tim M wrote:
>> So do I just have to use C/C++ and is there any plans / current projects that this may change in future?
>
> No, you just have to do this:
>
> extern (Windows)
> {
> 	// The application calls this
> 	void someDllFunc ()
> 	{
> 		// regular D code here
> 	}
>
> }
>
> void someNonDllFunc ()
> {
> 	// The application doesn't see this.
> }
>
>
> extern (Windows) tells the compiler to disguise the functions so they look like regular C functions in the resulting object file. It doesn't change the meaning of any code inside.

Christopher Wright wrote:

> extern (Windows) tells the compiler to disguise the functions so they look like regular C functions in the resulting object file. It doesn't change the meaning of any code inside.

Not quite. That would be extern(C). Using the Windows version will give you a function with the stdcall calling convention, which changes the order in which parameters are passed on the stack in a function call. Not a good idea to use in the general case.

Mike Parker wrote:
> Christopher Wright wrote:
> 
>> extern (Windows) tells the compiler to disguise the functions so they look like regular C functions in the resulting object file. It doesn't change the meaning of any code inside.
> 
> Not quite. That would be extern(C). Using the Windows version will give you a function with the stdcall calling convention, which changes the order in which parameters are passed on the stack in a function call. Not a good idea to use in the general case.

Groovy, thanks. I use Linux, and even there I don't use extern; thus my ignorance.