unexpected 'pure virtual function' error

[Corno]

Hi all,

I thought that the 2 following functions would have the same effect;

void first()
{
ClassA a("bla");
anotherFunction(a);
}

void second()
{
anotherFunction(ClassA("bla"));
}

but when using the second alternative I get a 'calling pure virtual
function' error.
Can anybody explain what the difference is between the 2 that would explain
the error?

TIA,

Corno

 

[Alf P. Steinbach]

* Corno:

I thought that the 2 following functions would have the same effect;

void first()
{
ClassA a("bla");
anotherFunction(a);
}

void second()
{
anotherFunction(ClassA("bla"));
}

but when using the second alternative I get a 'calling pure virtual
function' error.
Can anybody explain what the difference is between the 2

In the second case you're using a temporary.

that would explain the error?

Nope, for that you'll have to post a complete small program that
demonstrates the problem (one possibility, though, is that ClassA's copy
constructor is invoked and calls a pure virtual function).

See the FAQ item "How do I post a question about code that doesn't work
correctly?" currently at <url:
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8>.

 

[Corno]

Can anybody explain what the difference is between the 2

In the second case you're using a temporary.


Nope, for that you'll have to post a complete small program that
demonstrates the problem (one possibility, though, is that ClassA's copy
constructor is invoked and calls a pure virtual function).

See the FAQ item "How do I post a question about code that doesn't work
correctly?"

I see your point about posting the code. However I don't think code is
necessary in this case. The fact that the error I got was specifically a
'pure virtual function call' is not that relevant to me. I trying to
understand how the C++ standard handles temporary variables differently from
named variables. You talk about the copy constructor, are temporary
variables always copied before the statement is executed or is there
anything else the standard has to say about this?

TIA,

Corno

 

[Alf P. Steinbach]

* Corno:

I see your point about posting the code. However I don't think code is
necessary in this case. The fact that the error I got was specifically a
'pure virtual function call' is not that relevant to me. I trying to
understand how the C++ standard handles temporary variables differently from
named variables. You talk about the copy constructor, are temporary
variables always copied before the statement is executed or is there
anything else the standard has to say about this?

(Please do include relevant context).

You're talking about the call

anotherFunction(ClassA("bla"));

No, temporaries are not always copied, and AFAIK in C++0x the temporary
will be guaranteed to /not/ be copied. However, the current standard
allows any number of copies to be made, and requires an accessible copy
constructor of the form T(T const&). Whether a copy is actually made
depends on the compiler, the code, and perhaps the phase of the moon.

Another manifestation of this -- but one that can be regarded as a
Very Nice Feature that as far as I understand it will disappear in C++0x
-- is that you cannot pass a temporary std::auto_ptr to

void foo( std::auto_ptr<Q> const& );

because std::auto_ptr doesn't have a T(T const&) copy constructor, as
required by the current standard.

 

[Ian Collins]

I see your point about posting the code. However I don't think code is
necessary in this case. The fact that the error I got was specifically a
'pure virtual function call' is not that relevant to me. I trying to
understand how the C++ standard handles temporary variables differently from
named variables. You talk about the copy constructor, are temporary
variables always copied before the statement is executed or is there
anything else the standard has to say about this?

If I'm not mistaken, from your original (lost) posting, you are passing
by value, so the first instance your object will be copied, in the
second, it might not.

With this type of behaviour, you realy should post the smallest snippet
that compiles and exhibits your problem.