3
두 개의 타사 라이브러리를 사용하는 프로젝트가 있습니다. 두 프로젝트 모두 헤더 파일에 TCHAR을 사용합니다. 불행히도 한 라이브러리는 멀티 바이트 (라이브러리 a라고 부름)로 컴파일되고 다른 라이브러리는 유니 코드 (라이브러리 b라고 부름)로 컴파일됩니다.다른 문자 집합을 사용하는 라이브러리의 헤더 파일에서 TCHAR 처리
이제는 TCHAR이 빌드 옵션에 따라 wchar 또는 char이있는 사전 컴파일러로 대체된다는 것을 이해합니다. 따라서 라이브러리 a가 컴파일 될 때 TCHAR 유형의 매개 변수를 사용하는 모든 메소드는 char 유형의 매개 변수를 예상하도록 설정되고 라이브러리 b의 메소드는 wchar 유형의 매개 변수를 예상하도록 설정됩니다.
불행히도 내 소비 응용 프로그램도 문자 집합을 선택해야합니다. 유니 코드를 선택하면 라이브러리 a에 포함 된 헤더 파일에 메서드에 wchar이 필요하다는 메시지가 표시됩니다. 헤더에서 TCHAR을 컴파일 할 때 wchars로 해석되기 때문입니다. 여기에는 구조물 내부에 정의 된 TCHARS가 포함됩니다. 실제로이 동작을 확인했습니다. TCHAR 버퍼를 할당하고 전달할 때 멀티 바이트 데이터로 wchar 버퍼를 채우므로 가비지를 다시 가져옵니다.
내 질문은 : 같은 응용 프로그램에서 이러한 라이브러리를 모두 사용할 수있는 깨끗한 방법이 있습니까? 내가이 라이브러리를 어떻게 사용하고 있는지에 대해 뭔가 잘못된 생각을하고 있습니까?
답장을 보내 주셔서 감사합니다. 나는 그것이 기울고있는 방향입니다. 나는 사지에 가서 무엇이 바보 같은 질문 일지 물어볼 것입니다. 래퍼를 사용하는 것보다 라이브러리의 헤더 파일을 편집하는 것보다 구조와 내보내기 된 함수의 컴파일 된 정의와 일치하는 이점은 무엇입니까? 나는 이것이 TCHARs의 수색과 교체를하는 것만 큼 쉽다는 것을 상상하고 있습니다. 나는 그것을 단순화하고 있는가? – MichaC
xtofl은 아래 장점 중 하나를 지적합니다. 래퍼에서 멀티 바이트로 변환하거나 멀티 바이트에서 변환 할 수 있습니다. find/replace가 작동하는지에 대한 피드백에 대부분 관심이 있다고 생각합니다. – MichaC
라이브러리 헤더 파일에서 TCHAR을 char/wchar_t로 바꾸는 것은 라이브러리 헤더 파일에 #include를 통해 포함 된 헤더 파일을 포함하여 모든 파일을 교체하는 동안에 만 작동합니다. 라이브러리에 따라 일부 표준/시스템 파일이 포함될 수 있습니다. 다른 단점은 라이브러리의 새 버전을 구할 때 무엇입니까?다시 검색하고 바꾸시겠습니까? –