On Sunday, 18 March 2018 at 10:28:58 UTC, Radu wrote:
On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:
On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
You have to remember that the really big first client of
betterC(++) was DMD, porting DMD from C++ was a big
undertaking. Right now both DMD and LDC use a form of
betterC, so it is critical to have it finalized.
This is entirely wrong. DMD and LDC rely extern(C++), but this
has nothing to do with -betterC whatsoever.
Both compilers link and initialise the runtime as normal (and
then disable the GC at runtime).
— David
I stand corrected. I remembered something about druntime being
used but last time I checked front end code was filled with
strcpm and strlen, wrongly assumed that druntime was not used.
Oh well...
You're not completely wrong about this: the dmd frontend uses
almost nothing from druntime, not counting extern(C) declarations
that are really from the local libc, and nothing from Phobos.
However, I think it still requires druntime to be linked against
because of some compiler-generated symbols and the like. Also,
LDC using the D frontend has allowed a few Phobos dependencies to
creep in.
So where you were wrong is in saying dmd/ldc use betterC, which
is an extreme that precludes linking against druntime or Phobos
at all, though you could still use extern(C) declarations alone
from the stdlib. What you may have been thinking of is Walter's
plan to move the dmd backend to D written with betterC, because
he'd like to use that same D backend with his C/C++ compiler
frontends written in C/C++ and he wants to dogfood betterC there.
You weren't wrong that the dmd frontend is very much written in a
betterC style, it just isn't fully usable with betterC yet.
Still, probably D compilers will benefit from fixing mangling
bugs and allow more integration with C++ std, right?
Sure, David was simply pointing out that the betterC and
extern(C++) efforts are orthogonal and that one doesn't imply the
other: the ddmd frontend is an example of this, extensively using
extern(C++) but not enabling betterC.
