c++ language design teaser

[Rajat Chadda]

Given a pointer within an object, C++ runtime could have been written
to delete the pointed object automatically. Why is it that they
require a destructor to be written instead?

 

[Buster]

Given a pointer within an object, C++ runtime could have been written
to delete the pointed object automatically. Why is it that they
require a destructor to be written instead?

Not all pointers point to dynamically created objects. Not all
dynamically created objects are created with new. Not all objects
containing pointers (even pointers to dynamically created objects)
own the pointed-to object. That's just off the top of my head.

Hope that helps,
Buster.

 

[Alberto Barbati]

Not all pointers point to dynamically created objects. Not all
dynamically created objects are created with new. Not all objects
containing pointers (even pointers to dynamically created objects)
own the pointed-to object. That's just off the top of my head.

Good answer. I would add that if one doesn't want (or is too lazy) to
write a destructor, he/she can just use std::auto_ptr or any other smart
pointer class instead of using a bare pointer.

Alberto

 

[Pete Becker]

I would add that if one doesn't want (or is too lazy) to
write a destructor, he/she can just use std::auto_ptr or any other smart
pointer class instead of using a bare pointer.

Be careful: using auto_ptr also gives specific meanings to the copy
constructor and assigment operator, and those are usually not what was
intended.

 

[Cy Edmunds]

Not all pointers point to dynamically created objects. Not all
dynamically created objects are created with new. Not all objects
containing pointers (even pointers to dynamically created objects)
own the pointed-to object. That's just off the top of my head.

Hope that helps,
Buster.

Good list. I will also add that destructors don't necessarily have anything
to do with deleting pointers. They can free other resources (e.g. files) or
do other kinds of cleanup activities which have nothing to do with releasing
resources.

 

[Andrey Tarasevich]

Given a pointer within an object, C++ runtime could have been written
to delete the pointed object automatically. Why is it that they
require a destructor to be written instead?

Because in many cases the object pointed by the pointer is not supposed
to be deleted with the object that stores the pointer.

 

[Jorge Rivera]

Given a pointer within an object, C++ runtime could have been written
to delete the pointed object automatically. Why is it that they
require a destructor to be written instead?

All of the answers I heard are very solid, however, I think it might
have more to do with bindings to C programming paradigms and design than
all the other commentary.

I am pretty sure that there are countless solutions to this problem,
however, the requirement of backward compatibility with C makes this
more complex than originally intended. Furthermore, it makes C++ more
disimilar to C, which might have been considered a bad thing.

Comments?

JLR

 

[Mike Wahler]

All of the answers I heard are very solid, however, I think it might
have more to do with bindings to C programming paradigms and design than
all the other commentary.

I am pretty sure that there are countless solutions to this problem,
however, the requirement of backward compatibility with C makes this
more complex than originally intended. Furthermore, it makes C++ more
disimilar to C, which might have been considered a bad thing.

Comments?

Yes. You wrote above:

"I am pretty sure that there are countless solutions to this problem"

OP did not describe any problem.

-Mike

 

[Alberto Barbati]

Be careful: using auto_ptr also gives specific meanings to the copy
constructor and assigment operator, and those are usually not what was
intended.

Good you noticed. Generally speaking, std::auto_ptr is ok for classes
that are not going to be copied/assigned. When an std::auto_ptr is
around, forbidding the copy ctor and assignment operator is usually a
good thing, unless you know what you're doing. Alternatively, one could
avoid std::auto_ptr in favor of boost::scoped_ptr, which has exactly the
right semantic (i.e.: it invokes delete on destruction but it's
non-copiable).

If the class is going to be copied and/or assigned, other smart pointer
classes, for example boost::shared_ptr, are usually a better choice.

Alberto