November 27, 2014
On 11/25/2014 11:01 AM, Kagamin wrote:
>
> Maybe we can have a function, which will search the typeinfo based on
> type name, like C++ does it?

No!
https://issues.dlang.org/show_bug.cgi?id=7020#c2
November 27, 2014
On 11/24/2014 07:20 PM, MrSmith wrote:
> I've got little test here
> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>
>
> I have one application and two dlls. Application loads both dlls, calls
> their factory functions and then passes each IModule instance that it
> got from factories to those modules.
>
> Modules then try to cast those IModule refs back to their real
> interfaces (ISharedModule1) but i am getting null there.
>
> A have found a workaround for this by returning a void* pointer to real
> interface and it back when needed.
>
> Another, and more major issue is, that when exception is thrown
> application fail immediately.
>
> Is it broken on windows, or it is me doing it wrong?

On Windows we currently only support static linkage of phobos and druntime. DLLs do work as long as each one is isolated, once you start exchanging data across DLL boundaries you run in ODR issues.
We need to make phobos itself a DLL to solve this, but that's quite a lot of work.
November 27, 2014
On Thursday, 27 November 2014 at 11:24:45 UTC, Martin Nowak wrote:
> On 11/24/2014 07:20 PM, MrSmith wrote:
>> I've got little test here
>> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>>
>>
>> I have one application and two dlls. Application loads both dlls, calls
>> their factory functions and then passes each IModule instance that it
>> got from factories to those modules.
>>
>> Modules then try to cast those IModule refs back to their real
>> interfaces (ISharedModule1) but i am getting null there.
>>
>> A have found a workaround for this by returning a void* pointer to real
>> interface and it back when needed.
>>
>> Another, and more major issue is, that when exception is thrown
>> application fail immediately.
>>
>> Is it broken on windows, or it is me doing it wrong?
>
> On Windows we currently only support static linkage of phobos and druntime. DLLs do work as long as each one is isolated, once you start exchanging data across DLL boundaries you run in ODR issues.
> We need to make phobos itself a DLL to solve this, but that's quite a lot of work.

Can you suggest a good way to design mod system? Where each mod can depend on others and use their real functionality. All mods should be in form of dlls.

Another question is: What dll features are currently supported on linux and what they should be idealy? How do i use them?
November 28, 2014
On Thursday, 27 November 2014 at 11:21:23 UTC, Martin Nowak wrote:
> No!
> https://issues.dlang.org/show_bug.cgi?id=7020#c2

If you want interfaces to be unique, you'll have whole new dlls containing only interface definitions and probably nothing else, just for the sake of uniqueness (things like this happen in .net). And you still have to deal with templates.
November 29, 2014
On Thursday, 27 November 2014 at 21:52:27 UTC, MrSmith wrote:
> Can you suggest a good way to design mod system? Where each mod can depend on others and use their real functionality. All mods should be in form of dlls.

No DLL per module, just releasing a complete Phobos.DLL. If you want to ship a smaller Phobos.dll , build one yourself.

> Another question is: What dll features are currently supported on linux and what they should be idealy? How do i use them?

Shared library support on Linux is feature complete (we're still lacking a high level wrapper). You can compile libraries using -fPIC -shared -defaultlib=libphobos2.so for the libs and -defaultlib=libphobos2.so for the application.
https://github.com/D-Programming-Language/druntime/pull/617
December 01, 2014
On Saturday, 29 November 2014 at 13:52:11 UTC, Martin Nowak wrote:
> On Thursday, 27 November 2014 at 21:52:27 UTC, MrSmith wrote:
>> Can you suggest a good way to design mod system? Where each mod can depend on others and use their real functionality. All mods should be in form of dlls.
>
> No DLL per module, just releasing a complete Phobos.DLL. If you want to ship a smaller Phobos.dll , build one yourself.

I meant modifications, not modules here. Will it work if i have an interface and implementation of each modification in a separate shared library? How other modifications can depend on that interface? Should i simply add it to import path while compiling or i need to compile it too? This will cause a duplication of interface.

On Friday, 28 November 2014 at 12:56:10 UTC, Kagamin wrote:
> On Thursday, 27 November 2014 at 11:21:23 UTC, Martin Nowak wrote:
>> No!
>> https://issues.dlang.org/show_bug.cgi?id=7020#c2
>
> If you want interfaces to be unique, you'll have whole new dlls containing only interface definitions and probably nothing else, just for the sake of uniqueness (things like this happen in .net). And you still have to deal with templates.
Can i compile it in the same dll with its implementation?
December 02, 2014
On Monday, 1 December 2014 at 18:35:28 UTC, MrSmith wrote:
> Can i compile it in the same dll with its implementation?

Yes, you can have all implementations in the same dll, interface will only have to be directly accessible to all code seeing it.
December 02, 2014
On Tuesday, 2 December 2014 at 10:48:16 UTC, Kagamin wrote:
> On Monday, 1 December 2014 at 18:35:28 UTC, MrSmith wrote:
>> Can i compile it in the same dll with its implementation?
>
> Yes, you can have all implementations in the same dll, interface will only have to be directly accessible to all code seeing it.

Can i have interface compiled only in one dll, and others dlls that use this one will not have it compiled, only import it?
December 03, 2014
yes
December 03, 2014
On 12/02/2014 11:22 PM, MrSmith wrote:
>
> Can i have interface compiled only in one dll, and others dlls that use
> this one will not have it compiled, only import it?

Yes, you'd need to link against the dll containing the interfaces.
In fact you could link against your executable too, but that's a bit ugly.
1 2
Next ›   Last »