2009-08-27 10 views
5

Jestem w procesie uczenia się C++ i natknąłem się na artykuł na MSDN tutaj:Co Microsoft używa jako typ danych dla ciągów Unicode?

http://msdn.microsoft.com/en-us/magazine/dd861344.aspx

W pierwszym przykładzie kodu jeden wiersz kodu, który moje pytanie dotyczy jest następujący:

VERIFY(SetWindowText(L"Direct2D Sample")); 

W szczególności ten prefiks L. Miałem trochę czytać i popraw mnie, jeśli się mylę :-), ale jest to dozwolone dla ciągów unicode, tzn. Do przygotowania długiego zestawu znaków. Teraz w czasie mojego przeczytać na to natknąłem innym artykule na temat technik Adavnced smyczkowy C tutaj http://www.flipcode.com/archives/Advanced_String_Techniques_in_C-Part_I_Unicode.shtml

Mówi istnieje kilka opcji, w tym włączenia nagłówku:

#define UNICODE 

LUB

#define _UNICODE 

w C, jeszcze raz wskaż, jeśli się mylę, doceń swoją opinię. Dalsze pokazuje typ danych odpowiedni dla tych Unicode ciągi są:

wchar_t 

To rzuca w mix makro i rodzaj hybrydowym typu danych, makra są:

_TEXT(t) 

który po prostu prefiksów ciąg z typ danych L i hybrydowy jako

TCHAR 
Wskazuje, że pozwoli na kodowanie Unicode, jeśli jest tam nagłówek, a ASCII, jeśli nie. Teraz moje pytanie brzmi, czy raczej o jakimś potwierdzeniu, które chciałbym potwierdzić, czy Microsoft użyłby tego typu danych TCHAR, który jest bardziej elastyczny lub czy istnieje jakakolwiek korzyść, aby zobowiązać się do korzystania z wchar_t.

Również kiedy mówię, że Microsoft używa tego, a konkretniej do przykładu w bibliotekach ATL i WTL, czy ktokolwiek z was ma preferencje lub ma jakieś porady dotyczące tego?

Cheers,

Andrew

+0

Dzięki za opinie wszystkich! Doceniam to! :-) –

Odpowiedz

12

dla wszystkich nowych programów należy określić UNICODE i wykorzystać wchar_t bezpośrednio. Korzystanie z ANSI stirngs wróci cię prześladować.

Powinieneś po prostu użyć wchar_t i szerokich wersji wszystkich funkcji CRT (np: wcscmp zamiast strcmp). Makra TEKST i TCHAR itd. Istnieją, jeśli twój kod musi działać w środowiskach ANSI i UNICODE, które uważam, że kod rzadko musi robić.

Po utworzeniu nowej aplikacji systemu Windows przy użyciu programu Visual Studio standard UNICODE jest definiowany automatycznie, a wchar_t będzie działał jak wbudowany.

1

TCHAR zmienia swój typ zależności czy UNICODE jest zdefiniowany, i powinny być stosowane, jeśli chcesz kod, który można skompilować dla Unicode i non-Unicode.

Jeśli chcesz jawnie przetwarzać tylko dane UNICODE, możesz użyć wchar_t.

5

Krótka odpowiedź: infrastruktura hybrydowy z typem TCHAR The _TEXT() makro i różne _t* funkcje (_tcscpy przychodzi do głowy) są powrotem do czasów, gdy Microsoft miał dwie platformy koegzystujący:

  1. Windows Linia NT została oparta na reprezentacji ciągów Unicode
  2. Linia Windows 95/98/ME została oparta na reprezentacji ciągów ANSI.

Przedstawienie ciągów oznacza tutaj, że wszystkie interfejsy API systemu Windows, które oczekiwały lub zwróciły łańcuchy do aplikacji, używały jednej lub drugiej reprezentacji dla tych ciągów. COM dodał jeszcze więcej nieporozumień, ponieważ był dostępny na obu platformach - i oczekiwany ciągi Unicode na obu!

W dawnych czasach zachęcano do napisania "przenośnego" kodu: polecono Ci używać hybrydowej infrastruktury dla twoich strun, abyś mógł skompilować oba modele, definiując/niezdefiniowując UNICODE i/lub _UNICODE dla twojego aplikacja.

Ponieważ linia Windows9x nie jest już istotna (w większości przypadków) można bezpiecznie zignorować świat ANSI i bezpośrednio użyć ciągów Unicode.

Pamiętaj jednak, że Unicode ma dziś wiele reprezentacji: jak wskazano powyżej, konwencja Unicode implikowana przez wchar_t jest reprezentacją UCS-2 (wszystkie znaki zakodowane w 16-bitowych słowach). Istnieją inne, szeroko stosowane reprezentacje, w których niekoniecznie jest to prawda.

Powiązane problemy