On 10/29/12, Brad Roberts <braddr@puremagic.com> wrote:
> Conclusion, the tool chains must get more user friendly.

Yep. Just compare:

$ dmd -c test.d -oftest.obj

Optlink:
$ link test.obj
> test.obj(test)
>  Error 42: Symbol Undefined _D4test1A3fooMFZv

Unilink:
$ ulink test.obj
> Error: Unresolved external 'test.A.foo()' referenced from 'test.obj'

On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:
> This code compiles with no errors, and then later the linker gives a "Symbol Undefined":
>
>
> abstract class A {
>     public void foo();
> }
> class B : A {}
> void main() {}

Interestingly, adding abstract to the method will result in no linker error for compiling. And if a new B is created then a compiler error is provided instead of a linker error.

I'm for getting some line numbers over the less informative linker error.

On 10/29/2012 1:19 PM, Brad Roberts wrote:
> There's another angle to this:
>
> 1) It's been stated more than once that one of the goals for D is to
> achieve a user base of over 1 million users.
>
> 2) I assert that there aren't more than 1 million programmers with the
> level of expertise and experience required to understand what happens
> during compilation to a sufficient degree that they feel comfortable with
> the tool chains that D (and c and c++) have today.
>
> Conclusion, the tool chains must get more user friendly.


Stroustrup estimates "more than 3 million" C++ users in 2004.

http://www.stroustrup.com/bs_faq.html#number-of-C++-users

There are probably more than that many C users.

On Mon, 29 Oct 2012, Walter Bright wrote:

> On 10/29/2012 1:19 PM, Brad Roberts wrote:
> > There's another angle to this:
> >
> > 1) It's been stated more than once that one of the goals for D is to achieve a user base of over 1 million users.
> >
> > 2) I assert that there aren't more than 1 million programmers with the level of expertise and experience required to understand what happens during compilation to a sufficient degree that they feel comfortable with the tool chains that D (and c and c++) have today.
> >
> > Conclusion, the tool chains must get more user friendly.
> 
> 
> Stroustrup estimates "more than 3 million" C++ users in 2004.
> 
> http://www.stroustrup.com/bs_faq.html#number-of-C++-users
> 
> There are probably more than that many C users.

Think there's any chance that 1/3 of the existing c++ users are going to switch to d?  In the next year?  Me neither.

The majority of D users are newish developers or developers w/out history in the C style compilation model.  It's just foreign and the majority aren't interested in having to learn about issues that the higher level languages don't require.

It's friction.  It needs to be reduced.

I say all of the above having been essentially an member of the C style compilation model, exclusively.

On 29/10/2012 22:34, Walter Bright wrote:
> On 10/29/2012 1:19 PM, Brad Roberts wrote:
>  > There's another angle to this:
>  >
>  > 1) It's been stated more than once that one of the goals for D is to
>  > achieve a user base of over 1 million users.
>  >
>  > 2) I assert that there aren't more than 1 million programmers with the
>  > level of expertise and experience required to understand what happens
>  > during compilation to a sufficient degree that they feel comfortable
> with
>  > the tool chains that D (and c and c++) have today.
>  >
>  > Conclusion, the tool chains must get more user friendly.
>
>
> Stroustrup estimates "more than 3 million" C++ users in 2004.
>
> http://www.stroustrup.com/bs_faq.html#number-of-C++-users
>
> There are probably more than that many C users.

In 2004 C++ was on the top of its game.
http://www.tiobe.com/content/paperinfo/tpci/C__.html

But, I also think 1 million is on the low side. It is probably closer to 5 (third=C,C++,alike of 15) million, excluding the "feel comfortable" part of course.
http://stackoverflow.com/questions/453880/how-many-developers-are-there-in-the-world

I also wanted to say some thing about expectations and reasons to switch..

On 10/29/2012 2:28 PM, Jesse Phillips wrote:
> On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:
>> This code compiles with no errors, and then later the linker gives a "Symbol
>> Undefined":
>>
>>
>> abstract class A {
>>     public void foo();
>> }
>> class B : A {}
>> void main() {}
>
> Interestingly, adding abstract to the method will result in no linker error for
> compiling.

That's because by saying "abstract" you're telling the compiler that there is no implementation for A.foo(), which is fundamentally different from saying that A.foo() is defined elsewhere. The compiler inserts a 0 in the vtbl[] slot for it, even though it won't let you try to call it.

> And if a new B is created then a compiler error is provided instead
> of a linker error.

Abstract types are really a different thing from "it's defined somewhere else."

> I'm for getting some line numbers over the less informative linker error.

The object file format does not support line numbers for symbol references and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff) have that. Even the symbolic debug info doesn't have line numbers for references, just for definitions.

On 10/29/2012 3:11 PM, Brad Roberts wrote:
> It's friction.  It needs to be reduced.

Short of building the linking code into dmd, the options are fairly limited.

Note that I did build the librarian code into dmd, instead of leaving it as a separate utility (lib.exe, ar), and have been pretty pleased with the results. But the librarian is a trivial piece of code.

On 10/29/12 6:13 PM, Walter Bright wrote:
> On 10/29/2012 3:11 PM, Brad Roberts wrote:
>> It's friction. It needs to be reduced.
>
> Short of building the linking code into dmd, the options are fairly
> limited.

Why can't the linking code be built into dmd? I am baffled :o).

Andrei

Andrei Alexandrescu:

> Why can't the linking code be built into dmd? I am baffled :o).

This is possible, but a better question is how much work is required to do  this?

Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways.

Bye,
bearophile

On Tuesday, October 30, 2012 01:45:31 bearophile wrote:
> Andrei Alexandrescu:
> > Why can't the linking code be built into dmd? I am baffled :o).
> 
> This is possible, but a better question is how much work is required to do this?
> 
> Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways.

Depending, it should be fairly easy to just wrap the linker call and have dmd process its output and present something saner when there's an error. That could be a bit fragile though, since it would likely depend on the exact formatting of linker error messages. Better integration than that could be quite a bit more work.

I think that it's fairly clear that in the long run, we want something like this, but I don't know if it's worth doing right now or not.

- Jonathan M Davis