View mode: basic / threaded / horizontal-split · Log in · Help
October 28, 2012
To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Re: To avoid some linking errors
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
Top | Discussion index | About this forum | D home