定義向量元素的銷燬順序是否合理？

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()需要收縮。

我還沒有收到有關此可見的實現細節的任何反饋，無論是正面還是負面的。