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]

Jeff Rosenfeld <sp********@comcast.net> wrote in message
news:UQ********************@comcast.com...

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?

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:

CompositeGraphResource::CompositeGraphResource()
: GraphResource(GC_RES_NULL),
m_resourcePtrList(*new GraphResourcePtrList)
{
}

CompositeGraphResource::CompositeGraphResource(con st CompositeGraphResource
&r)
: GraphResource(r), m_resourcePtrList(*new
GraphResourcePtrList(r.m_resourcePtrList))
{
}

CompositeGraphResource::~CompositeGraphResource()
{
delete &m_resourcePtrList;
}

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_resourcePtrList 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]

"Jeff Rosenfeld" <sp********@comcast.net> wrote in message news:<UQ********************@comcast.com>...

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);
}

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]

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" <pk*@mailme.dk> wrote in message
news:61**************************@posting.google.c om...

"Jeff Rosenfeld" <sp********@comcast.net> wrote in message

news:<UQ********************@comcast.com>...

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);
}

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