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]

Re: c++ language design teaser


"Rajat Chadda" <rajat.chadda@w ipro.com> wrote[color=blue]
> Given a pointer within an object, C++ runtime could have been[/color]
written[color=blue]
> to delete the pointed object automatically. Why is it that they
> require a destructor to be written instead?[/color]

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]

Re: c++ language design teaser

Buster wrote:[color=blue]
> "Rajat Chadda" <rajat.chadda@w ipro.com> wrote[color=green]
>>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?[/color]
>
> 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.[/color]

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]

Re: c++ language design teaser

Alberto Barbati wrote:[color=blue]
>
> 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.
>[/color]

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]

Re: c++ language design teaser

"Buster" <noone@nowhere. com> wrote in message
news:c1agsm$mqq $1@newsg2.svr.p ol.co.uk...[color=blue]
>
> "Rajat Chadda" <rajat.chadda@w ipro.com> wrote[color=green]
> > Given a pointer within an object, C++ runtime could have been[/color]
> written[color=green]
> > to delete the pointed object automatically. Why is it that they
> > require a destructor to be written instead?[/color]
>
> 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.
>
>[/color]

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]

Re: c++ language design teaser

Rajat Chadda wrote:[color=blue]
> 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?[/color]

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]

Re: c++ language design teaser

Rajat Chadda wrote:[color=blue]
> 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?[/color]

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]

Re: c++ language design teaser


"Jorge Rivera" <jorgeri@roches ter.rr.com> wrote in message
news:bQb_b.4531 4$um1.30995@twi ster.nyroc.rr.c om...[color=blue]
> Rajat Chadda wrote:[color=green]
> > 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?[/color]
>
> 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?[/color]

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]

Re: c++ language design teaser

Pete Becker wrote:[color=blue]
> Alberto Barbati wrote:[color=green]
>>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.[/color]
>
> Be careful: using auto_ptr also gives specific meanings to the copy
> constructor and assigment operator, and those are usually not what was
> intended.[/color]

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_p tr, 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_p tr, are usually a better choice.

Alberto