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