deleting the referent

[Jeff Rosenfeld]

Hi. Is there anything to be wary of when delete-ing the object to which a
reference refers? Other than being certain that the reference won't be used
again? Notwithstanding the contrived example below, is this really a
horrible thing to do, to the extent that I should avoid creating the
reference in the first place? In my actual code, B::rr is just a convenience
used during the lifetime of B.

Thanks,
- Jeff.

class R;
class B {
R& rr;
public:
B(R& r) : rr(r) {};
~B() { delete &rr; do_other_stuff_ in_B(this); };
};

int main(() {
R* pr = new R;
B b(*pr);
}

[David White]

Re: deleting the referent

Jeff Rosenfeld <spamophobe@com cast.net> wrote in message
news:UQydnTUYYN PYgJyiXTWJgQ@co mcast.com...[color=blue]
> Hi. Is there anything to be wary of when delete-ing the object to which a
> reference refers? Other than being certain that the reference won't be[/color]
used[color=blue]
> again? Notwithstanding the contrived example below, is this really a
> horrible thing to do, to the extent that I should avoid creating the
> reference in the first place?[/color]

It's not very common as far as I know. It does look a little strange, but I
don't think you can make a blanket statement about it.

I did manage to find some old code of mine that has such a reference:

CompositeGraphR esource::Compos iteGraphResourc e()
: GraphResource(G C_RES_NULL),
m_resourcePtrLi st(*new GraphResourcePt rList)
{
}

CompositeGraphR esource::Compos iteGraphResourc e(const CompositeGraphR esource
&r)
: GraphResource(r ), m_resourcePtrLi st(*new
GraphResourcePt rList(r.m_resou rcePtrList))
{
}

CompositeGraphR esource::~Compo siteGraphResour ce()
{
delete &m_resourcePtrL ist;
}

I don't remember why I did it. I guess it was just because I knew I would
never replace the referred-to object, and I must have thought that I'd
rather use . everywhere than ->. It beats me why I bothered using a
reference _or_ a pointer. Why not just make m_resourcePtrLi st a member
object? Anyway, for private use within a class like this I don't see a
problem.

I find that pointers look like things that might need deleting, but
references don't, so I guess I'd probably avoid it where it's not as local
as it was in my case. Maybe some people like using references for neatness
wherever possible and don't have any objection to it.

David

[Peter Koch Larsen]

Re: deleting the referent

"Jeff Rosenfeld" <spamophobe@com cast.net> wrote in message news:<UQydnTUYY NPYgJyiXTWJgQ@c omcast.com>...[color=blue]
> Hi. Is there anything to be wary of when delete-ing the object to which a
> reference refers? Other than being certain that the reference won't be used
> again? Notwithstanding the contrived example below, is this really a
> horrible thing to do, to the extent that I should avoid creating the
> reference in the first place? In my actual code, B::rr is just a convenience
> used during the lifetime of B.
>
> Thanks,
> - Jeff.
>
> class R;
> class B {
> R& rr;
> public:
> B(R& r) : rr(r) {};
> ~B() { delete &rr; do_other_stuff_ in_B(this); };
> };
>
> int main(() {
> R* pr = new R;
> B b(*pr);
> }[/color]

This is absolutely horrible. For a start, how can you tell if rr was
allocated using new? Your class has no evidence whatsoever that this
is so, thus verifying the correctness of B requires you to examine
every usage of it.
Even so, using a reference makes no sense at all. A reference does not
convey any hint that the refered to object could possibly be allocated
using new.

The solution: Do not delete the object in B but outside. Then you can
use new whenever you need so and automatic, faster and safer storage
in situations where this is feasible - such as main above.

Kind regards
Peter

[Jeff Rosenfeld]

Re: deleting the referent

Fair enough, but I'm not doing this as part of a library. In fact, the
equivalent to B in my case exists for as long as it takes to decide which
one of two R's is going to be deleted. The B goes away shortly after one of
the R's does. B is representative of a system state, not so much a block of
data. In fact, other parts of the system alter their behaviors when B exists
and there is never more than one B at a time.

I suppose it's possible to isolate B by passing its constructor an object
that describes the post-B action to take. That would also require that
something outside of B itself could be alerted to B's destruction (not
currently the case; B invokes delete on itself because it is the only one
that knows when its decision is made). I tried a little too hard to simplify
my example.

- Jeff.

"Peter Koch Larsen" <pkl@mailme.d k> wrote in message
news:61c84197.0 307010219.7ed80 f86@posting.goo gle.com...[color=blue]
> "Jeff Rosenfeld" <spamophobe@com cast.net> wrote in message[/color]
news:<UQydnTUYY NPYgJyiXTWJgQ@c omcast.com>...[color=blue][color=green]
> > Hi. Is there anything to be wary of when delete-ing the object to which[/color][/color]
a[color=blue][color=green]
> > reference refers? Other than being certain that the reference won't be[/color][/color]
used[color=blue][color=green]
> > again? Notwithstanding the contrived example below, is this really a
> > horrible thing to do, to the extent that I should avoid creating the
> > reference in the first place? In my actual code, B::rr is just a[/color][/color]
convenience[color=blue][color=green]
> > used during the lifetime of B.
> >
> > Thanks,
> > - Jeff.
> >
> > class R;
> > class B {
> > R& rr;
> > public:
> > B(R& r) : rr(r) {};
> > ~B() { delete &rr; do_other_stuff_ in_B(this); };
> > };
> >
> > int main(() {
> > R* pr = new R;
> > B b(*pr);
> > }[/color]
>
> This is absolutely horrible. For a start, how can you tell if rr was
> allocated using new? Your class has no evidence whatsoever that this
> is so, thus verifying the correctness of B requires you to examine
> every usage of it.
> Even so, using a reference makes no sense at all. A reference does not
> convey any hint that the refered to object could possibly be allocated
> using new.
>
> The solution: Do not delete the object in B but outside. Then you can
> use new whenever you need so and automatic, faster and safer storage
> in situations where this is feasible - such as main above.
>
> Kind regards
> Peter[/color]