Export and Protected Scoping in Dynamic Libraries

[Adam Wilson]

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?

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.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/