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]

"Rajat Chadda" <ra**********@wipro.com> wrote

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]

Buster wrote:

"Rajat Chadda" <ra**********@wipro.com> wrote

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.

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]

Alberto Barbati wrote:

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Cy Edmunds]

"Buster" <no***@nowhere.com> wrote in message
news:c1**********@newsg2.svr.pol.co.uk...

"Rajat Chadda" <ra**********@wipro.com> wrote

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.

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.

--
Cy
http://home.rochester.rr.com/cyhome/

[Andrey Tarasevich]

Rajat Chadda wrote:

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.

--
Best regards,
Andrey Tarasevich

[Jorge Rivera]

Rajat Chadda wrote:

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]

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message
news:bQ*******************@twister.nyroc.rr.com...

Rajat Chadda wrote:

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?

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]

Pete Becker wrote:

Alberto Barbati wrote:

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.

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