Irritating shortcoming with modules and externs

[Brad Roberts]

On Wed, 17 May 2006, Derek Parnell wrote:

> On Tue, 16 May 2006 18:22:40 -0400, Jarrett Billingsley wrote:
> 
> > Say I want to create a library which has a "pluggable function."  By 
> > that I mean that I want the library to reference an external function, 
> > defined by the user of the library.  So, in my library module, I 
> > write:

<snip>

> > The problem: even though I've defined my intFunc() to match the signature to 
> > be the same as the signature expected by the library, the linker won't 
> > resolve the reference because the function names are mangled with the module 
> > names as well.  Meaning that the linker is looking for mod.intFunc, but I've 
> > given it main.intFunc.  So I limit the ability to use the library by 
> > dictating that the user define the intFunc in a certain module (and it gets 
> > worse when multiple source levels come up).
> > 
> > One workaround is to put "extern(C)" before the reference in the library and 
> > before the definition, but I don't know if that interferes with the 
> > exception handling stuff.
> > 
> > I doubt there's any robust solution to this, but it's frustrating 
> > nonetheless.  
> 
> I've hit this limitation a few times too. The method I've used to get
> around it (which might actually be the D-way) is to isolate the "pluggable"
> function in its own module.

How about moving to a delegate model instead of a direct global symbol 
model?  It's much more obvious, imho.

Later,
Brad