Export and Protected Scoping in Dynamic Libraries

[Walter Bright]

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.


> 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.