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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
Copyright © 1999-2021 by the D Language Foundation