On Fri, 16 Dec 2011 01:34:32 -0800, Walter Bright <newshou...@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/

Reply via email to