定义向量元素的销毁顺序是否合理？

Question

我知道向量元素破坏顺序没有用C++定义的标准（见Order of destruction of elements of an std::vector），我看到了，我检查了所有的编译器做到这一点的破坏，从开始到结束 - 这是相当令人惊讶的我，因为动态和静态数组做反向顺序，而这种相反的顺序在C++世界中经常出现。

要严格：我知道“集装箱会员...可以构造和使用，例如以任意顺序插入销毁和擦除成员函数”，我不选“容器保持某种日志在这些变化”。我只是投票改变当前矢量析构函数的实现，从向前销毁到向后销毁元素 - 仅此而已。也许可以将此规则添加到C++标准中。

其原因为什么？从阵列到矢量的转换将更安全。

现实世界的例子： 我们都知道，互斥锁定和解锁顺序是非常重要的。并确保解锁发生 - 使用ScopeGuard模式。那么销毁顺序很重要。考虑这个例子。有 - 从数组向量原因僵局开关 - 只是因为他们的破坏顺序不同：

class mutex { 
public: 
    void lock() { cout << (void*)this << "->lock()\n"; } 
    void unlock() { cout << (void*)this << "->unlock()\n"; } 
}; 

class lock { 
    lock(const mutex&); 
public: 
    lock(mutex& m) : m_(&m) { m_->lock(); } 
    lock(lock&& o) { m_ = o.m_; o.m_ = 0; } 
    lock& operator = (lock&& o) { 
     if (&o != this) { 
      m_ = o.m_; o.m_ = 0; 
     } 
     return *this; 
    } 
    ~lock() { if (m_) m_->unlock(); } 
private: 
    mutex* m_; 
}; 

mutex m1, m2, m3, m4, m5, m6; 

void f1() { 
    cout << "f1() begin!\n"; 
    lock ll[] = { m1, m2, m3, m4, m5 }; 
    cout <<; "f1() end!\n"; 
} 

void f2() { 
    cout << "f2() begin!\n"; 
    vector<lock> ll; 
    ll.reserve(6); // note memory is reserved - no re-assigned expected!! 
    ll.push_back(m1); 
    ll.push_back(m2); 
    ll.push_back(m3); 
    ll.push_back(m4); 
    ll.push_back(m5); 
    cout << "f2() end!\n"; 
} 

int main() { 
    f1(); 
    f2(); 
} 

输出 - 看到从破坏秩序的变化F1（）到F2（）

f1() begin! 
0x804a854->lock() 
0x804a855->lock() 
0x804a856->lock() 
0x804a857->lock() 
0x804a858->lock() 
f1() end! 
0x804a858->unlock() 
0x804a857->unlock() 
0x804a856->unlock() 
0x804a855->unlock() 
0x804a854->unlock() 
f2() begin! 
0x804a854->lock() 
0x804a855->lock() 
0x804a856->lock() 
0x804a857->lock() 
0x804a858->lock() 
f2() end! 
0x804a854->unlock() 
0x804a855->unlock() 
0x804a856->unlock() 
0x804a857->unlock() 
0x804a858->unlock() 

Answer 1

我认为这是另一种C++为编译器编写者提供了为他们的架构编写最高性能容器的灵活性。以特定的顺序销毁可能会损害性能，例如在0.001％的情况下（我实际上从未见过默认顺序不适合的另一个示例）。在这种情况下，因为vector是连续的数据，所以我指的是硬件能够智能地利用预读缓存，而不是向后迭代并可能重复丢失缓存。

如果需要对您的容器实例破坏的特定顺序，语言要求你自己实现以避免潜在的惩罚的标准功能，其他客户端。

Answer 2

FWIW，libc++输出：

f1() begin! 
0x1063e1168->lock() 
0x1063e1169->lock() 
0x1063e116a->lock() 
0x1063e116b->lock() 
0x1063e116c->lock() 
f1() end! 
0x1063e116c->unlock() 
0x1063e116b->unlock() 
0x1063e116a->unlock() 
0x1063e1169->unlock() 
0x1063e1168->unlock() 
f2() begin! 
0x1063e1168->lock() 
0x1063e1169->lock() 
0x1063e116a->lock() 
0x1063e116b->lock() 
0x1063e116c->lock() 
f2() end! 
0x1063e116c->unlock() 
0x1063e116b->unlock() 
0x1063e116a->unlock() 
0x1063e1169->unlock() 
0x1063e1168->unlock() 

有人故意实施这样。定义here的主要功能是：

template <class _Tp, class _Allocator> 
_LIBCPP_INLINE_VISIBILITY inline 
void 
__vector_base<_Tp, _Allocator>::__destruct_at_end(const_pointer __new_last, false_type) _NOEXCEPT 
{ 
    while (__new_last != __end_) 
     __alloc_traits::destroy(__alloc(), const_cast<pointer>(--__end_)); 
} 

这家私人实现细节被称为每当size()需要收缩。

我还没有收到有关此可见的实现细节的任何反馈，无论是正面还是负面的。