Re: Terminology problem

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 06/07/04 

Date: Mon, 7 Jun 2004 09:27:42 -0400 (EDT)

On Mon, 7 Jun 2004, David White wrote:
>
> "Gary Labowitz" <glabowitz@comcast.net> wrote...
> >
> > int &rVal = val;
> > decalres a new name for the variable val. It is rVal.
> > You may now use rVal and val interchangeably.
> > rVal is called a reference to val. It exists as long as val exists;
> > that is, they share the same scope.
>
> They don't necessarily share the same scope. A reference can be born after,
> and die before, the object to which it refers, or it can refer to an object
> that no longer exists. Obviously, you can't allow the latter case to ever
> happen.

  Right. As Francis says, the correct term for "exists as long as
val exists" is *lifetime*. rVal and val, being the same object, have
the same lifetime. rVal and val, being different names, may or may
not have different scope.

  Examples, just for fun:

    void foo(const int &v) { int &rVal = v; }
    int main() { int val; foo(val); return 0; }

Here, the scopes of 'rVal' and 'val' do not overlap at all (when
the name 'rVal' is in scope, 'val' is out of scope, and vice versa).
Yet all three names --- 'val', 'v', and 'rVal' --- refer to the
same object.

    int main() {
        int *p = new int(42);
        int &rVal = *p;
        delete p;
        rVal;
        return 0;
    }

Here, the scopes of 'p' and 'rVal' are almost the same ('rVal' is
created just a little later). But the lifetime of the object pointed
to by 'p' is shorter than the "lifetime" of 'rVal', because it gets
explicitly destroyed while the name 'rVal' is still in scope. I
don't think that immediately causes undefined behavior, but the
next line --- the one that evaluates the "value" of the no-longer-extant
'rVal' --- is definitely incorrect, and will cause undefined behavior.
In fact, since a reference is just another name for an existing object,
once *p has been destroyed, there is no way to "re-attach" 'rVal' to
another object. The reference is just dead at this point, and can no
longer be used for anything (except as an argument to 'sizeof').

-Arthur

Relevant Pages

  • Re: Newbie Q: Declare variable IN the loop or BEFORE the loop?
    ... when in fact it's the other local variables that they (via the ... anonymous delegates) reference that are of concern. ... and "expensive" are tied in lifetime by their being in the same scope, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: lectures about "programming methodology"
    ... A lifetime is a period of time during the execution ... So let us assume that software engineering requires coding. ... I can't conceive of a competent developer not understanding scope ... Software Engineering covers the whole process of getting from a statement of requirements written in natural language or more accurately the natural language of the problem domain to a working, ...
    (comp.lang.java.programmer)
  • Re: Lock-free reference counting
    ... The scope of t is the entire function foo, ... The reference's lifetime is considerably shorter than ... The only way for it to collect it is if no reference is ... Bindings are introduced by various language constructs. ...
    (comp.programming)
  • Re: C scope and struct definitions
    ... Are you conflating scope and lifetime? ... I was going to say that the exception would be that a lifetime can't extend ... Scope is the boundary of a variable's existence at compile time. ... static locals break that nice symmetry between compile time and runtime, ...
    (comp.lang.c)
  • Re: Lock-free reference counting
    ... If you mean that he's very confused about the difference between scope ... they destroy objects immediately their lifetime ends, ... variable binding whereas tracing collectors don't do this. ... tracing collectors can reclaim dead space on the stack whereas ...
    (comp.programming)