各位前輩日安，
想請教各位前輩，在QMH的Quene內為什麼需要放一個varient?
小的查了資料後得知，通常是在producer迴圈中，發生事件後將「訊息」放入variant，
然後傳遞給consumer用varient to Data 「翻譯」出訊息，
不同資料型態的「訊息」都能放入variant，再依據各種資料型態，讓variant to Data「翻譯」出來，
替前面的data type cluster中省下不少空間，或是其他用意?
相對的，我可以因為有variant，所以有很多東西都可以「借用空間」，省下一堆constant的宣告?
對呀, 在物件導向也會用到這個概念,
用了variant整體程式的彈性會高很多
謝H大的回饋
後來我玩了一下variant，
發現他挺像一個空盒子，基本上想放什麼就放什麼，
沒有累積性，直接取代掉。只是「翻譯」回去原資料型態就得注意翻譯的對不對~
所以…使用這種架構時，也得注意事件排序，避免把過去的資料蓋掉?
我是覺得應該不會出現覆蓋資料的問題哈, 因為每次deQ出來都是一個獨立的物件, 你根據message就很明確定義data資料類型了, 所以既不會解錯, 也不會有覆蓋的問題(如果真的有覆蓋, 那連同message都會被蓋掉, 您說是吧XD)
完全同意H大唷，
應該說我一開始沒很適應這種寫法，
過去習慣先宣告給Queue資料型態，提前構想哪種資料能用，
但是Variant出現後，直接換成「啥資料我都吃，不用類別，丟給我我幫你傳遞」
直覺上資料全彙整成一條，
不過依照Quene的FIFO特性，覆蓋的問題就不存在了~
你的問題你自己回答了
variant 提供你一個通用的介面管道
當今天傳送的資料結構發生變化的時候你只要留意發送端接收端的編解譯而無需為資料線結構變更來大幅更動程式
通當會配合自定control 以 Strict Type Definitions 強制定義發送端接收端的資料型別結構組成
感謝貓大!!!
這說明更好吸收與理解了~