On Monday, 19 June 2017 at 21:01:35 UTC, Honey wrote:
On Monday, 19 June 2017 at 20:26:43 UTC, Adam D. Ruppe wrote:
On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
Is it correct that D produces executables that depend on libc?
Usually yes, since that makes sense for most programs on
operating systems, but you can pull it out if you want to for
a specialized task. (Really, same boat C is in.)
Thanks, Adam!
To elaborate on my second point: if one compares, say,
FreeBSD's libc [1] with glibc [2] it is pretty obvious that not
all implementations are optimized to the same degree.
Does it make sense - at least in cerain cases - to provide and
use a D implementation that is fast on all platforms, instead?
[1] https://svnweb.freebsd.org/base/head/lib/libc/
[2] https://sourceware.org/git/?p=glibc.git;a=tree;hb=HEAD
The issue with that is that you assume:
1) that a complete libc replacement can be created from scratch
2) that a correct libc replacement can be created from scratch
3) that a better libc replacement can be created from scratch
4) that this replacement can be maintained for years to come on
all plateforms
All those points are certainly theoretically possible, but
getting all 4 at once isn't a small task. Point 2 and 3 in
particular: whatever your libc is it's been tested, reflected
upon and optimized for years by good programmers. There is
absolutely no reason to throw away this work. Even if it was
practical to do that and that the developper was confident enough
that he can do better than libc to start working on it, point 4
would be out of reach given the current state of affairs.
So, while replacing specific C functions by D implementations
where the gain is clear seems like a good idea to me, dropping
the dependency on libc seems more like a risky gamble than
anything.
