Jump to page: 1 27  
Page
Thread overview
To avoid some linking errors
Oct 28, 2012
bearophile
Oct 28, 2012
Walter Bright
Oct 28, 2012
deadalnix
Oct 28, 2012
Walter Bright
Oct 28, 2012
David Nadlinger
Oct 28, 2012
Benjamin Thaut
Oct 28, 2012
Walter Bright
Oct 29, 2012
Jacob Carlborg
Oct 29, 2012
Walter Bright
Oct 29, 2012
Faux Amis
Oct 29, 2012
H. S. Teoh
Oct 29, 2012
Jacob Carlborg
Oct 29, 2012
Faux Amis
Oct 29, 2012
Jacob Carlborg
Oct 29, 2012
Jacob Carlborg
Oct 29, 2012
Dmitry Olshansky
Oct 29, 2012
Peter Alexander
Oct 29, 2012
Jacob Carlborg
Oct 29, 2012
Brad Roberts
Oct 29, 2012
Andrej Mitrovic
Oct 29, 2012
Walter Bright
Oct 29, 2012
Brad Roberts
Oct 29, 2012
Walter Bright
Oct 30, 2012
bearophile
Oct 30, 2012
Jonathan M Davis
Oct 30, 2012
Brad Roberts
Oct 30, 2012
bearophile
Oct 30, 2012
Walter Bright
Oct 30, 2012
Brad Roberts
Oct 30, 2012
Jacob Carlborg
Oct 30, 2012
H. S. Teoh
Oct 30, 2012
Brad Roberts
Oct 30, 2012
Jacob Carlborg
Oct 30, 2012
H. S. Teoh
Oct 30, 2012
Walter Bright
Oct 30, 2012
Jacob Carlborg
Oct 30, 2012
Paulo Pinto
Oct 29, 2012
Faux Amis
Oct 30, 2012
deadalnix
Oct 30, 2012
H. S. Teoh
Oct 29, 2012
Jesse Phillips
Oct 29, 2012
Walter Bright
Oct 30, 2012
Daniel Murphy
Oct 30, 2012
Walter Bright
Oct 30, 2012
Daniel Murphy
Oct 30, 2012
Walter Bright
Oct 30, 2012
Daniel Murphy
Oct 30, 2012
Jesse Phillips
Oct 30, 2012
Brad Roberts
Oct 30, 2012
Brad Roberts
Oct 30, 2012
Walter Bright
Oct 30, 2012
H. S. Teoh
Oct 31, 2012
Jacob Carlborg
Oct 31, 2012
Walter Bright
October 28, 2012
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() {}


In this bug report I have asked for the compiler to give an error:
http://d.puremagic.com/issues/show_bug.cgi?id=5129


But Walter has answered it's not a bug:

> This is not a bug, as in another module there could be a class C that derives
> from B and implements foo().
> 
> As documented, D accepts non-abstract functions with no body declared as:
> 
>    void foo();
> 
> with the idea that the user will be supplying a body somewhere else - perhaps
> even a C function or an assembler one. It's another way of doing encapsulation
> by having an opaque implementation. In fact, it's used by the TypeInfo's.


Stewart Gordon suggests:

> I think the underlying problem is that there's no mandatory explicit notation
> for externally defined functions.


So isn't it better to require (similarly to annotations like "override") the programmer to write in B an "extern" or "abstract" or something similar to state that the implementation is elsewhere (and give a nice compilation error if it's missing)?


abstract class A {
    public void foo();
}
class B : A {
	extern foo;
}
void main() {}


Or:

abstract class A {
    public void foo();
}
class B : A {
	abstract foo;
}
void main() {}


