TCHAR은 여전히 ​​관련이 있습니까?

TCHAR은 여전히 ​​관련이 있습니까?

---

저는 Windows 프로그래밍을 처음 접했고 Petzold 책을 읽은 후 궁금합니다.

문자열을 선언 하는 데 TCHAR유형과 _T()함수 를 사용하는 것이 여전히 좋은 방법 입니까? 아니면 새 코드에서 wchar_t및 L""문자열을 사용해야 하나요?

Windows 2000 이상 만 대상 으로하고 시작부터 코드는 i18n 입니다.

---

오늘 새 프로젝트를 수행한다면 여전히 TCHAR 구문을 사용합니다. 그것을 사용하는 것과 WCHAR 구문을 사용하는 것 사이에는 실질적인 차이가 많지 않으며 문자 유형이 무엇인지 명시적인 코드를 선호합니다. 대부분의 API 함수와 도우미 개체는 TCHAR 유형 (예 : CString)을 사용 / 사용하므로 사용하는 것이 합리적입니다. 또한 어느 시점에서 ASCII 앱에서 코드를 사용하기로 결정했거나 Windows가 Unicode32 등으로 진화 한 경우 유연성을 제공합니다.

WCHAR 경로로 가기로 결정했다면 명시 적으로 설명하겠습니다. 즉, CString 대신 CStringW를 사용하고 TCHAR로 변환 할 때 매크로를 캐스팅합니다 (예 : CW2CT).

어쨌든 그것은 내 의견입니다.

---

짧은 대답 : 아니오 .

이미 작성한 다른 모든 프로그래머와 마찬가지로 많은 프로그래머가 여전히 TCHAR 및 해당 함수를 사용합니다. 내 겸손한 의견으로 는 전체 개념이 나쁜 생각 이었습니다. UTF-16 문자열 처리는 단순한 ASCII / MBCS 문자열 처리와는 많이 다릅니다. 두 가지 모두에 동일한 알고리즘 / 함수를 사용하는 경우 (이것이 TCHAR 아이디어의 기반입니다!), 단순한 문자열 연결보다 약간 더 많은 작업을 수행하는 경우 (예 : 구문 분석 등). 주된 이유는 대리자 입니다.

유일한 예외로 당신은 때 정말 유니 나는 새로운 응용 프로그램에서 과거이 수하물을 사용하는 이유를 볼 지원하지 않는 시스템에 대한 귀하의 응용 프로그램을 컴파일해야합니다.

---

나는 Sascha에 동의해야합니다. TCHAR/ _T()/ 등 의 기본 전제 는 "ANSI"기반 응용 프로그램을 작성한 다음 매크로를 정의하여 마법처럼 유니 코드 지원을 제공 할 수 있다는 것입니다. 그러나 이것은 몇 가지 나쁜 가정을 기반으로합니다.

소프트웨어의 MBCS 및 유니 코드 버전을 모두 적극적으로 빌드해야합니다.

그렇지 않으면, 당신은 것 까지 미끄러 보통 사용하는 char*많은 장소에서 문자열을.

_T ( "...") 리터럴에서 비 ASCII 백 슬래시 이스케이프를 사용하지 않습니다.

"ANSI"인코딩이 ISO-8859-1 이 아니면 결과 char*와 wchar_t*리터럴은 동일한 문자를 나타내지 않습니다.

UTF-16 문자열은 "ANSI"문자열처럼 사용됩니다.

그들은 아니다. 유니 코드는 대부분의 레거시 문자 인코딩에 존재하지 않는 몇 가지 개념을 도입합니다. 대리. 문자 결합. 표준화. 조건부 및 언어 구분 대소 문자 규칙.

그리고 아마도 가장 중요한 것은 UTF-16이 디스크에 저장되거나 인터넷을 통해 전송되는 경우가 드물다는 사실입니다. UTF-8은 외부 표현에 선호되는 경향이 있습니다.

애플리케이션이 인터넷을 사용하지 않는다는 사실

(이제,이에 대한 올바른 가정 할 수있다 당신의 ... 소프트웨어 만)

웹은 UTF-8 과 더 희귀 한 인코딩으로 실행 됩니다. 이 TCHAR개념은 "ANSI"( UTF-8 일 수 없음 )와 "유니 코드"(UTF-16) 두 가지만 인식 합니다. Windows API 호출이 유니 코드를 인식하도록 만드는 데 유용 할 수 있지만 웹 및 전자 메일 앱이 유니 코드를 인식하도록 만드는 데는 쓸모가 없습니다.

타사 라이브러리를 사용하지 않음

다른 사람은 TCHAR. Poco 는 std::stringUTF-8을 사용합니다. SQLite 에는 UTF-8 및 UTF-16 버전의 API가 있지만 TCHAR. TCHAR표준 라이브러리에도 없으므로 std::tcout직접 정의 하지 않는 한 없습니다 .

TCHAR 대신 내가 추천하는 것

유효한 UTF-8이 아닌 파일을 읽어야하는 경우를 제외하고 "ANSI"인코딩이 존재한다는 사실을 잊어 버리십시오. TCHAR너무 잊어라 . 항상 Windows API 함수의 "W"버전을 호출하십시오. #define _UNICODE실수로 "A"함수를 호출하지 않도록합니다.

