Question

Names have scope (a compile-time property), while objects have lifetimes (a runtime property). Right?

I often see people talking about temporary objects "going out of scope". But since a temporary object does not have a name, I think it does not make sense to talk about "scope" in this context. The lifetime of a temporary object is very clearly defined and has nothing to do with scope. Would you agree?

Was it helpful?

Solution

Names have scope (a compile-time property),

Yes. I would not call it a property thought. But basically yes.

while objects have lifetimes (a runtime property). Right?

There are three types of variables. Each type has different properties in relation to lifetimes.

  • Automatic storage duration:
  • Static storage duration
  • Dynamic storage duration

Note: automatic storage duration objects have a lifetime that is bound to the scope of the variable.

I often see people talking about temporary objects "going out of scope".

Unless bound to a variable a temporary is destroyed at the end of an expression. If they are bound to a variable (a const reference) then they have the same lifespan as the variable. Sometimes it is just easier to refer to this as the scope, but technically you are correct.

But since a temporary object does not have a name, I think it does not make sense to talk about "scope" in this context.

Technically yes. But I think it just makes talking about it easier. To me (though not technically correct) the scope of a temporary (not bound) is the expression. Its easier to say than the lifespan of the temporary variable.

The lifetime of a temporary object is very clearly defined and has nothing to do with scope. Would you agree?

Yes. But it still feels more natural to talk about scope (even if it is not technically correct). As most people understand what you are trying to imply. But when you get down and talk about the very technical stuff you should use the correct terminology and scope in this context is not correct.

OTHER TIPS

The lifetime of temporaries has very little to do with syntactical blocks, but "scope" — as a word rather than a technical term — can be used in other ways. The important question is whether you are confused when people use "scope" to refer to temporaries. (It doesn't appear that you are, from my POV.)

Since you're talking about using the term to communicate with others, that communication is what's really important. If you were defining terms by writing a standardese document or trying to interpret such a document in the context of defined terms, the situation would be different. Interpreting ISO 14882 will, of course, involve communicating with others, so you would just have to ask for clarification if necessary, in that case.

It's counter-productive to make all non-standardese communication be standardese, and it's often better to use code in either case when high precision is required. The C++ standard extensively uses examples for this reason.

For another example, "calling a constructor" is often used, yet technically you can't call a ctor directly; instead, ctors are part of object initialization. This is why there's an explicit form of new solely to construct an object. (Interestingly, you can call a destructor directly.) However, I would expect that phrase to be understood in most contexts, though I wouldn't advocate using it in standardese contexts.

I've seen people say that "an object went out of scope" when it meant (in your parlance) "the lifetime of the object ended when the object's name went out of scope". If you use that short form, it's natural to say that temporay objects go out of scope, too.

Temporary objects do have names, albeit referable by the compiler only. Otherwise how would the compiler refer to them? Just because you can't refer to a temporary once it's instantiated doesn't mean the compiler can't refer to it.

f(Foo(), Bar());

The compiler has to refer to at least one of the temporaries even though you as a programmer can't refer to either of them. Temporary objects do have a scope.

Binding to a const reference extends the lifetime of a temporary to the lifetime of the reference, so in a sense, it does have something to do with scope in this particular case :

std::string foo();

int main()
{
    // Lifetime of the temporary returned by foo is indeed the scope of bar
    const std::string &bar = foo();
}

See this article from Herb Sutter :

Normally, a temporary object lasts only until the end of the full expression in which it appears. However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself, and thus avoids what would otherwise be a common dangling-reference error.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top