Windows programlama konusunda yeniyim ve Petzold kitabını okuduktan sonra merak ediyorum:
dizeleri bildirmek için TCHARtürü ve _T()işlevi kullanmak hala iyi bir uygulama mı yoksa yeni kodda yalnızca wchar_tve L""dizelerini kullanmalı mıyım?
Yalnızca Windows 2000 ve üzerini hedefleyeceğim ve kodum başlangıçtan itibaren i18n olacak .
Yanıtlar:
Bugün yeni bir proje yapıyor olsaydım yine de TCHAR sözdizimini kullanırdım. Kullanmakla WCHAR sözdizimi arasında pek pratik bir fark yok ve ben karakter türünün ne olduğu konusunda açık olan kodu tercih ediyorum. Çoğu API işlevi ve yardımcı nesne TCHAR türlerini aldığı / kullandığı için (örneğin: CString), onu kullanmak mantıklıdır. Ayrıca, kodu bir noktada ASCII uygulamasında kullanmaya karar verirseniz veya Windows Unicode32'ye dönüşürse, size esneklik sağlar.
WCHAR rotasına gitmeye karar verirseniz, bu konuda açık olurum. Yani, CString yerine CStringW kullanın ve TCHAR'a dönüştürürken makroları yayınlayın (örneğin: CW2CT).
Her neyse, bu benim fikrim.
Kısa cevap: HAYIR .
Diğerlerinin zaten yazdığı gibi, birçok programcı hala TCHAR'ları ve bunlara karşılık gelen işlevleri kullanıyor. Benim naçizane fikrime göre tüm konsept kötü bir fikirdi . UTF-16 dizge işleme, basit ASCII / MBCS dizgi işlemeden çok farklıdır. Her ikisiyle de aynı algoritmaları / işlevleri kullanırsanız (TCHAR fikrinin temeli budur!), Basit dizgi birleştirmeden biraz daha fazlasını yapıyorsanız UTF-16 sürümünde çok kötü performans elde edersiniz (örneğin ayrıştırma vb.). Ana neden, Suretler .
Tek istisna olan ne zaman gerçekten Unicode Yeni bir uygulamada geçmişten bu bagajı kullanmak için hiçbir neden görmüyorum desteklemeyen bir sistem için başvurunuzu derlemeliyiz.
TCHARartık kullanılmaması gerektiğini kabul ederken , bunun kötü bir fikir olduğuna katılmıyorum. Ben de düşünüyorum eğer seçtiğiniz kullanmak yerine açık olmak TCHARmüstehcen olmalı her yerde . Bildirimlerinde TCHAR/ _TCHAR(gibi _tmain) işlevlerini de kullanmam . Basitçe söylemek gerekirse: tutarlı olun. Hala +1.
TCHARBaşlangıçta ne için tanıtıldığını yanlış beyan ediyorsunuz : Windows'un Win 9x ve Windows NT tabanlı sürümleri için kod geliştirmeyi kolaylaştırmak için. O sırada, Windows NT'nin UTF-16 uygulaması UCS-2 idi ve dize ayrıştırma / işleme algoritmaları aynıydı. Suret yoktu. Yinelemelerde bile, DBCS (Windows için desteklenen tek MBCS kodlaması) ve UTF-16 için algoritmalar aynıdır: Her iki kodlamada da bir kod noktası bir veya iki kod biriminden oluşur.
Sascha'ya katılıyorum. TCHAR/ _T()/ Vb .'nin temel dayanağı, "ANSI" tabanlı bir uygulama yazabilmeniz ve ardından bir makro tanımlayarak sihirli bir şekilde ona Unicode desteği verebilmenizdir. Ancak bu, birkaç kötü varsayıma dayanmaktadır:
Yazılımınızın hem MBCS hem de Unicode sürümlerini aktif olarak oluşturduğunuz
Aksi takdirde, olacak kadar kayma ve sıradan kullanmak char*birçok yerde dizeleri.
_T ("...") değişmez değerlerinde ASCII olmayan ters eğik çizgi kaçışları kullanmadığınız
"ANSI" kodlamanız ISO-8859-1 olmadıkça, sonuç char*ve wchar_t*değişmez değerler aynı karakterleri temsil etmeyecektir.
UTF-16 dizelerinin tıpkı "ANSI" dizeleri gibi kullanıldığı
Onlar değil. Unicode, çoğu eski karakter kodlamasında bulunmayan birkaç kavram sunar. Suretler. Karakterleri birleştirmek. Normalleştirme. Koşullu ve dile duyarlı büyük / küçük harf kuralları.
Ve belki de en önemlisi, UTF-16'nın nadiren diske kaydedilmesi veya İnternet üzerinden gönderilmesi gerçeği: UTF-8 harici gösterim için tercih edilme eğilimindedir.
Uygulamanızın İnternet'i kullanmadığını
(Şimdi, bunun için geçerli bir varsayım olabilir senin ... yazılım, ama)
Web, UTF-8 ve çok sayıda nadir kodlamayla çalışır . TCHARKavram sadece iki tanır: ( "ANSI" olamaz UTF-8 olmak ) ve "Unicode" (UTF-16). Windows API çağrılarınızın Unicode duyarlı olmasını sağlamak için yararlı olabilir, ancak web ve e-posta uygulamalarınızı Unicode duyarlı hale getirmek için kesinlikle yararsızdır.
Microsoft'a ait olmayan kitaplıklar kullanmadığınız
Başka kimse kullanmıyor TCHAR. Poco kullanır std::stringve UTF-8. SQLite , API'sinin UTF-8 ve UTF-16 sürümlerine sahiptir, ancak yoktur TCHAR. TCHARstandart kitaplıkta bile değildir, bu yüzden std::tcoutkendiniz tanımlamak istemediğiniz sürece hayır .
Geçerli UTF-8 olmayan bir dosyayı okumanız gerektiği durumlar dışında "ANSI" kodlamalarının var olduğunu unutun. Siz TCHARde unutun . Her zaman Windows API işlevlerinin "W" sürümünü çağırın. #define _UNICODEsadece yanlışlıkla "A" işlevini çağırmadığınızdan emin olmak için.
Dizeler için her zaman UTF kodlamalarını kullanın: dizeler için UTF-8 ve chardizeler için UTF-16 (Windows'ta) veya UTF-32 (Unix benzeri sistemlerde) wchar_t. typedef UTF16ve UTF32platform farklılıklarından kaçınmak için karakter türleri.
#define _UNICODEşimdi bile sürdürülmesi gereken uygulamalar var . İletimin sonu :)
_UNICODECRT'de genel metin eşlemelerinin nasıl çözümlendiğini kontrol eder. Bir Windows API'nin ANSI sürümünü çağırmak istemiyorsanız, tanımlamanız gerekir UNICODE.
Hala pratikte olup olmadığını merak ediyorsanız, o zaman evet - hala oldukça kullanılıyor. TCHAR ve _T ("") kullanıyorsa kimse kodunuza komik bakmayacaktır. Şu anda üzerinde çalıştığım proje ANSI'den unicode'a dönüştürüyor - ve taşınabilir (TCHAR) rotaya gidiyoruz.
Ancak...
Benim oyum, tüm ANSI / UNICODE taşınabilir makrolarını (TCHAR, _T ("") ve tüm _tXXXXXX çağrılarını, vb.) Unutmak ve her yerde unicode varsaymak olacaktır. Bir ANSI sürümüne asla ihtiyacınız olmayacaksa, taşınabilir olmanın anlamını gerçekten görmüyorum. Tüm geniş karakter işlevlerini ve türlerini doğrudan kullanırdım. Tüm dize değişmezlerini bir L ile ekleyin.
Giriş Windows Programlama makale MSDN diyor
Yeni uygulamalar her zaman Unicode sürümlerini (API'nin) çağırmalıdır.
METİN ve TCHAR tüm uygulamalar Unicode kullanmalıdır çünkü makrolar bugün daha az yararlıdır.
Ben sopa wchar_tve L"".
Farklı bir yaklaşım önermek isterim (ikisi de değil).
Özetlemek için, UTF-8 kodlamasını varsayarak char * ve std :: string kullanın ve UTF-16'ya dönüşümleri yalnızca API işlevlerini sararken yapın.
Windows programlarında bu yaklaşım için daha fazla bilgi ve gerekçe http://www.utf8everywhere.org adresinde bulunabilir .
TCHAR/ WCHARBazı eski projeler için yeterli olabilir. Ancak yeni uygulamalar için HAYIR derdim .
Bütün bunlar TCHAR/ WCHARşeyler tarihsel nedenlerden dolayı var. TCHARANSI metin kodlaması (MBCS) ve Unicode metin kodlaması (UTF-16) arasında geçiş yapmak için görünüşte düzgün bir yol (gizleme) sağlar. Geçmişte insanlar dünyadaki tüm dillerin karakter sayısını anlamıyorlardı. Tüm karakterleri temsil etmek için 2 baytın yeterli olduğunu ve dolayısıyla sabit uzunlukta bir karakter kodlama şemasına sahip olduklarını varsaydılar WCHAR. Ancak, Unicode 2.0'ın 1996'da piyasaya sürülmesinden sonra bu artık geçerli değildir .
Yani: CHAR/ WCHAR/ içinde hangisini kullanırsanız kullanın TCHAR, programınızdaki metin işleme kısmı uluslararasılaştırma için değişken uzunlukta karakterleri işleyebilmelidir .
Yani aslında Windows'ta programlama için CHAR/ WCHAR/ içinden birini seçmekten daha fazlasını yapmanız gerekir TCHAR:
WCHAR. Unicode destekli WinAPI ile bu şekilde çalışmak daha kolay olduğu için.Daha derinlemesine okumak için bu harika web sitesine göz atın: http://utf8everywhere.org/
Evet kesinlikle; en azından _T makrosu için. Yine de geniş karakterli şeylerden pek emin değilim.
Bunun nedeni, WinCE'yi veya diğer standart olmayan Windows platformlarını daha iyi desteklemektir. Kodunuzun NT'de kalacağından% 100 eminseniz, muhtemelen normal C-string bildirimlerini kullanabilirsiniz. Bununla birlikte, daha esnek bir yaklaşıma yönelmek en iyisidir, çünkü bu makroyu Windows olmayan bir platformda tanımlamak, binlerce satır koddan geçmek ve bazı kitaplıkları taşımanız gerektiğinde onu her yere eklemekle karşılaştırıldığında çok daha kolaydır. Windows mobile'a.
IMHO, kodunuzda TCHAR'lar varsa, yanlış soyutlama düzeyinde çalışıyorsunuz demektir.
Kullanım neyse bu umutla şey destekleyen unicode olacak, ama bu size kalmış - metin işleme ile uğraşırken dize türü sizin için en uygundur. Gerektiği gibi, OS API sınırlarında dönüştürme yapın.
Dosya yollarıyla uğraşırken, dizeleri kullanmak yerine kendi özel türünüzü oluşturun. Bu, işletim sisteminden bağımsız yol ayırıcılara izin verir, size manuel dize birleştirme ve bölmeye göre kodlama için daha kolay bir arayüz sağlar ve farklı işletim sistemlerine (ansi, ucs-2, utf-8, ne olursa olsun) uyarlamak çok daha kolay olacaktır. .
Açık WCHAR dışında herhangi bir şey kullanmamın tek nedeni taşınabilirlik ve verimliliktir.
Son çalıştırılabilir dosyanızı olabildiğince küçük yapmak istiyorsanız, char kullanın.
RAM kullanımını önemsemiyorsanız ve uluslararasılaştırmanın basit çeviri kadar kolay olmasını istiyorsanız, WCHAR'ı kullanın.
Kodunuzu esnek hale getirmek istiyorsanız, TCHAR kullanın.
Yalnızca Latin karakterleri kullanmayı planlıyorsanız, ASCII / MBCS dizelerini de kullanabilirsiniz, böylece kullanıcınız çok fazla RAM'e ihtiyaç duymaz.
"Başlangıçtan itibaren i18n" olan kişiler için, kaynak kodu alanından tasarruf edin ve tüm Unicode işlevlerini kullanın.
Sadece eski bir soruya ekliyoruz:
VS2010'da yeni bir CLR C ++ projesi başlatın. Microsoft'un kendisi kullanıyor L"Hello World", 'dedi.
Cve C++. Cevaplar her zaman kendi yazarları tarafından silinebilir. Bu hükmü kullanmak için iyi bir zaman olacaktır.
TCHARlimana yeni bir anlam var WCHARiçin CHAR.
https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
Windows 10'un son sürümleri , uygulamalara UTF-8 desteği sunmak için ANSI kod sayfasını ve -A API'lerini kullandı. ANSI kod sayfası UTF-8 için yapılandırılmışsa, -A API'leri UTF-8'de çalışır.