爲什麼64位平臺上的BSTR長度前綴爲4個字節？

似乎在64位平臺上有一個8字節長度的前綴是合理的。如果我們可以解決超過4Gb的mem，爲什麼不允許使用5Gb字符串？答案僅僅是「通過規範」，還是存在一些我不知道的互操作性/向後兼容性原因？謝謝。爲什麼64位平臺上的BSTR長度前綴爲4個字節？

來源

2014-04-16 Alexander Chertov

BSTR數據類型是標準的COM字符串數據類型。改變長度前綴將使得不可能在不同位數的進程之間安全地移動字符串（或者至少使其顯得更復雜）。由於COM是唯一相關的跨位互操作性基礎結構，因此對於32位進程和64位進程，必須具有相同的行爲方式BSTR。

這是一個折衷，強加了一個2GB的「限制」，以換取不同位數的進程之間的無干擾字符串編組交換。

來源

2014-04-16 14:14:56 IInspectable

謝謝。我沒有意識到你可以通過32位和64位進程之間的BSTR。 –

BSTR如何從32位傳遞到64位處理而不重新分配？ –

@David是否重新分配，BSTR的佈局被記錄。自定義和系統提供的marshalers都依賴於這種文檔化的佈局：指向數據字符串的指針，其長度爲4字節，緊接在內存中的數據之前。考慮一個優化的編組器，用於保持共享內存狀態的對象。如果該內存映射到兩個進程中，則不能針對不同位的「BSTR」使用不同的內存佈局。 – IInspectable

http://msdn.microsoft.com/en-us/library/windows/desktop/ms221069%28v=vs.85%29.aspx

BSTR是一個前綴長度的字符串，所以第一個屬性是是長度，沒有解決

大多數64位編譯實現使用LP64（的Linux/Unix）或LLP64（視窗），所以INT的長度保持32位

另一個原因也許向後兼容性

來源

2014-04-16 04:20:20

我編輯了這個問題。我問的是爲什麼沒有size_t而不是4字節的int。 –

一個很好的理由是用於與平臺API，其接受int LEN兼容性等MultiByteToWideChar gths。還有更多的字符串API可以使用32位長度。

這實際上並不是一個真正的限制，因爲我無法想象長度> 2GB的BSTR將是解決問題的最佳方案。

來源

2014-04-16 06:06:43

爲什麼64位平臺上的BSTR長度前綴爲4個字節？

回答

相關問題