国产亚洲精品一区二区,久久―日本道色综合久久,亚洲欧美久久

STL容器的賦值運算符可以更靈活嗎?

STL容器的賦值運算符可以更靈活嗎?

（轉載請注明來源于金慶的專欄）

STL容器如果元素類型不同是不能相互賦值的,
即使元素類型是兼容的.

如兩個list, 一個存放基類B指針, 一個存放派生類D指針:

class B {};
class D : public B {};

    std::list<B*> lB;
    std::list<D*> lD;
    lB = lD; // ERROR!

編譯報錯
error: no match for 'operator=' in 'lB = lD'|
list.tcc|121|note: candidates are:
    std::list<_Tp, _Alloc>& std::list<_Tp, _Alloc>::operator=(
        const std::list<_Tp, _Alloc>&)
    [with _Tp = B*, _Alloc = std::allocator<B*>]|

而boost::shared_ptr<B>與boost::shared_ptr<D>之間卻可以仍然保持兼容性.
以下賦值與指針賦值一樣是正確的.
    boost::shared_ptr<B> pB;
    boost::shared_ptr<D> pD;
    pB = pD;

因為STL容器與boost::shared_ptr的賦值運算符定義方式不一樣.
boost::shared_ptr賦值運算符中參數(shù)的模板參數(shù)與類的模板參數(shù)不同,
所以支持更靈活的賦值.

boost::shared_ptr<T>& boost::shared_ptr<T>::operator=(
    const boost::shared_ptr<Y>&)

只要改寫STL容器的賦值運算符的參數(shù), 同樣可以擴大靈活性.

例如將
    list<_Tp,_Alloc>&
    list<_Tp,_Alloc>::
    operator=(const list& __x)
改為:
    list<_Tp,_Alloc>&
    list<_Tp,_Alloc>::
    operator=(const list<_Tp2, _Alloc2> & __x)

不知為什么STL沒有放開這種靈活性?

posted on 2008-11-12 12:17 金慶閱讀(2556) 評論(6) 編輯收藏引用所屬分類: 1. C/C++

LZ 可能是python用爽了吧
C++的特點:
強類型(其實也是基于指針(內存訪問格式))
說到底也就是為了效率;
當然"虛表"之類的東西避開了這個問題, 也導致了被不少人忌憚的"詬病".

從這方面考慮
我想如果 STL實現(xiàn)了
>>
std::list<B*> lB;
std::list<D*> lD;
lB = lD;
勢必犯下大不韙的錯誤
結論: STL不是一種為了滿足小范圍需求的庫

最后, 我想如果是在開發(fā)網游中遇上了此等問題:
尋找或者開發(fā)一種適合網游開發(fā)的"STL", 很有必要;

回復更多評論

# re: STL容器的賦值運算符可以更靈活嗎? 2009-10-12 14:13 金慶

@yisa
@踏雪赤兔
既然可以這樣賦值: lB.assign(lD.begin(), lD.end());
也應該支持等號運算符賦值: lB = lD;

既然支持元素的隱式類型轉換, 也應該支持容器的隱式類型轉換. 回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發(fā)表評論。


相關文章: How are dtLinks created in NavMesh C++ parameter passing rules Naming Conventions for Accessors Visual Studio 2019 Compiler Hangs Fbx File Format Identifier 查找內存錯誤 std::thread 中的異常會丟失調用棧用賦值代替 protobuf CopyFrom() vs2017 linux 編譯輸出改成 vs 格式為 LiteIDE 添加選中標記

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

金慶的專欄

公告

留言簿(12)

隨筆分類(502)

隨筆檔案(423)

相冊

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜

評論