Why Do Un-Named C++ Objects Destruct Before the Scope Block Ends

Why do un-named C++ objects destruct before the scope block ends?

A temporary variable lives until the end of the full expression it was created in. Yours ends at the semicolon.

This is in 12.2/3:

Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created.

Your behavior is guaranteed.

There are two conditions that, if met, will extend the lifetime of a temporary. The first is when it's an initializer for an object. The second is when a reference binds to a temporary.

Does C++ destruct object in given compound?

The temporaries live until the end of the full expression, which in your case is marked by the ;. So the code is perfectly safe and the p will be initialized with 5.

See

http://en.cppreference.com/w/cpp/language/lifetime

for more details.

EDIT: your code works, aside from @Remy's comment, read about the Most vexing parse for more details.

Is a C++ destructor guaranteed not to be called until the end of the block?

You are OK with this - it's a very commonly used pattern in C++ programming. From the C++ Standard section 12.4/10, referring to when a destructor is called:

for a constructed object with
automatic storage duration
when the block in which the object is
created exits

How is destroying local variables when a block is exited normally called in C++?

An object is automatically destructed when it "goes out of scope". This could be referred to as "automatic storage reclamation", but that actually refers to garbage collection (there are several papers with that phrase in their name that use the term to mean garbage collection). When it is used to ensure proper pairing of open/close, lock/unlock, or other forms of resource acquisition with their appropriate release, then it is known as the design pattern of Resource Acquisition is Initialization (RAII), which is somewhat ironic given that the main aspect of RAII is not the resource initialization or acquisition, but rather its destruction.

Does C++ destruct object in given compound?

The temporaries live until the end of the full expression, which in your case is marked by the ;. So the code is perfectly safe and the p will be initialized with 5.

See

http://en.cppreference.com/w/cpp/language/lifetime

for more details.

EDIT: your code works, aside from @Remy's comment, read about the Most vexing parse for more details.

Trying to keep an anonymous variable alive in C++

In your class:

Node(char d)
{
   data = &d;
}

char d is a parameter to constructor Node. The problem is that d lives only in local scope on the program stack. It ceases to exist when the code returns from constructor.
data now has an address pointing somewhere in the program stack. If you try to read the data, you could read some other thing that was pushed on the stack later. If you write to this address you'll overwrite some other variables in your program. It could crash or just do something unexpected.

Local variable scope question

You quoted standard correctly. Let me emphasize:

A name declared in a block is local to that block. Its potential scope begins at its point of declaration and ends at the end of its declarative region.

You didn't declare any name, actually. Your line

MyClass (12345);

does not even contain a declaration! What it contains is an expression that creates an instance of MyClass, computes the expression (however, in this particular case there's nothing to compute), and casts its result to void, and destroys the objects created there.

A less confusing thing would sound like

call_a_function(MyClass(12345));

You saw it many times and know how it works, don't you?

in C++ which happens first, the copy of a return object or local object's destructors?

For previous standards (here I will use C++ 03), the closest the standard comes to declaring the sequence of operations in a return is from 6.6

6.6 Jump statements

2. On exit from a scope (however accomplished), destructors (12.4) are called for all constructed objects with automatic storage duration (3.7.2) (named objects or temporaries) that are declared in that scope, in the
   reverse order of their declaration. Transfer out of a loop, out of a block, or back past an initialized variable with automatic storage duration involves the destruction of variables with automatic storage duration that are in scope at the point transferred from...

The return statement must complete in order to exit the [function] scope, implying that the copy-initialization must also complete. This order is not explicit. Various other quotes from 3.7.2 and 12.8 concisely state the same as above without providing explicit order. Working revisions (after Nov. 2014) include the quote below to address that. The defect report clarifies the change.

From the current working draft (N4527) of the standard as seen on the date of this question

6.6.3 The Return Statement

3. The copy-initialization of the returned entity is sequenced before the destruction of temporaries at the end
   of the full-expression established by the operand of the return statement, which, in turn, is sequenced before
   the destruction of local variables (6.6) of the block enclosing the return statement.

Notice that this quote refers directly to 6.6. So I think it is safe to assume that the Mutex object will always be destroyed after the return expression has copy-initialized the return value.

---

Related Topics