2012-09-23 4 views
1

32 비트 호스트 Windows 응용 프로그램 설정 공유 메모리 (메모리 매핑 파일/CreateFileMapping() API 사용) 및 다른 32 비트 클라이언트 프로세스는이 공유 메모리를 사용하여 서로 통신합니다.포팅 - 공유 메모리 x32 및 x64 프로세스

호스트 응용 프로그램을 64 비트 플랫폼으로 이식 할 준비가 완료되면 32 비트 및 64 비트 클라이언트 프로세스 모두가 기본 64 비트 호스트 응용 프로그램의 공유 메모리 설정을 사용할 수 있어야합니다.

호스트 x32 응용 프로그램 용으로 작성된 원본 코드는 "size_t"를 거의 모든 곳에서 사용합니다. 이는 x32에서 x64로 이동함에 따라 4 바이트와 8 바이트가 다르기 때문에 대체하려고합니다.

"size_t"를 "unsigned long long"으로 바꾸려고하므로 크기가 32 비트 & 64 비트에서 동일합니다.

제게 더 나은 대안을 제안 해 주시겠습니까? 또한, "부호없는 long long"의 사용은 x32 app에 성능에 영향을 미칩니다. 그렇습니다.


연구 완료 - 찾을 매우 유용한 기사 - 가) 20 문제를 32 비트 64 비트 (www.viva64.com) b)는 64에/변경 "를 size_t"를 제한 할 수있는 방법에 포팅 플랫폼은 typedef이기 때문에 컴파일러 플래그 또는 후크/사기를 사용하여 4 바이트로 변환합니다.

+0

아무 의미가 없습니다. 32 비트 프로세스는 주소 공간에 4 기가 바이트를 넘지 않는 매핑으로 제한됩니다. size_t를 문제없이 맞 춥니 다. –

+0

@HansPassant : 올바르게 이해하면 32 비트 및 64 비트 릴리스에 대해 동일한 코드를 사용하려고하며 바이너리 호환이 가능해야하므로 동일하지 않은 유형 정의를 사용할 수 없습니다 두 플랫폼에서. –

답변

3

일반적으로 64 비트 변수를 사용하면 32 비트 응용 프로그램의 속도가 느려집니다.

그러나 일반적으로 모든 프로세스에서 동일한 가상 주소에서 공유 메모리를 찾을 수 없기 때문에 아마도 공유 메모리 블록의 시작 부분에 상대적인 주소를 사용하고있을 것입니다. 또한 응용 프로그램이 32 비트 프로세스를 지원할 것이므로 공유 메모리 블록은 아마도 4GB보다 작을 것입니다. 왜 unsigned int를 사용하지 않습니까?

어떤 유형을 선택하든 typedef를 사용하여 의미있는 이름 (예 : shared_memory_address)을 사용하고 일관되게 그 이름을 사용하는 것이 좋습니다. 그렇게하면 필요할 때 기본 유형을 나중에 변경할 수 있습니다.

관련 문제