Virtual destructor

[pmizzi]

When i compile my program with the -ansi -Wall -pedantic
flags,
i get this warning: `class vechile' has virtual functions
but non-virtual destructor, and the same with my
sub-classes. But when i add a virtual destructor like this :

" virtual ~vechile". I get this error:
Undefined first referenced
symbol in file
vtable for vechile /var/tmp//ccC9yD6Z.o
ld: fatal: Symbol referencing errors. No output written to
a.out
collect2: ld returned 1 exit status
Can anyone help me?

[Ian]

pmizzi wrote:

When i compile my program with the -ansi -Wall -pedantic
flags,
i get this warning: `class vechile' has virtual functions
but non-virtual destructor, and the same with my
sub-classes. But when i add a virtual destructor like this :

" virtual ~vechile". I get this error:

You haven't provides a body for the destructor. If it does nothing ,
then ~vechile() {} will suffice.

Ian

[E. Robert Tisdale]

pmizzi wrote:

When I compile my program with the -ansi -Wall -pedantic flags,
I get this warning: `class vechile' has virtual functions
but non-virtual destructor,
It's a warning. Ignore it.
and the same with my sub-classes.
But, when I add a virtual destructor like this:

"virtual ~vechile", I get this error:

Undefined first referenced
symbol in file
vtable for vechile /var/tmp//ccC9yD6Z.o
ld: fatal: Symbol referencing errors. No output written to
a.out
collect2: ld returned 1 exit status

Can anyone help me?

Don't define a virtual destructor if you don't need one.
If you really need a virtual destructor,
you will need virtual constructors as well.
No function should ever delete an object
that was allocated by the calling function and,
in C++, it is poor programming practice
to require the calling program
to explicitly delete an object through a pointer
returned by a function that allocated the object.

[Ali Çehreli]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:di******** **@nntp1.jpl.na sa.gov...

pmizzi wrote:

When I compile my program with the -ansi -Wall -pedantic flags,
I get this warning: `class vechile' has virtual functions
but non-virtual destructor,
It's a warning. Ignore it.

It is a warning that should not be ignored in almost all cases. A virtualy
destructor is only rarely unnecessary. Even then, not defining virtual would
be a timebomb.

Deleting a polymorphic object through a base class pointer is very common.
It is undefined behavior when the destructor is non-virtual in that case.

and the same with my sub-classes.
But, when I add a virtual destructor like this:

"virtual ~vechile", I get this error:

Undefined first referenced
symbol in file
vtable for vechile /var/tmp//ccC9yD6Z.o
ld: fatal: Symbol referencing errors. No output written to
a.out
collect2: ld returned 1 exit status

Can anyone help me?

Don't define a virtual destructor if you don't need one.

That is very rarely the case.
If you really need a virtual destructor,
you will need virtual constructors as well.
Not at all. Using a function to make the decision on what object to
construct and to return a base object pointer is very common:

Base * read_object(/* ... */)
{
/* ... */
return some_condition
? new Derived1
: new Derived2;
}

/* ... */

Base * base = read_object(/* ... */);
No function should ever delete an object
that was allocated by the calling function
I can think of a linked-list implementation that has a function, which
removes objects. Surely the objects would not be allocated in that function,
yet deleted in there.
and,
in C++, it is poor programming practice
to require the calling program
to explicitly delete an object through a pointer
returned by a function that allocated the object.

See the read_object function above. How do you propose we delete the
returned object? Of course approach is to return a suitable smart pointer
that communicates precisely the transfer of ownership, which in turn means
that the object will be deleted outside of the allocating function.

Ali

[E. Robert Tisdale]

Ali Çehreli wrote:

E. Robert Tisdale wrote:

If you really need a virtual destructor,
you will need virtual constructors as well.

Not at all. Using a function to make the decision on what object to
construct and to return a base object pointer is very common:

Base* read_object(/* ... */) {
/* ... */
return some_condition? new Derived1: new Derived2;
}

/* ... */

Base* base = read_object(/* ... */);

But it isn't good programming practice in C++.
Your program already knows about types Derived1 and Derived2
so you might as well use them in the calling program.

A virtual constructor is more "extensible ".
See Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 15: Class Hierarchies, Section 6: Free Store,
Subsection 2: Virtual constructors, pages 424-5.

[Ali Çehreli]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:di******** *@nntp1.jpl.nas a.gov...

Ali Çehreli wrote:

E. Robert Tisdale wrote:

If you really need a virtual destructor,
you will need virtual constructors as well.
Not at all. Using a function to make the decision on what object to
construct and to return a base object pointer is very common:

Base* read_object(/* ... */) {
/* ... */
return some_condition? new Derived1: new Derived2;
}

/* ... */

Base* base = read_object(/* ... */);

But it isn't good programming practice in C++.

Himmm... I don't see what you mean.

Even Stroustrup refers to such a use in C++ in the pages you quoted. My
read_object does exactly the same thing as his Ival_maker::dia l does. Maybe
naming it as "factory method" might
Your program already knows about types Derived1 and Derived2
so you might as well use them in the calling program.
My program knows of them, but the translation unit does not know of them. We
don't always mention the physical structure of code in our posts, but you
can assume that the declaration is

