多年來,將功能集成到標準庫中的過程變得明顯。是否有任何標準擦除型容器的計劃?
看來雖然,一個有用&實用提升的一部分,這是容器提供類型擦除,逃脫了這個過程。
是否有任何特殊原因(性能損失,缺乏魯棒性)?
是否有任何建議與將這些功能(如
boost::any
)納入下一個標準庫有關?shared_pointer
使用類型擦除,在今天的標準庫有什麼其他的設施,我們可以利用這種技術?
多年來,將功能集成到標準庫中的過程變得明顯。是否有任何標準擦除型容器的計劃?
看來雖然,一個有用&實用提升的一部分,這是容器提供類型擦除,逃脫了這個過程。
是否有任何特殊原因(性能損失,缺乏魯棒性)?
是否有任何建議與將這些功能(如boost::any
)納入下一個標準庫有關?
shared_pointer
使用類型擦除,在今天的標準庫有什麼其他的設施,我們可以利用這種技術?
類型擦除通常引入了一個額外的間接和降低性能,最終虛函數調用。
最近剛剛更新的工作草案「C++擴展庫的基礎知識」,其中提出了(其他功能)boost::any
for the standard。
std::function
將是另一個例子。
There也提出了一些建議,允許'struct'被用作類型擦除模板:然而,強大的反射可能會讓我們在庫中執行此操作(foreach中的標記方法,寫入類型擦除代碼)。大概不反射1.0;) – Yakk
@Yakk你會介意你在這裏談論的建議嗎?謝謝。 –
@GuillaumeRacicot哦,上帝,那是3年前。我不知道我現在在哪裏看到它。抱歉。如果我想從現在開始的7到10年內考慮這樣做,我希望反思提案能夠進入,並且提出有關元類的提議;那麼可以編寫名稱type_erasure的元類來生成所需的代碼mayhap; 'type_erasure bob {int foo; void print(std :: ostream&)const; }'。這比我在上面的評論中描述的要乾淨得多。 – Yakk
Boost.Any將其作爲std::any
與C++ 17做了一些區別。連同其他有用的類型構造函數:std::optional
和std::variant
。
「**將** **提升** ** ** ** ** ** ** ** ** ** ** ** ** ** - 」這是提升原因造成的原因 – sp2danny