Export and Protected Scoping in Dynamic Libraries

[Walter Bright]

On 12/17/2011 11:22 AM, Adam Wilson wrote:
> On Sat, 17 Dec 2011 01:33:33 -0800, Walter Bright <newshound2 at digitalmars.com>
> wrote:
>
>> On 12/16/2011 9:01 PM, Adam Wilson wrote:
>>> On Fri, 16 Dec 2011 01:34:32 -0800, Walter Bright <newshound2 at digitalmars.com>
>>> wrote:
>>>
>>>> On 12/14/2011 11:41 AM, Adam Wilson wrote:
>>>>> Hello Everyone,
>>>>>
>>>>> I want to start this conversation by pointing out that I come from a C/C++/C#
>>>>> background and my ideas and frustrations in this post will be colored by that
>>>>> history.
>>>>>
>>>>> When I first approached D, the idea of an 'export' confused me. I've since
>>>>> figured out, at least in libraries, that in C# terms D's 'export' means
>>>>> 'public'.
>>>>
>>>> I'm not too familiar with C#'s public, but what D 'export' means is a function
>>>> is an entry point for a DLL. In the Windows world, that means it gets an extra
>>>> level of indirection when calling it, and it corresponds to:
>>>>
>>>> __declspec(export)
>>>>
>>>> in Windows compilers.
>>>
>>> Huh, I didn't know that. It makes sense though, I recall using
>>> __declspec(dllexport) in MSVC and hating the unwieldy syntax. Does it perform a
>>> similar function on other OS'es?
>>
>> No, as such magic isn't necessary. Any public symbol will be automatically
>> accessible from a shared library.
>
> So my understanding then is that, for dynamic libs on OS'es like Linux/OSX, DI
> files also need to include members marked public?

The member function will be called through the vtbl[]. But for the compiler to 
know that member even exists, and where it is in the vtbl[], it needs to be in 
the .di file.

> And how does the compiler
> treat the export keyword on systems that don't need it? I am assuming they are
> treated as publics?

Yes.


>>> C#'s public means "this function can be used anyone, including other libraries
>>> or executables", which according to the D docs, is what D's export means. C#
>>> also has 'protected' and 'internal protected'. 'protected' is available to any
>>> subclass, even those outside of the library, and 'internal protected' is only
>>> available to subclasses within the same library.
>>>
>>> It's actually quite a useful to have that distinction. For example, in WPF you
>>> end up subclassing the system classes (which are in separate DLL's) repeatedly
>>> and it is an encouraged pattern to extend existing functionality with your own.
>>> The reason I went with the syntax I did is that it doesn't add any new keywords
>>> and is, I think, even more clear about the programmers intentionality than C#'s
>>> scoping model. If 'export' really is just the equivalent of
>>> __declspec(dllexport) then it makes even more sense as an attribute and not a
>>> scope in it's own right.
>>>
>>>>> However, this raise a problem, specifically, how do I export a
>>>>> protected member from a dynamic library?
>>>>
>>>> Do you mean how does one directly call a protected function inside a DLL from
>>>> outside that DLL, without going through the virtual table?
>>>
>>> What I am after is a member that can be overridden in a subclass outside of the
>>> DLL but is otherwise only reachable within the module it's defined in. Mr.
>>> Carlborg's code example is spot on.
>>
>> It isn't necessary to export a protected symbol in order to override it.
>
> I see, that's a neat little trick. +1 for D!

C++ works the same way.


> So for DI file generation I should
> just include the protected members in the file and let the compiler sort it out?

Yes.


> I know DLL's are relatively new to D so not much documentation exists about how
> they work in D. I think this would be something good to document, especially the
> special behaviors for Windows. I have to admit that, coming from a C# and C++
> background, I've been a little confused by how the scope system works in
> relation to dynamic libraries and have been shooting the dark trying to figure
> it out. Thanks for the clarifications! Hopefully this lesson will become part of
> the D lore surrounding dynamic libs. :-)

DLL's have been supported in D forever, but hardly anyone uses them, and 
sometimes they get bit rotted.

I strongly recommend Jeffrey Richter's book "Advanced Windows" for a low level 
and lucid explanation of how DLLs work.