temporary variables storage duration type?

I

Ivan Novick

Is the string below automatic storage duration?

#include <iostream>
#include <string>
int main(int argc, char** argv)
{
std::cout << std::string().size() << std::endl;
return 0;
}

Thanks,
 
A

Alf P. Steinbach

* Ivan Novick:
Is the string below automatic storage duration?

#include <iostream>
#include <string>
int main(int argc, char** argv)
{
std::cout << std::string().size() << std::endl;
return 0;
}

Yes, but it may internally use dynamic memory allocation.
 
I

Ivan Novick

Alf said:
* Ivan Novick:

Yes, but it may internally use dynamic memory allocation.
Hmmm... What does that mean?

-- When does the destructor get called? At the end of the statement?
When the expression goes out of scope?

-- Is the memory for this string on the heap or the stack?

Thank you,
 
A

Alf P. Steinbach

* Ivan Novick:
Hmmm... What does that mean?

-- When does the destructor get called? At the end of the statement?
When the expression goes out of scope?

An object with automatic storage duration is at the latest destroyed at
the end of the block it's created in.

A temporary object persists at least until the end of the
full-expression it occurs in.

That is, if I recall correctly -- you shouldn't try to take advantage
of any particular destruction point, so it's mostly irrelevant when that
occurs. If you need the object to persist until the end block, then
declare it as a variable or bind it to a reference to const. And in
general, when you need control, take control.

-- Is the memory for this string on the heap or the stack?

Automatic storage duration is technically a stack, in the sense that the
storage lifetimes are (required to be) nested in LIFO order.

In that sense the object "is on the stack", but beware that C++
compilers have existed where that stack was not implemented as the usual
moving stack pointer now in fashion: the C++ standard requires a
logical stack for a fully conforming implementation, but not necessarily
a hardware stack pointer or a contiguous memory area designated as stack.

Whether the object internally makes use of dynamic memory allocation
(the "heap") or not, is not specified by the standard. It is a quality
of implementation issue. If you're concerned about efficiency for
creating an empty string or vector, then measure, Measure, MEASURE.
 
D

Dizzy

Alf said:
* Ivan Novick:

An object with automatic storage duration is at the latest destroyed at
the end of the block it's created in.

A temporary object persists at least until the end of the
full-expression it occurs in.

With the exception that a temporary to which a reference (to const) is bound
will exist as long as the reference exists (of course the reference itself
has to be in the same exact scope as the code creating the temporary).

Thus:
MyClass const& ref = getMyClassInstance();
// where getMyClassInstance() returns by value, ie a temporary

The compiler will make sure that the temporary exists as long as ref exists.
 
A

Alf P. Steinbach

* Dizzy:
With the exception that a temporary to which a reference (to const) is bound
will exist as long as the reference exists (of course the reference itself
has to be in the same exact scope as the code creating the temporary).

Thus:
MyClass const& ref = getMyClassInstance();
// where getMyClassInstance() returns by value, ie a temporary

The compiler will make sure that the temporary exists as long as ref exists.

I think that was summarized in the immediately following part of my
posting that you elided,

<q>
That is, if I recall correctly -- you shouldn't try to take advantage
of any particular destruction point, so it's mostly irrelevant when that
occurs. If you need the object to persist until the end block, then
declare it as a variable or bind it to a reference to const.
</q>

Probably you didn't see that.

For just about any C++ subject one would care to pick, any explanation
in a Usenet posting will always fall short of being correct when
compared to the standard's full treatment, except if it quotes in full
all that's relevant from the standard (which may be all of it). In this
case the detail you noted was actually not left out, but covered in the
posting. But there are more such details, there always is, e.g.

- For full accuracy the above simplified explanation has to make an
exception for binding the temporary via a return statement (not a
good idea).

- For another example, a class type object ceases to exist (as an
object, not as a region of memory) if you explicitly call the
destructor (not a good idea).

- And for a third example, take the situation where you bind the
temporary to a reference to const member (not a good idea!), like
T(int const& x = 666): m(x){} where x may refer to a temporary.

Cheers,

- Alf
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top