Are you building SDC in the same fashion as clang by chance where the
pieces are modular and usable else ware? (such as the parser being able
to be used in an ide?)
On 12/9/2011 10:25 PM, Jakob Ovrum wrote:
On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote:
Why do need to re-create a new compiler not participate in the
maintenance ddmd ?
What better features than ddmd ?
I assume you are comparing SDC and DDMD on the basis that they're both
written in D. While being written in D is a main point for SDC, it's not
the only one.
SDC is written from scratch with no other dependency than LLVM. Like
LDC, it uses LLVM for the back-end, but unlike LDC, it doesn't use the
DMD front-end.
GDC and LDC inherit all the advantages and disadvantages of the DMD
front-end. They get the whole language, or at least as far as the
reference compiler implements it, up front. But they also get all the
baggage of DMD: bugs, legacy code, etc. The SDC front-end is written
with only D2 in mind and inherits no code from any C++ or D1 compiler,
while DMD was built incrementally while D was a moving target. Due to
all of this, the design of the codebase is fundamentally different from
DMD.
On the other hand, DDMD is a massive project in its own right. First you
have to convert all of DMD's sources to D, then you can get onto the
real task: turning the new code into idiomatic D instead of "C++ with a
D compiler". And you have to keep it up to date with DMD development
until DDMD is ready to take over.
It's not yet clear which approach is "better", only time will tell. But
the SDC project has already reaped benefits from its approach, and the
design allows for many improvements as the project moves forward.
Do note that as an SDC dev, I do have a bias in this comparison, but
feel free to come up with some actual arguments for DDMD :)
