Re: Undefined reference to...
On Nov 11, 5:22 pm, Leigh Johnston <le...@i42.co.uk> wrote:
On 11/11/2010 16:58, Andrea Crotti wrote:
Leigh Johnston<le...@i42.co.uk> writes:
On 11/11/2010 09:16, James Kanze wrote:
However, what you've just shown *is* the closest working
approximation of what he seems to be trying to do. Unless he
actually wants more than one instance---it's not really clear.
For more than one instance, he'd need a factory function, e.g.
class Base
{
public:
virtual void printOut() = 0;
static std::auto_ptr<Base> getLower();
};
class Extended: public Base
{
public:
void printOut() { cout<< "hello"; }
};
std::auto_ptr<Base> Base::getLower()
{
return std::auto_ptr<Base>( new Extended );
}
This is UB as Base does not contain a virtual destructor.
Can't find anywhere what "UB" mean, but I guess something bad...
For understanding, why there should be a virtual destructor?
And in general, whenever inside the classes I'm creating I don't
allocate anything with "new", do I ever need a destructor?
Or you mean that the virtual must be present since otherwise one
subclass COULD have some memory leaks that could not be "closed" by the
auto_ptr??
"UB" means "undefined behaviour". If deleting via a base class pointer
(which is what std::auto_ptr will do in Mr Kanze's example) the base
class must have a virtual destructor.
Yes, a memory leak could occur if the derived class allocated an object
as its destructor would not be called is the base class destructor was
not virtual.
A memory leak could occur. Or the program could crash. Or it
could just seem to work. You said it right the first time: it's
undefined behavior. (FWIW, I've seen cases where it did crash.
And others where it just corrupted the free space arena, causing
a crash much later. Both involved multiple inheritance, but the
principle is there.)
--
James Kanze