Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!sol.ctr.columbia.edu!caen!uflorida!gatech!mcnc!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Smart pointers and stupid people (was: garbage collection...)
Message-ID: <3702@lupine.NCD.COM>
Date: 4 Feb 91 21:01:26 GMT
References: <4114@osc.COM> <3342@lupine.NCD.COM> <4173@osc.COM>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 48

In article <4173@osc.COM> tma@osc.UUCP (Tim Atkins) writes:
+Responding to Ron Guilmete's post on limiting pointer bugs...
+
+This is a pretty interesting proposal but it seems to break down when
+object movement is allowed.  I assume it is to be considered a bug
+if an object moves but a subsequent update goes to the old location
+of the object instead of the new one.  Even with good encapsulation I'm
+not sure that you will get much joy in the situation that a smart
+pointer is dereferenced and stored by the C or object code generated
+in a register just before some other arbitrary function gets executed
+which results in a situation where the object moves...

You talk about a "smart point being dereferenced".  I assume by that you
mean a smart pointer being turned into a dumb pointer so that the
pointed-at object can actually be accessed.

Anyway, I don't think that this is a problem.  The basic idea in my
proposal is *not* to make everyone wear bullet-proof vests so that nobody
could ever do themselves any dammage by accidently discharging some firearms.
Rather, my idea was to give people safety catches on their firearms so that
they could protect themselves when they conciously decided they needed to.

In short, to make use of the ideas in my proposal, you would still be
required to cooperate by programming carefully.  In particular, you would
have to limit the regions of code in which dumb pointers are generated
and/or used, and in those (hopefully few) areas, you would have to
avoid doing things which may cause the pointed-at objects to move around
or to be deleted (thus invalidating one or more of the "stupid" pointers
that you are manipulating in that small region of code).

I think a good analogy is "critical sections".  You're not supposed to
spin-wait on a lock within a critical section with interrupts disabled.
That's just dumb practice and it gets you nowhere fast.

Likewise, within the small regions of code where "stupid" pointers are
actually generated and/or manipulated (in my scheme) you should not do
stuff that can cause movement of the pointed-at object(s).

Now just because some yahoo *could* write some code in which he did a
spin-wait on a lock within a critical section with interrups disabled
does NOT mean that critical sections are a bad concept.  It only means
that you must use them carefully in order to use them properly.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.