digitalmars.D - (Non)Abstract Funcs, Linker Errors, and Wild Goose Chases
- Nick Sabalausky (34/34) Apr 27 2012 Consider this:
- Steven Schveighoffer (19/61) Apr 27 2012 You have my sympathy. Since working with D, I don't think I've *ever*
- Jonathan M Davis (8/11) Apr 27 2012 That would be a problem because of documentation. You need to be able to...
- Steven Schveighoffer (4/16) Apr 27 2012 Creating a stub function with implementation is quite easy.
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. 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 requesting. Thoughts?
Apr 27 2012
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. 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 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
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
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:Creating a stub function with implementation is quite easy. -SteveYou 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.
Apr 27 2012