Base * read_object(/* ... */);

and the user is

Base * base = read_object(/* ... */);

So, Derived1 and Derived2 are know only in another translation unit, where
read_object is defined.
A virtual constructor is more "extensible ".
It is not more extensible than a function like read_object; you can extend
read_object any way we like. Besides, their application are very different:
read_object returns a brand new object, virtual constructor copies an
existing object. That's why I use virtual constructor in some of my copy
constructors.
See Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 15: Class Hierarchies, Section 6: Free Store,
Subsection 2: Virtual constructors, pages 424-5.

Thanks for the refence; I've re-read it. I think he could declare new_expr
as a static member function. Then it could be used without an existing
object; esentially using the same principle as a simple function as
read_object above.

Ali

[E. Robert Tisdale]

Ali Çehreli wrote:

E. Robert Tisdale wrote:

A virtual constructor is more "extensible ".
It is not more extensible than a function like read_object;
you can extend read_object any way we like.
Besides, their application are very different:
read_object returns a brand new object,
virtual constructor copies an existing object.
That's why I use virtual constructor in some of my copy constructors.

See Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 15: Class Hierarchies, Section 6: Free Store,
Subsection 2: Virtual constructors, pages 424-5.

Stoustrup's example shows a virtual "default constructor" (new_expr)
and a virtual "copy constructor" (clone) corresponding to
the actual constructors for class Expr.
Thanks for the refence; I've re-read it.
I think he could declare new_expr as a static member function.
Then it could be used without an existing object;
esentially using the same principle
as a simple function as read_object above.

That means that the base class would need to know about
all of the derived types which are, generally, unknown
when the base class is implemented.

[Dave Rahardja]

On Wed, 05 Oct 2005 09:03:33 -0700, "E. Robert Tisdale"
<E.************ **@jpl.nasa.gov > wrote:

pmizzi wrote:

When I compile my program with the -ansi -Wall -pedantic flags,
I get this warning: `class vechile' has virtual functions
but non-virtual destructor,
It's a warning. Ignore it.

Famous last words. Warnings should be dealt with, or at least documented,
because they indicate an error-prone construct.

Destructors should almost always be declared virtual. Without virtual
destructors derived classes stand a good chance of not getting destroyed
correctly.
If you really need a virtual destructor,
you will need virtual constructors as well.
Virtual destructors and "virtual constructors" (vis-a-vis Stroustroup) solve
very different problems. Don't confuse them with each other.
No function should ever delete an object
that was allocated by the calling function and,
in C++, it is poor programming practice
to require the calling program
to explicitly delete an object through a pointer
returned by a function that allocated the object.

Nonsense. std::auto_ptr uses that idiom.

There are situations where an Orchestrator may construct an object on the heap
derived from some base class, then passes a reference to that object on the
heap to a helper object as a reference to the base class. The helper object
then "owns" and manages that object, and will destruct it on its own schedule.

There's nothing wrong with that pattern.

-dr

[Richard Herring]

In message <di*********@nn tp1.jpl.nasa.go v>, E. Robert Tisdale
<E.************ **@jpl.nasa.gov > writes

Ali Çehreli wrote:

E. Robert Tisdale wrote:

If you really need a virtual destructor,
you will need virtual constructors as well. Not at all. Using a function to make the decision on what object to
construct and to return a base object pointer is very common:
Base* read_object(/* ... */) {
/* ... */
return some_condition? new Derived1: new Derived2;
}
/* ... */
Base* base = read_object(/* ... */);

But it isn't good programming practice in C++.
Your program already knows about types Derived1 and Derived2
so you might as well use them in the calling program.

So virtual functions are a waste of time. You heard it here first,
folks!

A virtual constructor is more "extensible ".
See Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 15: Class Hierarchies, Section 6: Free Store,
Subsection 2: Virtual constructors, pages 424-5.

--
Richard Herring

[Richard Herring]

In message <di**********@n ntp1.jpl.nasa.g ov>, E. Robert Tisdale
<E.************ **@jpl.nasa.gov > writes

pmizzi wrote:

When I compile my program with the -ansi -Wall -pedantic flags,
I get this warning: `class vechile' has virtual functions
but non-virtual destructor,
It's a warning. Ignore it.

and the same with my sub-classes.
But, when I add a virtual destructor like this:
"virtual ~vechile", I get this error:

Undefined first referenced
symbol in file
vtable for vechile /var/tmp//ccC9yD6Z.o
ld: fatal: Symbol referencing errors. No output written to
a.out
collect2: ld returned 1 exit status
Can anyone help me?

Don't define a virtual destructor if you don't need one.
If you really need a virtual destructor,
you will need virtual constructors as well.

Nonsense. They aren't paired requirements.
No function should ever delete an object
that was allocated by the calling function
ITYM "programs using pointers need a consistent, well-defined ownership
model"
and,
in C++, it is poor programming practice
to require the calling program
to explicitly delete an object through a pointer
returned by a function that allocated the object.

If the caller doesn't delete the object, what does, and how would it
obviate the need for a virtual dtor?

You've just condemned many kinds of smart pointer, garbage collection,
factory patterns, and much more, as "poor programming practice."

Personally I shall continue to use them whenever it's appropriate.

--
Richard Herring