On 7/24/23 9:30 AM, cc wrote:
On Monday, 24 July 2023 at 09:29:09 UTC, Richard (Rikki) Andrew
Cattermole wrote:
There isn't a huge concern with which one you use.
Its quite common to use dmd for development, and ldc for release for
example.
They all share the same frontend, so they really only differ between
them by their glue code to the relevant backend and some modules in
druntime that are optional. Oh and inline assembly, although there is
some compat code in ldc/gdc for dmd style.
If dmd dies, so does ldc/gdc basically. Each one sees active
development although gdc only has one developer. Ldc keeps up with the
dmd releases pretty well.
If DMD dies, the other two will live on. This is open source after all.
Is there any list of known significant "gotchas" with moving to LDC from
DMD? Any unexpected surprises to watch out for or be careful for? I'm
thinking of all the "features" of DMD that are now considered verboten
by many users (e.g. compiling with -release, disabling of asserts or
array bounds checking, etc). Known edge cases of compiler optimization
causing different behavior between vendors?
DMD is the point of all D feature introductions, and so anything that
works with LDC should work with DMD.
It's the other way around that might cause trouble, since there may be
DMD features which haven't yet made it into LDC.
There are also subtle ways to consider things "broken" which might
affect you if you care about that. Like for instance floating point
handling is different, so you might not get exactly the same binary results.
-Steve
