Lifetime of objects created inside function calls

Question

Object lifetime is usually tied to scope but when an object is created inside a function call things become a bit blurrier (at least to me). Check the code below:

#include <iostream>
#include <string>

using namespace std;

struct ins
{
    ins() : _num(++num) { cout << "ctor " << _num << endl; }
    ~ins() { cout << "dtor " << _num << endl; }
    int get() { return _num; }
    static int num;
    int _num;
};

int ins::num = 0;
ins geti() { return {}; }
void usei(int i) { cout << "using " << i << endl; }

int main()
{
    usei(geti().get());
    cout << endl;
    usei(geti().get());
}

Output

ctor 1

using 1

dtor 1

ctor 2

using 2

dtor 2

Demo

Long story short, I want to know if there's a way to "calculate" the lifetime of objects in such cases. How would I know to what function each object is tied to? my current mental model of what's going on does not help me much.

You don't say what you expect. So it difficult to help you with what is happening. — Richard Critten, Apr 12 '18 at 16:32
The lifetime depends on the scope. The problem I see you running into is you are using pointers to temporary objects. `get_string1().c_str()` gives you a pointer to the returned string data and that returned string that will go out of scope at the end of the expression. If `f` is holding onto it then you are going to have a dangling pointer. I think you might be better served giving us a [mcve] of the actual problem and we can explain why it falls apart. — NathanOliver, Apr 12 '18 at 16:34
@NathanOliver Edited, my Q does not have to do with the bug so lets set aside the MCV. I just want to know what the language (the standard) has to say about lifetime in such cases. (the bug is fixed, at least according to valngrind, address sanitizer and the testing team, thank you for your concern) — Lorah Attkins, Apr 12 '18 at 16:40
What case exactly are you talking about? The lifetime of a non static local object ends at the end of its scope. The lifetime of a returned object ends and the end of the full expression. That's pretty much all there is to it (unless you extend its life with a `const &`) — NathanOliver, Apr 12 '18 at 16:43
Possible duplicate of [Lifetime of temporaries](https://stackoverflow.com/questions/4214153/lifetime-of-temporaries) — , Apr 12 '18 at 16:43

score 1 · Accepted Answer · answered Apr 12 '18 at 16:46

After digging into cppreference, I found a section on object lifetime. Apparently my mental model on this was wrong.

Lifetime does not bind to functions in this case, but to expressions. My case pertains to temporary object lifetime, which is created by

returning a prvalue from a function

In that case the following rule applies:

All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created, and if multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.

Lifetime of objects created inside function calls

1 Answers1