Irritating shortcoming with modules and externs

[Derek Parnell]

On Tue, 16 May 2006 18:44:39 -0700, Brad Roberts wrote:

> 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

That is actually what I did in Build ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
17/05/2006 1:01:44 PM