我正在用C++設計自己的消息總線,它將作爲基於組件的遊戲的後端。消息總線將具有以下特徵:消息總線的最佳容器
- 經常迭代,從第一個元素開始到最後一個結束。
- 在隨機位置不常取下元件的
- 元件的理論上無限數量
- 消息類型的理論上無限數量
- 需要運行儘可能快
- 所有元素將包含一個指針,指向該消息的處理程序
- 線程安全
我的問題是:
什麼是最好的容器來存儲這些信息?這不僅限於標準C++,因此只要容器在Windows和Linux之間跨平臺,boost容器就可以使用。
我正在用C++設計自己的消息總線,它將作爲基於組件的遊戲的後端。消息總線將具有以下特徵:消息總線的最佳容器
我的問題是:
什麼是最好的容器來存儲這些信息?這不僅限於標準C++,因此只要容器在Windows和Linux之間跨平臺,boost容器就可以使用。
消息總線是一件複雜的事情,並不能簡單歸結爲連接到總線的單個組件的消息隊列的表示。
正如在評論中提到的,std::queue<MessageType,std::list<MessageType> >
應該滿足除線程安全性以外的主要用例,但是還有很多事情需要考慮。
這是樣本線程安全隊列實現:EventQueue.h從STTCL。如果您將std::queue<__T__,std::list<__T__> >
作爲STTCL_DEFAULT_DEQUEIMPL(__T__)
的值,那麼它應該符合您的需求,包括對特定項目的find()
操作。
根據您的應用程序的使用情況,您需要從各種消息傳遞模式中進行選擇以分發和訂閱特定類型的消息。
當我正要處理這些話題時,我發現EAI catalog of messaging patterns非常有用。
除此之外:始終(ALWAYS !!!是三驚歎號!)出發從傳輸消息的有效載荷!
消息模式的着名傳輸系統是0MQ,它提供了各種語言的綁定。但其他人可用於C++實現(包括基於原始套接字的實現或s.th.,如boost::asio
)。對於消息有效載荷的設計,我發現Google Protocol Buffers對我在分佈式系統(包括嵌入式!)中的所有需求最有用,便攜和靈活。
有些這似乎超出了我,我有很多的閱讀要做!非常感謝你 :) – OMGtechy
線程安全的東西,這是肯定的。 –
在隨機位置不頻繁地去除元素 - 這是否意味着隨機,但是剛剛被搜索或隨機搜索,如數組索引隨機? – Sarien
@sarien一個對象可能會在任何給定的時間取消訂閱特定的消息。 – OMGtechy