On 11/15/2013 12:00 AM, Daniel Murphy wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message
> news:l64imh$27na$1@digitalmars.com...
>>
>> Also, at least on Windows, you can call functions in a DLL without saying
>> dllimport on them and suffering a layer of indirection. The magic happens
>> in the import library, which provides the relevant thunk. It's about 15
>> years since I worked on this stuff, so I might be a bit fuzzy on the
>> details.
>
> The symbol in the import library just translates to an import table
> indirection.

Yes, meaning the compiler doesn't have to do it if the import library is set up correctly. (implib.exe should do it.)

Am 15/11/2013 08:27, schrieb Walter Bright:
> On 11/14/2013 3:37 AM, Benjamin Thaut wrote:
>> Am 14.11.2013 11:28, schrieb Walter Bright:
>>> On 11/12/2013 2:23 PM, Martin Nowak wrote:
>>>
>>> One possibility is modules listed on the command line are regarded as
>>> export==dllexport, and other modules as export==dllimport.
>>>
>>> This of course means that functions may wind up going through the
>>> dllimport indirection even for calling functions in the same dll, but it
>>> should work.
>>
>> That doesns't work for the case where a dll "A" uses a dll "B".
>> In that case export has to mean "dllexport" for all modules of A but
>> "dllimport"
>> for all modules of B.
>
> I don't follow. If you're compiling A, you're specifying A modules on
> the command line, and those will regard the B modules as dllimport.
>

Ok now I understand what you suggest. So basically you want to do the exact same as DIP 45 just giving the compiler parameter a different name.

But you still didn't give a solution for the problem that the compiler does not know which modules are part of a shared library, which are part of a static library and which are part of the exeuctable. And please also consider single file compilation.

Kind Regards
Benjamin Thaut

Am 15/11/2013 08:32, schrieb Walter Bright:
> It's not that bad. Phobos can be built by specifying all the files on
> the command line.
>
> Also, at least on Windows, you can call functions in a DLL without
> saying dllimport on them and suffering a layer of indirection. The magic
> happens in the import library, which provides the relevant thunk. It's
> about 15 years since I worked on this stuff, so I might be a bit fuzzy
> on the details.

I know that. And we are using that fact in DIP 45. For data symbols we did suggest a similar behaviour that has to be implemented by us first. And yes we need data symbols, because of all the implicit data symbols the D programming language generates. TypeInfos, vtables etc.

I suggest that you read all the links I gave for further reading in DIP 45 and DIP 45 again, because you are pretty close to what we suggested in DIP 45 without actually realizing it.

Kind Regards
Benjamin Thaut

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:l64lji$2buh$1@digitalmars.com...
> On 11/15/2013 12:00 AM, Daniel Murphy wrote:
>> "Walter Bright" <newshound2@digitalmars.com> wrote in message news:l64imh$27na$1@digitalmars.com...
>>>
>>> Also, at least on Windows, you can call functions in a DLL without
>>> saying
>>> dllimport on them and suffering a layer of indirection. The magic
>>> happens
>>> in the import library, which provides the relevant thunk. It's about 15
>>> years since I worked on this stuff, so I might be a bit fuzzy on the
>>> details.
>>
>> The symbol in the import library just translates to an import table indirection.
>
> Yes, meaning the compiler doesn't have to do it if the import library is set up correctly. (implib.exe should do it.)
>

Right, I was saying the indirection still exists.

On 15.11.2013 08:02, Benjamin Thaut wrote:
> Am 15.11.2013 00:38, schrieb Rainer Schuetze:
>>
>> Maybe. Another rule might be that only the declarations actually
>> annotated with "export" gets exported with the instantiation, so you
>> could add "export" to the whole class or only some declaraations.
>>
>
> I don't think this is a good idea. It should be possible to put
> "export:" on top of a file and just export everything. If you limit it
> to decelerations the following would work:
>
> export __gshared int g_var;
>
> but the following wouldn't:
>
> export __gshared int g_var = 0;
>
> Although it would really produce equivalent code.

I don't follow. What does this have to do with template instances?
I was referring to your example where you wanted to export just one symbol from a template class.

>
>>
>> compiling c and d as single files will silently generate different code,
>> because when compiling d, the export alias is never seen.
>>
>> (this cannot happen with standard variables, only when declared multiple
>> times, but differently, with extern(C/C++/System)).
>
> And do you already have a idea how we could work around this problem?
>

It might be possible to produce some linker errors: e.g. the dllimport version drags in the __imp_var symbol that also provides a _var definition record that produces some link error (e.g. by referring to a non-existing symbol). If it links to a non-dllimport version that actually refers to _var, it bails out.

Generated COMDAT records that define the _var symbol aswell might cause problems here, though, because the current COMDAT selection strategy is "pick any".

Am 15/11/2013 18:04, schrieb Rainer Schuetze:
>
>
> I don't follow. What does this have to do with template instances?
> I was referring to your example where you wanted to export just one
> symbol from a template class.
>

Then I misunderstood your use of the word "declaration". With declarations you did mean template declarations only?

On 15.11.2013 18:18, Benjamin Thaut wrote:
> Am 15/11/2013 18:04, schrieb Rainer Schuetze:
>>
>>
>> I don't follow. What does this have to do with template instances?
>> I was referring to your example where you wanted to export just one
>> symbol from a template class.
>>
>
> Then I misunderstood your use of the word "declaration". With
> declarations you did mean template declarations only?
>

I actually meant declaration inside template definitions as in your example:

class WeakReferenced(T)
{
  export __gshared WeakReferenced!T[] m_weakTable;
}

The proposal was that

export alias WeakReferenced!int exported_weak_int_array;

would only export the symbol for m_weakTable, not any other class symbols like the class info.

I'm not sure if this is a good idea, I'm just exploring possibilities here.

Am 15/11/2013 18:41, schrieb Rainer Schuetze:
>
>
> I actually meant declaration inside template definitions as in your
> example:
>
> class WeakReferenced(T)
> {
>    export __gshared WeakReferenced!T[] m_weakTable;
> }
>
> The proposal was that
>
> export alias WeakReferenced!int exported_weak_int_array;
>
> would only export the symbol for m_weakTable, not any other class
> symbols like the class info.
>
> I'm not sure if this is a good idea, I'm just exploring possibilities here.

Sounds good to me. It gives the ability to percisely select what gets exported and what not. Basically also matches was C++ does.

On 11/13/2013 09:45 PM, Benjamin Thaut wrote:
> Would you mind moving this discussion to another thread? Everytime I see
> a update I think its something relevant and usually its just about
> object.factory.

Yes please, OT discussions ruin every focus.

On 11/14/2013 11:28 AM, Walter Bright wrote:
>
> One possibility is modules listed on the command line are regarded as
> export==dllexport, and other modules as export==dllimport.

We've considered this and it doesn't work for separate compilation.
This means I couldn't compile phobos dll with unittests.