2011-03-25 3 views
0

내 보관소에 보관 된 일부 오래된 C++ 소스를 iOS로 이식하여 ObjC GUI를 제공하고 일부 C++ 항목에 래퍼를 사용하고 중요한 데이터를 남겨 둘 생각입니다. C++ 코드 내에서 작동합니다. 그래서, 문제는 오래된 소스가 Win32 MFC에서 문자열을위한 CString 클래스를 사용하고 있다는 것입니다. Joe O'Leary의 CStdString과 대체하려고합니다. C++ 템플릿 클래스는 괜찮습니다. 그러나 :하나 이상의 소스에있는 C++ 템플릿 클래스와 ObjC 및 C++ 믹싱

커다란 C++ 소스와 함께 문자열 클래스 정의를 사용해야하므로 각각 CStdString 템플릿이 자체적으로 포함됩니다. 일반적으로 전체 문자열 클래스에 대한 래퍼를 작성하지만, 필요가 없다면 더 좋습니다.

다른 소스에서 문자열의 인스턴스화에 문제가 있습니까? 한 소스에서 다른 소스로 템플릿 문자열을 전달하는 것이 문제가 될 수 있습니까? 컴파일러가 동일한 인스턴스화 유형이 템플릿에 사용된다는 사실을 가지고 한 번만 또는 여러 번 템플릿에 대한 코드를 생성하는지는 실제로 알 수 없습니다.

약간의 빛을 채울 수 있습니까? 그들은 잠재적 창 이외의 플랫폼에서 사용되는 라이브러리의 어떤 종류의 퍼팅에 좋은 후보가되지 않도록

감사합니다 ...

답변

0

std :: string 또는 C++ 용 다른 다중 플랫폼 문자열 구현을 유지하는 한 어떤 문제도 겪지 않을 것입니다 (심지어 iOS에서도 효과가 있음).

저는 C++/Obj-C를 약 2 년 동안 통합하여 C++로 모델 클래스를 유지하는 것이 (템플릿이 많은 코드 일지라도) 문제가되지 않는다고 확신 할 수 있습니다. Obj-C에서 Obj-C로 가장 잘할 수있는 일을 조언하겠습니다. (해머 개발자가되는 것을 피하십시오 :))

행운을 빌어 요!

+0

안녕하세요 Mr.Gando, 정말 좋아 보입니다 :-) CStdString의 기본 클래스 인 std :: string은 실제로 동일한 프로젝트 내의 다른 소스에 포함될 수 있으며 그 코드는 한 번만 빌드됩니다. - 귀하의 마지막 조언 : 오케이, 그동안 Obj-C에 대해 잘 알고 있습니다. 그러나 그 것이 C++ 코드의 많은 양을 다시 작성하고자 함을 의미하지는 않습니다 :-) – konran

+0

동의합니다. 이식성 또한 좋은 주장. xcode 프로젝트에서 CString을 삭제하고 어떤 일이 발생하는지 확인할 수 있습니다. 윈도우즈에 의존성이 있다면 물건이 잘못 될 수 있습니다. 어떻게 진행되는지 알려주세요. – Goles

+0

좋아요, 예를 들어 멀티 파일링 된 템플릿에 주석 처리되지 않은 부분이 있습니다 ;-) 내 테스트에는 많은 cpp 소스가 포함되지 않았으므로 시간이 더 걸립니다. 지금까지 컴파일러 오류가없고 누수 (Analyzer & Instruments)가없는 typedef'd CString을 삭제할 수 있으며 이렇게 좋은 결과를 얻을 수 있다고 말할 수 있습니다. : - : : .thgir ot tfel morf gnirts lamron a si siht – konran

1

MFC 및 CString는 Windows OS에서 제대로 작동하지 않을 수 있습니다.

내가 조 오리어리의 CStdString 클래스에 익숙하지 않아요하지만 난 C의 외부 사용을위한 기능을 "extern C" 수출에 가능한 한 많은 std::stringchar*를 사용하여 포장 권하고 싶습니다 ++ 땅은 C 스타일의 문자열은 더 쉽게 그대로 C++ 라이브러리를 호출해야하는 다른 언어와 호환됩니다.

템플릿과 마찬가지로 모든 유사 콘텐츠가 컴파일 타임에 생성 된 다음 런타임에 올바른 구현이 선택됩니다. 그러나 당신의 문제는 한 종류의 문자열에서 다른 언어로 번역 될 가능성이 가장 높습니다. 중간 또는 래퍼를 만들어서 한 언어의 문자열 유형에서 다른 언어로 마샬링해야 할 수도 있습니다.

+0

음, Joe의 CStdString은 실제로 std :: string의 파생 클래스입니다. 나는 그것을 여러 번 사용했고 오늘은 최신 버전을 사용했다. (2005 년, 마지막으로 사용한 것은 4 살이다.) 불투명 포인터를 통해 Obj-C 래퍼 클래스로 테스트했다. 모든 것이 잘되었습니다. 그래서 문자열 전송 Obj-C <=> C++은 조금 문제가되지 않습니다. 이 클래스를 사용하는 주된 측면은 CStdString에서 CString에 typedef를 만들고 기존 코드의 대부분에 제공 할 수 있다는 것입니다. 다른 클래스를 대체해야하기 때문에 거기에서 사용 된 유일한 중요한 MFC 유형이기 때문입니다. – konran

+0

'std :: basic_string' 소멸자가'virtual'이 아니기 때문에 STL 문자열, 즉': public std :: string'에서 파생되는 것은 나쁜 생각입니다. 구현에 멤버가 추가되면 파생 오브젝트가 제대로 파기되지 않습니다. 'std :: string'는 상속을위한 기본 클래스로 의도되거나 올바르게 구현되지 않았습니다. – AJG85

+0

고마워, 좋은 지적이야! 어쨌든 나쁜 일 - 좋은 점 : CStdString에는 멤버가 없습니다.이것은 std :: basic_string의 1/2 바이트 인스턴스화를위한 간단한 래퍼입니다. MFC CString이 제공하는 대부분의 기능과 넓은 유용성이 편리합니다. 필자는 10 년 전부터 Linux에서, 그리고 MFC를 사용할 수없는 Win32에서 사용했습니다. 조 (Joe)의 연구는 개발 7 년 이내에 ~ 50 명의 도움을 받아 1998 년부터 시작되었습니다. 나는 그들이 템플릿에 부작용을 일으켰다 고 생각한다. – konran

관련 문제