std library hooks

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Sun Apr 15 15:31:30 PDT 2012


"Artur Skawina" <art.08.09 at gmail.com> wrote in message 
news:mailman.1782.1334525867.4860.digitalmars-d at puremagic.com...
> On 04/15/12 22:45, Nick Sabalausky wrote:
>> Yea, I'm now more convinced than ever that proper hooks, or at least
>> something more formalized, would be a WAAAY better way to go. I mean, I 
>> can
>> see it's technically doable the current way, but it's basically voodoo 
>> hacks
>> and unhelpful error messages. And not even reliable across different
>> linkers, apperently.
>
> The runtime as a shared lib would make things easier, btw.
>
> Hooks would add overhead.

Well there's always options.

For instance, druntime's code and build system could be designed in a way to 
specifically facilitate replacing certain functionality with custom 
alternatives at druntime's compile-time. Ie, when you build druntime, you 
could choose to use all of druntime's built in versions, or tell druntime 
and its build system to use a custom alternate for the x, y and/or z 
functions/subsystems.

So it'd be a compile-time hook, rather than runtime or link-time. I think 
that could be a perfectly reasonable approach and would provide the best of 
both worlds between the run-time and link-time approaches: No 
runtime-overhead (unless you specifically made a custom version that allowed 
runtime-selection between the builtins and other customs), and good 
diagnostics, errors, and linker compatibility.

You'd have to recompile druntime and phobos, of course, but that's easy 
enough to do: "make -f (posix|win32).mak".

> If you want to selectively replace symbols
> during the link phase, *some* linker awareness is necessary...
> And some linkers will even help you do it; another ld example:
[...] 




More information about the Digitalmars-d mailing list