On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:
On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
Will dmd still produce OMF or will it be changed to produce
COFF?
It will be irrelevant, as the linker will read whatever it puts
out, and the linker will read COFF.
There is no reason why a linker cannot transparently read many
object and library file formats. I even want the linker to be
able to read a DLL and figure out how to interface it without
needing to build a corresponding import library.
There's quite a bit that can be done that was impractical for
linkers of yore because of severe memory constraints.
Yet you are the only one who can maintain optlink, just as you
are the only one who can process pull requests. The latter is
much more important, especially since there already are stable
alternative linkers with more features.
e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes
severe bugs with postblits/destructors and has been open for 4
months already without any comment from your side. We have to
live with the fact that bugs are fixed somewhat randomly (i.e.
the bugzilla voting system is completely ignored), but it isn't
acceptable that we have to deal with bugs that have been fixed
months ago but just not merged yet. Bug 314 is a prime example
for all of that (most voted bug for years, fixed in ldc long ago,
pull request was open for ages).
Also the dmd code needs improvement. It should leverage C++11
features, become more modular and code quality needs to be
improved. For example the typed Array was long overdue, yet
people still use that crappy tdata() syntax instead of just [].
The C++11 range based for loop would be a logical next step for
that. Other things that come to my mind are replacing hard-coded
values with proper constants, introducing smart pointers so at
least some memory is released and better (documentation) comments.
