How is it possible to invoke a virtual method that wasn't defined?  I.e., I 
have a superclass that declares
   void abc(int) = 0;

What's happening that I can instantiate a child of that class without that 
method defined, and then try to invoke the method? As far as I understand, 
the type system should be preventing that, shouldn't it?

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> How is it possible to invoke a virtual method that wasn't defined?  I.e., I 
> have a superclass that declares
>    void abc(int) = 0;

> What's happening that I can instantiate a child of that class without that 
> method defined, and then try to invoke the method? As far as I understand, 
> the type system should be preventing that, shouldn't it?

  If your compiler allows you to instantiate a class with pure virtual
functions, then your compiler is horribly buggy. Normally you should get
a compilation error along the lines of:

test.cc: In function 'int main()':
test.cc:13: error: cannot declare variable 'b' to be of abstract type 'B'
test.cc:8: note:   because the following virtual functions are pure within 'B':
test.cc:4: note:        virtual void A::abc(int)

  I guess that you are not really instantiating an abstract class, or either
you are doing something really weird which somehow is able to bypass the
compiler checks (in which case you get UB, of course).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I guess that you are not really instantiating an abstract class, or either
> you are doing something really weird which somehow is able to bypass the
> compiler checks (in which case you get UB, of course).

I don't know. I've seen it happen at runtime with "trying to invoke pure 
virtual function" on Windows, and now I'm getting some of the same sorts of 
messages from a Linux program (from a place where you're supposed to fill in 
as you port it, so not entirely unexpected).

If you had class Beta as a concrete child of abstract class Alpha, and you 
assigned a Beta to the Alpha (as in slicing it), the compiler would still 
complain when you tried to invoke the undefined function in Alpha, wouldn't it?

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New wrote:
> you assigned a Beta to the Alpha (as in slicing it),

Oh, I see that you probably shouldn't be able to do this.

OK, as I get my brain wound up to deal with this more, I'll see if I can 
figure out what's going on and follow up. Thanks!

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I don't know. I've seen it happen at runtime with "trying to invoke pure 
> virtual function" on Windows, and now I'm getting some of the same sorts of 
> messages from a Linux program (from a place where you're supposed to fill in 
> as you port it, so not entirely unexpected).

  That runtime error can happen when you call a pure virtual function from
the base class constructor (even if the object being instantiated is not
abstract). In other words:

class Base
{
 public:
    virtual void function() = 0;

    Base() { function(); }
};

  I'm not exactly sure how standard that behavior is, though. At least in
a current version of gcc you get both a warning and a linker error in this
situation if Base::function() has no implementation. However, I do remember
that in older versions of gcc it would compile and you would then get the
runtime error.

  (If the pure virtual function has an implementation in Base, what will
end happening is that this Base implementation gets called, rather than
the implementation in the derived class. Hence the warning.)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:

> I don't know. I've seen it happen at runtime with "trying to invoke pure 
> virtual function" on Windows, and now I'm getting some of the same sorts 
> of messages from a Linux program (from a place where you're supposed to 
> fill in as you port it, so not entirely unexpected).

Some of the PCs at work have some software that frequently spews out 
that error message.

Unfortunately, several users think that what the message is saying is 
"your computer doesn't have enough virtual memory", so they want me to 
add more RAM to the PC. (Yes, I realise that's completely illogical. But 
they seem pretty convinced about it, and won't accept my word that it's 
nothing to do with memory. But hey, I'm only a qualified computer expert...)

Even more unfortunately, the makers of the software have released an 
update which completely fixes this issue - but I'm not allowed to 
install it.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't know. I've seen it happen at runtime with "trying to invoke pure 
>> virtual function" on Windows, and now I'm getting some of the same sorts of 
>> messages from a Linux program (from a place where you're supposed to fill in 
>> as you port it, so not entirely unexpected).
> 
>   That runtime error can happen when you call a pure virtual function from
> the base class constructor (even if the object being instantiated is not
> abstract).

Yeah, but that would happen even if the child object implemented the 
function, yes?  In other words, this wouldn't be a bug of "you didn't 
implement the child correctly", but rather a bug that would persist even 
after the child object was correct?

Anyway, I'll be delving into this part of it pretty soon. Basically, as soon 
as I've groped thru the hardware docs to see how I have to port the stuff. 
I'll let youknow if I figure out what C++ is triggering this and how it 
manages to compile.

(I do get some compile-time warnings, but they're mostly things like unused 
member variables and switch statements that don't cover the entire 
enumeration and such. Nothing at link time and nothing about abstract classes.)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message