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.

On 08-01-2012 01:27, 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.
>

Does the OMF format actually support 64-bit? If not, we're bound to need COFF eventually.

-- 
- Alex

On 8 January 2012 02:27, Walter Bright <newshound2@digitalmars.com> 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.
>

I'd quite like to use the VisualC linker... so I hope this isn't a substitute for implementing COFF output to the compiler at some point.

On 2012-01-08 01:27, 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.
>

I see, thanks for the explanation.

-- 
/Jacob Carlborg

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.

On 8/01/12 2:14 PM, Trass3r wrote:
> 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.

It's still far too early to start using C++11 stuff because not all compilers support it. OSX still ships with g++ 4.2. Expecting people to install a new compiler just to compile the DMD code is a pointless barrier. Especially if the only reason for using C++11 is relatively minor syntactic changes.

Smart pointers (especially shared_ptr) are not free. They will make DMD slower, compile more slowly, and bloat the syntax (T* vs. std::shared_ptr<T>). It is also a very large change to change most pointers to smart pointers. Any mistakes made in the transition will cause bugs.

All this stuff you have proposed requires time. Time is precious. What do you propose should be delayed so that this work could be carried out?

On Sunday, 8 January 2012 at 14:39:59 UTC, Peter Alexander wrote:
> It's still far too early to start using C++11 stuff because not all compilers support it. OSX still ships with g++ 4.2. Expecting people to install a new compiler just to compile the DMD code is a pointless barrier. Especially if the only reason for using C++11 is relatively minor syntactic changes.

Usage can be restricted to those features that are well supported.
Apple switched to Clang.

> Smart pointers (especially shared_ptr) are not free. They will make DMD slower, compile more slowly, and bloat the syntax (T* vs. std::shared_ptr<T>).
IIRC Clang uses them all over the place and they did carefully design everything for speed and memory efficiency.

>
> All this stuff you have proposed requires time. Time is precious. What do you propose should be delayed so that this work could be carried out?

I didn't say it has to happen today. But it should be a goal.
Investing precious time in an old linker instead of just putting out COFF and using existing alternative ones isn't the right path.

On 1/7/2012 4:40 AM, Manu wrote:
> On 7 January 2012 08:40, Nick Sabalausky <a@a.a> wrote:
>
> If by 'better' languages, you mean D, then I completely disagree. D
> *NEEDS* an IDE, just like all the rest... and in my opinion, even more
> so... here are some reasons I find it so annoying there isn't a quality
> VS integration for D (yet):


My job is primarily C++ Windows programming and I use Visual Studio. I think I agree with everything you said. In my case, I think of development tools as consisting of three components: (1) the language (2) the library/libraries including GUI, and (3) development environment, which includes debugger, IDE, etc. So even if the language is wonderful by itself, it's still not everything, and the total package may be less attractive than some other. I casually follow D progress because, besides just looking like a fun language to use, it seems to have all the elements that make a good language. But as you say, some things outside the language aren't quite there.

I use C# for small-to-medium, internal tools that have a GUI. It's great for that because of the IDE integration and also the .NET framework. The integration/intellisense is better for C# than C++. The biggest negative in the language is the lack of deterministic destruction, and that's one reason I'd favor D. (Also, having to get the .NET framework installed on users' systems is not so great, but not an issue just for internal tools. ) But the pros of IDE integration and .NET framework are greater to me than D language advantage. Visual D is helpful....but then there's the GUI library....

Not to get too far off topic, I'm the only one where I work who will use C#. I think some people simply hate Microsoft the company so much that they would not even fire up C# and try it once. They won't be caught liking it. And that's seems to be the case where I work as far as I can tell. Maybe D would be more well received than C# by such people if it integrated better with VS, I don't know. But there is always the issue with less widely used languages: if I write our company's main product in D, and if we then need to hire more people, I need to tell my boss we need to hire people that know D (or are at least willing and able pick it up) which are not as common. If anything at all goes wrong with D that wouldn't have gone wrong had we used C++, it's on me. No one ever got fired for buying IBM, lol. Sorry, I know we need to battle past that but I can't help mentioning it.

On 1/8/2012 3:02 AM, Alex Rønne Petersen wrote:
> Does the OMF format actually support 64-bit?

Nope.

> If not, we're bound to need COFF eventually.

Probably. Or elf.

On 1/8/2012 7:06 AM, Trass3r wrote:
> IIRC Clang uses them all over the place and they did carefully design everything
> for speed and memory efficiency.

Clang is a lot slower at compiling than dmc.