문자열에는 항상 UTF 인코딩을 사용합니다. 문자열에는 UTF-8, char문자열에는 UTF-16 (Windows) 또는 UTF-32 (Unix 계열 시스템)를 wchar_t사용합니다. typedef UTF16및 UTF32문자 유형은 플랫폼의 차이를 방지 할 수 있습니다.

---

아직 실행 중인지 궁금하다면 예-여전히 꽤 많이 사용됩니다. TCHAR와 _T ( "")를 사용하면 아무도 당신의 코드를 재미있게 보지 않을 것입니다. 내가 지금 작업하고있는 프로젝트는 ANSI에서 유니 코드로 변환하는 것입니다. 그리고 우리는 이식 가능한 (TCHAR) 경로로 가고 있습니다.

하나...

내 투표는 모든 ANSI / UNICODE 포터블 매크로 (TCHAR, _T ( "") 및 모든 _tXXXXXX 호출 등)를 잊어 버리고 모든 곳에서 유니 코드를 가정하는 것입니다. ANSI 버전이 필요하지 않다면 이식성에 대한 요점을 알지 못합니다. 모든 와이드 문자 기능과 유형을 직접 사용합니다. 모든 문자열 리터럴을 L로 미리 시작합니다.

---

소개하여 Windows 프로그래밍 기사 MSDN에 말한다

새 응용 프로그램은 항상 API의 유니 코드 버전을 호출해야합니다.

TEXT 및 TCHAR의 모든 응용 프로그램이 유니 코드를 사용해야하기 때문에 매크로는 오늘 덜 유용합니다.

나는 wchar_t및 L"".

---

다른 접근법을 제안하고 싶습니다 (둘 중 어느 것도 아님).

요약하면 UTF-8 인코딩을 가정하고 char * 및 std :: string을 사용하고 API 함수를 래핑 할 때만 UTF-16으로 변환합니다.

Windows 프로그램에서이 접근 방식에 대한 자세한 정보와 이유는 http://www.utf8everywhere.org 에서 찾을 수 있습니다 .

---

TCHAR/ WCHAR일부 레거시 프로젝트에는 충분할 수 있습니다. 그러나 새로운 응용 프로그램의 경우 아니오 라고 말할 것 입니다.

이러한 모든 TCHAR/ WCHAR물건 때문에 역사적 이유가있다. TCHARANSI 텍스트 인코딩 (MBCS)과 유니 코드 텍스트 인코딩 (UTF-16) 사이를 전환하는 깔끔한 방법 (가장)을 제공합니다. 과거에 사람들은 세계의 모든 언어의 문자 수를 이해하지 못했습니다. 그들은 2 바이트가 모든 문자를 표현하기에 충분하다고 가정했고 따라서를 사용하는 고정 길이 문자 인코딩 체계를 가지고 WCHAR있습니다. 그러나 1996 년 유니 코드 2.0이 출시 된 이후에는 더 이상 사실이 아닙니다 .

즉 , CHAR/ WCHAR/ 에서 어떤 것을 사용하든 TCHAR프로그램의 텍스트 처리 부분은 국제화 를 위해 가변 길이 문자 를 처리 할 수 ​​있어야합니다 .

So you actually need to do more than choosing one from CHAR/WCHAR/TCHAR for programming in Windows:

1. If your application is small and does not involve text processing (i.e. just passing around the text string as arguments), then stick with WCHAR. Since it is easier this way to work with WinAPI with Unicode support.
2. Otherwise, I would suggest using UTF-8 as internal encoding and store texts in char strings or std::string. And covert them to UTF-16 when calling WinAPI. UTF-8 is now the dominant encoding and there are lots of handy libraries and tools to process UTF-8 strings.

Check out this wonderful website for more in-depth reading: http://utf8everywhere.org/

---

Yes, absolutely; at least for the _T macro. I'm not so sure about the wide-character stuff, though.

The reason being is to better support WinCE or other non-standard Windows platforms. If you're 100% certain that your code will remain on NT, then you can probably just use regular C-string declarations. However, it's best to tend towards the more flexible approach, as it's much easier to #define that macro away on a non-windows platform in comparison to going through thousands of lines of code and adding it everywhere in case you need to port some library to windows mobile.

---

IMHO, if there's TCHARs in your code, you're working at the wrong level of abstraction.

Use whatever string type is most convenient for you when dealing with text processing - this will hopefully be something supporting unicode, but that's up to you. Do conversion at OS API boundaries as necessary.

When dealing with file paths, whip up your own custom type instead of using strings. This will allow you OS-independent path separators, will give you an easier interface to code against than manual string concatenation and splitting, and will be a lot easier to adapt to different OSes (ansi, ucs-2, utf-8, whatever).

---

The only reasons I see to use anything other than the explicit WCHAR are portability and efficiency.

If you want to make your final executable as small as possible use char.

If you don't care about RAM usage and want internationalization to be as easy as simple translation, use WCHAR.

If you want to make your code flexible, use TCHAR.

If you only plan on using the Latin characters, you might as well use the ASCII/MBCS strings so that your user does not need as much RAM.

For people who are "i18n from the start up", save yourself the source code space and simply use all of the Unicode functions.

---

Just adding to an old question:

NO

Go start a new CLR C++ project in VS2010. Microsoft themselves use L"Hello World", 'nuff said.

참고URL : https://stackoverflow.com/questions/234365/is-tchar-still-relevant