Bug 44841 - Add suggestion to "undefined reference to `vtable for ...´"
Summary: Add suggestion to "undefined reference to `vtable for ...´"
Status: RESOLVED DUPLICATE of bug 42540
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-06 15:01 UTC by Sebastian Mach
Modified: 2010-07-07 09:11 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Mach 2010-07-06 15:01:13 UTC
It was today that I stumbled over the seemingly simple situation of tweaking some bits of an interface class. 

Upon doing that, I got an undefined reference to a vtable.

I made clean and made my application. Nothing changed. Then I checked again the interface and didn't find anything. Then I checked all derivations. Nothing.

Of course it was just me who has been a fool for not recognising a missing character-tuple " = 0" behind a function signature, as in:

struct IFoo { 
    virtual ~IFoo() {}
    virtual void frob (); // <-- missing pure specifier
}; 
struct Foo : IFoo { virtual void frob () {} }; 
int main () {
    IFoo *f = new Foo();
    f->frob();
    delete f;
}


The exact error message was

  "undefined reference to `vtable for IFoo'"

As this costed me a not irrelevant amount of time, and I wouldn't describe me as unexperienced, my proposal would be to add a suggestion in case of undefined vtable, in the spirit of

  undefined reference to `vtable for IFoo'
  Suggestions:
   * Ensure that no (pure) member function of `IFoo' became unintentionally non-pure because of a missing or deleted `= 0'
   * Ensure that all non-pure member functions are defined *and* linked

Of course there exist more reasons for such vtable errors, but I think it can already improve productivity to just enumerate the most common mistakes. 

Of course I learned my lesson for now, but probably I'll forget it again in some months, and then, "undefined reference to `vtable for IFoo'" alone will again not be of much help, as described in the introduction to this report.
Comment 1 Jonathan Wakely 2010-07-06 15:26:53 UTC
(In reply to comment #0)
> 
>   undefined reference to `vtable for IFoo'
>   Suggestions:
>    * Ensure that no (pure) member function of `IFoo' became unintentionally
> non-pure because of a missing or deleted `= 0'

While I think adding a note would be helpful, the suggestion above is ridiculous. It certainly shouldn't be the first suggestion.  The answer is to ensure the first, non-inline virtual function is defined. That's it.  Suggestions about "unintentionally becoming non-pure" would cause more  confusion than they would help.

However, the error comes from the linker, so there's nothing gcc can do about it when compiling.
Comment 2 Andrew Pinski 2010-07-06 15:47:39 UTC

*** This bug has been marked as a duplicate of 42540 ***
Comment 3 Sebastian Mach 2010-07-07 06:29:34 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > 
> >   undefined reference to `vtable for IFoo'
> >   Suggestions:
> >    * Ensure that no (pure) member function of `IFoo' became unintentionally
> > non-pure because of a missing or deleted `= 0'
> 
> While I think adding a note would be helpful, the suggestion above is
> ridiculous. It certainly shouldn't be the first suggestion.  

Of course this was just a quick scratch, but stating it's ridiculous is unnecessarily offending, i.e. ridiculous in itself.

> The answer is to
> ensure the first, non-inline virtual function is defined. That's it. 

In my humble opinion, no it's not the answer, at least not in my, and I guess in many people's cases. I did not want to define it, but wanted to have a purely virtual function, without definition.

Again, the wording is just a quick scratch, but your "answer which is it" is not necessarily the right solution either.

> Suggestions about "unintentionally becoming non-pure" would cause more 
> confusion than they would help.

Well, it can be rephrased. Maybe something like "Did you intend to make it a pure virtual function? Add `= 0' then. Otherwise, ensure to define the function." would be the better solution.

> 
> However, the error comes from the linker, so there's nothing gcc can do about
> it when compiling.
> 

Okay, my fail to not know that ld bugs don't go here.
Comment 4 Sebastian Mach 2010-07-07 06:55:53 UTC
Little update: I "re-opened" this report at http://sourceware.org/bugzilla/show_bug.cgi?id=11793 .
Comment 5 Jonathan Wakely 2010-07-07 09:11:40 UTC
(In reply to comment #3)
> > The answer is to
> > ensure the first, non-inline virtual function is defined. That's it.
>
> In my humble opinion, no it's not the answer, at least not in my, and I guess
> in many people's cases. I did not want to define it, but wanted to have a
> purely virtual function, without definition.

Well if you follow my rule you'd look at your class to see which is
the first non-inline virtual and you'd realise frob() isn't pure, and
be able to change that if that's what you want.

> Again, the wording is just a quick scratch, but your "answer which is it" is
> not necessarily the right solution either.

It's better to be able to fix the general case by following a simple
rule than to make the compiler enumerate all the possible ways a user
might have got it wrong.  The ways to write invalid code are almost
infinite.  There's often only one way to get it right.

> > Suggestions about "unintentionally becoming non-pure" would cause more
> > confusion than they would help.
>
> Well, it can be rephrased. Maybe something like "Did you intend to make it a
> pure virtual function? Add `= 0' then. Otherwise, ensure to define the
> function." would be the better solution.

I disagree.  It's far more common for this error to be caused by a
missing definition, or by having no non-inline virtuals, than a function which is meant to be pure but has been declared wrong.

You've made a particular mistake and you're asking for the compiler to
be modified to tell you exactly what you need to change.  There are a
few different ways to get this error, I don't think yours is the most
common, so I don't think your suggestion is the right one.