www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - (Non)Abstract Funcs, Linker Errors, and Wild Goose Chases

reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
Consider this:

abstract class Base
{
    void foo();  // Oops! Forgot "abstract"!
}

AIUI, that's *legal* because of two things:

1. Abstract classes are allowed to include functions that *do* have 
implementations.

2. D's compilation model, inherited from C, allows functions to be 
implemented in a separate source file if you use function stubs, such as 
above.

In D's abstract classes, wanting to include an abstract function is much, 
much more common than wanting to include 
separate-compilation/function-stubbing. So get it wrong, and thanks to those 
two normally-benign features above, you're treated to a mangled, ugly linker 
error and the associated deep-sinking feeling of "......Fuck!"

Now, maybe I was simply being stupid, but I just wasted two full days 
getting tripped up by this damn, uhh, non-bug. Completely reworked my whole 
approach at least a couple times trying to work around...the wrong issues. 
Even ran DustMite a couple times trying to get a test case demonstrating 
(what I *thought* was) DMD forgetting to instantiate some templated code. 
Only to eventually solve the whole damn thing by just simply typing in a 
stupid...little..."abstract ". Ugh.

The fact that optlink crashed while spitting out the errors certainly didn't 
help point me in the right direction. That's, of coruse, in addition to the 
"Symbol undefined" errors including some fun red herrings that appered to be 
from inside druntime/phobos.

There is an issue in bugzilla for this, #6485 ( 
http://d.puremagic.com/issues/show_bug.cgi?id=6485 ), but *unfortunately* I 
think it's invalid for the reasons I described above. However, maybe it's 
just frustration over the last couple days talking, but I think at least 
*something* should be done about this, even if it's not what #6485 is 
requesting.

Thoughts?
Apr 27 2012
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Apr 2012 03:36:48 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 Consider this:

 abstract class Base
 {
     void foo();  // Oops! Forgot "abstract"!
 }

 AIUI, that's *legal* because of two things:

 1. Abstract classes are allowed to include functions that *do* have
 implementations.

 2. D's compilation model, inherited from C, allows functions to be
 implemented in a separate source file if you use function stubs, such as
 above.

 In D's abstract classes, wanting to include an abstract function is much,
 much more common than wanting to include
 separate-compilation/function-stubbing. So get it wrong, and thanks to  
 those
 two normally-benign features above, you're treated to a mangled, ugly  
 linker
 error and the associated deep-sinking feeling of "......Fuck!"

 Now, maybe I was simply being stupid, but I just wasted two full days
 getting tripped up by this damn, uhh, non-bug. Completely reworked my  
 whole
 approach at least a couple times trying to work around...the wrong  
 issues.
 Even ran DustMite a couple times trying to get a test case demonstrating
 (what I *thought* was) DMD forgetting to instantiate some templated code.
 Only to eventually solve the whole damn thing by just simply typing in a
 stupid...little..."abstract ". Ugh.

 The fact that optlink crashed while spitting out the errors certainly  
 didn't
 help point me in the right direction. That's, of coruse, in addition to  
 the
 "Symbol undefined" errors including some fun red herrings that appered  
 to be
 from inside druntime/phobos.

 There is an issue in bugzilla for this, #6485 (
 http://d.puremagic.com/issues/show_bug.cgi?id=6485 ), but  
 *unfortunately* I
 think it's invalid for the reasons I described above. However, maybe it's
 just frustration over the last couple days talking, but I think at least
 *something* should be done about this, even if it's not what #6485 is
 requesting.

 Thoughts?

You have my sympathy. Since working with D, I don't think I've *ever* used the "declare then implement" model. My personal opinion is that the compiler should require .di files for declaring stubbed methods. Other than that, I don't see a way to "fix" this problem, because you absolutely have to be able to declare an abstract class with non-abstract methods. If you want a fully abstract class, use an interface ;) Another thought, burn this into your neurons: abstract class C { abstract: ... } At least you only have to type it *once*. Of course, you'd have to put all concrete methods before the abstract, which may hinder organization of your methods. No really good solutions, sorry :( -Steve
Apr 27 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, April 27, 2012 06:57:28 Steven Schveighoffer wrote:
 You have my sympathy. Since working with D, I don't think I've *ever*
 used the "declare then implement" model. My personal opinion is that the
 compiler should require .di files for declaring stubbed methods.

That would be a problem because of documentation. You need to be able to include stubbed out functions for ddoc (Phobos generally does that with version(StdDdoc) when it needs to), otherwise platform-specific stuff doesn't end up in the documentation when you generate it on _other_ platforms. And I think that it would be unreasonable to require that that be done with .di files. - Jonathan M Davis
Apr 27 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 27 Apr 2012 13:31:22 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Friday, April 27, 2012 06:57:28 Steven Schveighoffer wrote:
 You have my sympathy. Since working with D, I don't think I've *ever*
 used the "declare then implement" model. My personal opinion is that the
 compiler should require .di files for declaring stubbed methods.

That would be a problem because of documentation. You need to be able to include stubbed out functions for ddoc (Phobos generally does that with version(StdDdoc) when it needs to), otherwise platform-specific stuff doesn't end up in the documentation when you generate it on _other_ platforms. And I think that it would be unreasonable to require that that be done with .di files.

Creating a stub function with implementation is quite easy. -Steve
Apr 27 2012