移植 - 共享內存的X32＆x64的處理

一個32位主機的Windows應用程序的設置共享存儲器（使用存儲器映射的文件/的CreateFileMapping（）API），然後其他32位客戶端進程使用該共享存儲器互相通信。移植 - 共享內存的X32＆x64的處理

我打算將主機應用程序移植到64位平臺，一旦準備就緒，我打算32位和64位客戶機進程應該能夠使用由主要64位主機應用程序設置的共享內存。

主機X32應用程序編寫的原代碼使用「的size_t」幾乎無處不在，因爲這4個字節到8個字節不同，因爲我們從32倍到x64動，我找取代它。

我打算用「unsigned long long」替換「size_t」，以便它的大小在32位的位上是相同的64位。

你能否給我建議更好的替代方案？此外，使用「無符號long long」會對x32應用程序的性能產生影響。我猜是的？

研究完成 - 實測值非常有用的製品 - 一個）20在發出從移植32位到64位（www.viva64.com） b）否方式限制在x64 /改變「的size_t」平臺使用編譯器標誌或任何鉤/騙子因爲它的typedef

2012-09-23 dpb

它沒有任何意義。一個32位的進程被限制爲映射不超過4千兆字節到其地址空間。適合size_t沒有問題。 –

@HansPassant：如果我理解正確，他希望對32位和64位版本使用相同的代碼，並且它們必須是二進制兼容的，因此他不能使用任何不同的類型定義在兩個平臺上。 –

使用64比特變量的將通常的32位應用程序慢下來的4個字節。

不過：因爲它通常是不可能在所有的流程相同的虛擬地址來定位的共享內存，你可能使用相對於共享內存塊的開始地址;另外，由於您的應用程序將支持32位進程，因此共享內存塊的大小可能會小於4GB。那麼爲什麼不使用unsigned int？

無論您選擇哪種類型，這將是明智的使用typedef給它一個有意義的名字，例如，shared_memory_address，並一直使用該名稱。如果需要，您可以稍後更改基礎類型。

2012-09-23 22:39:20

回答