C + + 中临时保证的生存期？

C + + 是否为在函数调用中创建但不作为参数使用的临时变量的生存期提供了保证？下面是一个示例类:

class StringBuffer
{
public:
StringBuffer(std::string & str) : m_str(str)
{
m_buffer.push_back(0);
}
~StringBuffer()
{
m_str = &m_buffer[0];
}
char * Size(int maxlength)
{
m_buffer.resize(maxlength + 1, 0);
return &m_buffer[0];
}
private:
std::string & m_str;
std::vector<char> m_buffer;
};

你可以这样使用它:

// this is from a crusty old API that can't be changed
void GetString(char * str, int maxlength);


std::string mystring;
GetString(StringBuffer(mystring).Size(MAXLEN), MAXLEN);

什么时候调用临时 StringBuffer 对象的析构函数? 是:

  • 在调用 GetString 之前？
  • 在 GetString 返回之后？
  • 依赖编译器？

我知道 C + + 保证一个局部临时变量只要有一个对它的引用就是有效的——当有一个对成员变量的引用时，这是否适用于父对象？

谢谢。

23339 次浏览
小开
最佳答案

The destructor for that sort of temporaries is called at the end of the full-expression. That's the most outer expression which is not part of any other expression. That is in your case after the function returns and the value is evaluated. So, it will work all nice.

It's in fact what makes expression templates work: They can keep hold references to that sort of temporaries in an expression like

e = a + b * c / d

Because every temporary will last until the expression 

x = y

Is evaluated completely. It's quite concisely described in 12.2 Temporary objects in the Standard.

小开

After the call to GetString returns.

小开

StringBuffer is in the scope of GetString. It should get destroyed at the end of GetString's scope (ie when it returns). Also, I don't believe that C++ will guarantees that a variable will exist as long as there is reference.

The following ought to compile:

Object* obj = new Object;
Object& ref = &(*obj);
delete obj;
小开

litb's answer is accurate. The lifetime of the temporary object (also known as an rvalue) is tied to the expression and the destructor for the temporary object is called at the end of the full expression and when the destructor on StringBuffer is called, the destructor on m_buffer will also be called, but not the destructor on m_str since it is a reference.

Note that C++0x changes things just a little bit because it adds rvalue references and move semantics. Essentially by using an rvalue reference parameter (notated with &&) I can 'move' the rvalue into the function (instead of copying it) and the lifetime of the rvalue can be bound to the object it moves into, not the expression. There is a really good blog post from the MSVC team on that walks through this in great detail and I encourage folks to read it.

The pedagogical example for moving rvalue's is temporary strings and I'll show assignment in a constructor. If I have a class MyType that contains a string member variable, it can be initialized with an rvalue in the constructor like so:

class MyType{
const std::string m_name;
public:
MyType(const std::string&& name):m_name(name){};
}

This is nice because when I declare an instance of this class with a temporary object:

void foo(){
MyType instance("hello");
}

what happens is that we avoid copying and destroying the temporary object and "hello" is placed directly inside the owning class instance's member variable. If the object is heavier weight than a 'string' then the extra copy and destructor call can be significant.

小开

I wrote almost exactly the same class:

template <class C>
class _StringBuffer
{
typename std::basic_string<C> &m_str;
typename std::vector<C> m_buffer;


public:
_StringBuffer(std::basic_string<C> &str, size_t nSize)
: m_str(str), m_buffer(nSize + 1) { get()[nSize] = (C)0; }


~_StringBuffer()
{ commit(); }


C *get()
{ return &(m_buffer[0]); }


operator C *()
{ return get(); }


void commit()
{
if (m_buffer.size() != 0)
{
size_t l = std::char_traits<C>::length(get());
m_str.assign(get(), l);
m_buffer.resize(0);
}
}


void abort()
{ m_buffer.resize(0); }
};


template <class C>
inline _StringBuffer<C> StringBuffer(typename std::basic_string<C> &str, size_t nSize)
{ return _StringBuffer<C>(str, nSize); }

Prior to the standard each compiler did it differently. I believe the old Annotated Reference Manual for C++ specified that temporaries should clean up at the end of the scope, so some compilers did that. As late as 2003, I found that behaviour still existed by default on Sun's Forte C++ compiler, so StringBuffer didn't work. But I'd be astonished if any current compiler was still that broken.

小开

From cppreference:

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.


提交答案