Potential of a compiler that creates the executable at once
Walter Bright
newshound2 at digitalmars.com
Sat Feb 12 00:51:46 UTC 2022
On 2/11/2022 9:20 AM, max haughton wrote:
> If all the libraries rely on hooking something you will silently break all but
> one, whereas the process of overriding a runtime hook can be made into an atomic
> operation that can fail in a reasonable manner if wielded incorrectly.
Sorry, I don't follow that. I don't know what atomic ops have to do with it.
> Doing things based on the order at link-time is simply not good practice in the
> general case. It's OK if you control all the things in the stack and want to
> (say) override malloc, but controlling what happens on an assertion is exactly
> the kind of thing that resolution at link-time can make into a real nightmare to
> do cleanly (and mutably, you might want to catch assertions differently when
> acting as a web server than when loading data).
All link operations conform to the ordering I described. I can't think of a way
that is simpler, cleaner, or easier to understand. Hooking certainly ain't.
> Also linking (especially around shared libraries) doesn't work in exactly the
> same way on all platforms, so basically maximizing the entropy of a given link
> (minimize possible outcomes, so minimal magic) can be a real win when it comes
> to making a program that builds and runs reliably on different platforms. At
> Symmetry we have had real issues with shared libraries, for reasons more
> complicated than mentioned here granted, so we actually cannot ship anything
> with dmd even if we wanted to.
DLLs (shared libraries) are a different story because they are all-or-nothing.
In fact, they aren't actually libraries at all in the programming sense. They
aren't linked in, either, there's no linking involved when accessing a DLL.
More information about the Digitalmars-d
mailing list