Bye,
bearophile
October 28, 2012
On 10/28/2012 6:39 AM, bearophile wrote:
> This code compiles with no errors, and then later the linker gives a "Symbol
> Undefined":
> [...]
> (and give a nice compilation error if it's missing)?

It already gives a nice error "Symbol Undefined". I don't understand why this is a problem.

  void foo() { } // defined here
  void foo();    // defined elsewhere

No need for anything more.
October 28, 2012
Le 28/10/2012 18:17, Walter Bright a écrit :
> On 10/28/2012 6:39 AM, bearophile wrote:
>> This code compiles with no errors, and then later the linker gives a
>> "Symbol
>> Undefined":
>> [...]
>  > (and give a nice compilation error if it's missing)?
>
> It already gives a nice error "Symbol Undefined". I don't understand why
> this is a problem.
>
> void foo() { } // defined here
> void foo(); // defined elsewhere
>
> No need for anything more.

As Andrei stated, the linker's native language is encrypted klingon.
October 28, 2012
On 10/28/2012 1:34 PM, deadalnix wrote:
> As Andrei stated, the linker's native language is encrypted klingon.

It baffles me that programmers would find "undefined symbol" hard to make sense of.
October 28, 2012
On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
> It baffles me that programmers would find "undefined symbol" hard to make sense of.

Do really think that your typical Java programmer is familiar with the term »symbol« in the compiler/linker sense? Also, don't underestimate the perceived scariness/ugliness of mangled names in linker error messages. I'm pretty much fluent in reading D mangled names by now, but most newcomers definitely aren't.

That, coupled with the absence of the typical source location information (IDE integration!), is probably enough to make encountering such errors a significantly more unpleasant experience for most people than compiler errors.

Again, maybe not for you, maybe not for me, but I think it is clear that this is a problem to some, so the discussion should not be about talking the problem away, but rather about evaluating possible solutions/mitigation strategies in terms of feasibility (e.g. name demangling in linker output?).

David
October 28, 2012
Am 28.10.2012 22:38, schrieb David Nadlinger:
> On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
>> It baffles me that programmers would find "undefined symbol" hard to
>> make sense of.
>
> Do really think that your typical Java programmer is familiar with the
> term »symbol« in the compiler/linker sense? Also, don't underestimate
> the perceived scariness/ugliness of mangled names in linker error
> messages. I'm pretty much fluent in reading D mangled names by now, but
> most newcomers definitely aren't.
>
> That, coupled with the absence of the typical source location
> information (IDE integration!), is probably enough to make encountering
> such errors a significantly more unpleasant experience for most people
> than compiler errors.
>
> Again, maybe not for you, maybe not for me, but I think it is clear that
> this is a problem to some, so the discussion should not be about talking
> the problem away, but rather about evaluating possible
> solutions/mitigation strategies in terms of feasibility (e.g. name
> demangling in linker output?).
>
> David


VisualD has a command line tool that demangels linker error messages and makes them more readable.

Kind Regards
Benjamin Thaut
October 28, 2012
On 10/28/2012 2:38 PM, David Nadlinger wrote:
> On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
>> It baffles me that programmers would find "undefined symbol" hard to make
>> sense of.
>
> Do really think that your typical Java programmer is familiar with the term
> »symbol« in the compiler/linker sense?

I am baffled why a programmer with even a modest skill level in any language would not know what a symbol in a programming language is.


> Also, don't underestimate the perceived
> scariness/ugliness of mangled names in linker error messages. I'm pretty much
> fluent in reading D mangled names by now, but most newcomers definitely aren't.

I see the point of that, and at one point optlink did demangle names. But that didn't change anything. There was also a filter one could run the linker output through that would demangle the names, but nobody found that useful, either, and it fell by the wayside.

You'll see the same complaints from the same people appearing for C code being linked, which does not have mangled names.


> That, coupled with the absence of the typical source location information (IDE
> integration!), is probably enough to make encountering such errors a
> significantly more unpleasant experience for most people than compiler errors.
>
> Again, maybe not for you, maybe not for me, but I think it is clear that this is
> a problem to some, so the discussion should not be about talking the problem
> away, but rather about evaluating possible solutions/mitigation strategies in
> terms of feasibility (e.g. name demangling in linker output?).

There is this, which is linked to from the faq:

    http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

I even wrote an entry in this book

    http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

about it. *Every* programmer should know what a linker does.
October 29, 2012
On 2012-10-28 22:38, David Nadlinger wrote:

> Do really think that your typical Java programmer is familiar with the
> term »symbol« in the compiler/linker sense? Also, don't underestimate
> the perceived scariness/ugliness of mangled names in linker error
> messages. I'm pretty much fluent in reading D mangled names by now, but
> most newcomers definitely aren't.
>
> That, coupled with the absence of the typical source location
> information (IDE integration!), is probably enough to make encountering
> such errors a significantly more unpleasant experience for most people
> than compiler errors.
>
> Again, maybe not for you, maybe not for me, but I think it is clear that
> this is a problem to some, so the discussion should not be about talking
> the problem away, but rather about evaluating possible
> solutions/mitigation strategies in terms of feasibility (e.g. name
> demangling in linker output?).

I completely agree. I can handle the mangled symbols as well but it would be much nicer with demangled symbols, source location and so on.

Just because I can read HTML I'm not surfing the web with "curl", I use a GUI browser that renders the HTML. It's much nicer that way.

-- 
/Jacob Carlborg
October 29, 2012
On 2012-10-28 22:57, Walter Bright wrote:

> I am baffled why a programmer with even a modest skill level in any
> language would not know what a symbol in a programming language is.

Welcome to the real world :)

> I see the point of that, and at one point optlink did demangle names.
> But that didn't change anything. There was also a filter one could run
> the linker output through that would demangle the names, but nobody
> found that useful, either, and it fell by the wayside.
>
> You'll see the same complaints from the same people appearing for C code
> being linked, which does not have mangled names.

You still don't get any source location.


> http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

That's only for optlink.

> I even wrote an entry in this book
>
>
> http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484
>
> about it. *Every* programmer should know what a linker does.

I agree with you, but again, that's not the world we live in. On the other hand, why does, say, an PHP (insert your favorite dynamic programming language that doesn't use a linker) programmer need to know what a linker is?

-- 
/Jacob Carlborg
October 29, 2012
On 29-Oct-12 01:38, David Nadlinger wrote:
> On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
>> It baffles me that programmers would find "undefined symbol" hard to
>> make sense of.
>
> Do really think that your typical Java programmer is familiar with the
> term »symbol« in the compiler/linker sense? Also, don't underestimate
> the perceived scariness/ugliness of mangled names in linker error
> messages. I'm pretty much fluent in reading D mangled names by now, but
> most newcomers definitely aren't.
>
So true.

> That, coupled with the absence of the typical source location
> information (IDE integration!), is probably enough to make encountering
> such errors a significantly more unpleasant experience for most people
> than compiler errors.
>

> Again, maybe not for you, maybe not for me, but I think it is clear that
> this is a problem to some, so the discussion should not be about talking
> the problem away, but rather about evaluating possible
> solutions/mitigation strategies in terms of feasibility (e.g. name
> demangling in linker output?).
>

Indeed, when dmd works as a driver and invokes a linker can't it just pipe its output through ddemangle?

-- 
Dmitry Olshansky
« First   ‹ Prev
1 2 3 4 5 6 7