Official compiler

[Iain Buclaw via Digitalmars-d]

On 18 February 2016 at 22:23, Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger wrote:
>
>> On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis wrote:
>>
>>> […] if you want to be writing scripts in D (which is really useful), you
>>> need rdmd, which means using dmd
>>>
>>
>> You can use rdmd with ldmd2 just as well (and presumably gdmd too).
>>
>
> Good to know.
>
> Clear only to somebody with x86-centric vision. I'm not claiming that the
>> somewhat lower compile times aren't good for productivity. But being able
>> to easily tap into the rich LLVM ecosystem or even just targeting the most
>> widely used CPU architecture (in terms of units) is also something not to
>> be forgotten when considering the development process.
>>
>
> Having ldc is huge, but as long as you're targeting x86(_64) as one of
> your platforms, developing with dmd is going to be faster thanks to the
> fast compilation times. And if we can get dmd and ldc to be fully
> compatible like they should be, then as long as your code is
> cross-platform, it should be possible to develop it with dmd and then
> target whatever you want with ldc - though obviously some stuff will have
> to be done with ldc when it's something that dmd can't do (like a version
> block targeting ARM), and anything that's going to ultimately be released
> using ldc should be tested on it. But that fast compilation time is so
> tremendous in the edit-test-edit cycle, that I just can't see using ldc as
> the main compiler for development unless what you're doing isn't targeting
> x86(_64) at all, or ldc isn't compatible enough with dmd to do most of the
> development with dmd.
>
> But assuming that dmd and gdc/ldc are compatible, I would definitely argue
> that the best way to do D development is to do most of the development with
> dmd and then switch to gdc or ldc for production. That way, you get the
> fast compilation times when you need it, and your final binary is better
> optimized.
>
> - Jonathan M Davis
>

Actually, I'm sure this is a great way to let bugs in.  There's no saying
what could happen if you switch compiler and turn the optimisations
throttle to full.  In 99% of cases, one would hope all is good.  But the
bigger the codebase you're dealing with, the more you should really use
both side by side when testing to ensure that no heisenbugs creep in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160218/9c7896bb/attachment.html>