Export and Protected Scoping in Dynamic Libraries

Adam Wilson flyboynw at gmail.com
Sat Dec 17 15:32:28 PST 2011


On Sat, 17 Dec 2011 11:50:39 -0800, Walter Bright  
<newshound2 at digitalmars.com> wrote:

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

Understood. I'll update my DI gen changes to bring those in.

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

I may have know that at some point, but for the most part in the classes I  
took, they said "it just works" and left it at that without any further  
explanation.

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

Well, as long as I'm around I'll be sure to pester someone when it starts  
to get stale. Dynamic libraries are fundamental to my projects.

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

I'll look into it ... my bookshelf is already creaking under the strain of  
all the programming books I should have. :-)

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


More information about the Digitalmars-d mailing list