View mode: basic / threaded / horizontal-split · Log in · Help
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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?
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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.
January 08, 2012
Re: DMD - Windows
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home