TCHAR è ancora rilevante?

Question

Sono nuovo nella programmazione di Windows e dopo aver letto il libro di Petzold mi chiedo:

è ancora buona norma utilizzare il tipo TCHAR e la funzione _T () per dichiarare le stringhe o se dovessi semplicemente usare wchar_t e L " " stringhe nel nuovo codice?

Prenderò di mira solo Windows 2000 e versioni successive e il mio codice sarà i18n dall'inizio .

Answer 1

Userei ancora la sintassi TCHAR se stessi facendo un nuovo progetto oggi. Non c'è molta differenza pratica tra usarlo e la sintassi di WCHAR, e preferisco il codice che è esplicito in quale sia il tipo di carattere. Poiché la maggior parte delle funzioni API e degli oggetti helper accettano / usano i tipi TCHAR (ad es .: CString), ha senso usarlo. Inoltre ti dà flessibilità se decidi di utilizzare il codice in un'app ASCII ad un certo punto, o se Windows si evolve mai in Unicode32, ecc.

Se decidessi di seguire il percorso WCHAR, sarei esplicito a riguardo. Cioè, usa CStringW invece di CString e esegui il casting di macro quando esegui la conversione in TCHAR (ad esempio: CW2CT).

Questa è la mia opinione, comunque.

Answer 2

La risposta breve: NO .

Come tutti gli altri hanno già scritto, molti programmatori usano ancora TCHAR e le funzioni corrispondenti. Secondo la mia modesta opinione l'intero concetto era una cattiva idea . L'elaborazione della stringa UTF-16 è molto diversa dalla semplice stringa ASCII / MBCS in lavorazione. Se usi gli stessi algoritmi / funzioni con entrambi (questo è ciò su cui si basa l'idea TCHAR!), Otterrai prestazioni pessime sulla versione UTF-16 se stai facendo un po 'di più della semplice concatenazione di stringhe (come analisi ecc.). Il motivo principale sono Surrogates .

Con la sola eccezione quando davvero devi compilare la tua domanda per un sistema che non supporta Unicode, non vedo alcun motivo per utilizzare questo bagaglio del passato in una nuova applicazione.

Answer 3

Sono d'accordo con Sascha. La premessa di base di TCHAR / _T () / ecc. È che puoi scrivere un'applicazione basata su " ANSI " e quindi darle magicamente supporto Unicode definendo una macro . Ma questo si basa su diversi presupposti negativi:

Di creare attivamente entrambe le versioni MBCS e Unicode del tuo software

Altrimenti, scivolerai e utilizzerai le normali stringhe char * in molti punti.

Che non si utilizzi escape di barra rovesciata non ASCII in letterali _T (" ... ")

A meno che il tuo " ANSI " la codifica sembra essere ISO-8859-1, i letterali risultanti char * e wchar_t * non rappresenteranno gli stessi caratteri.

Che le stringhe UTF-16 sono usate proprio come " ANSI " stringhe

Non lo sono. Unicode introduce diversi concetti che non esistono nella maggior parte delle codifiche di caratteri legacy. Surrogati. Combinazione di personaggi. Normalizzazione. Regole di involucro condizionate e sensibili al linguaggio.

E forse, soprattutto, il fatto che UTF-16 viene raramente salvato su disco o inviato su Internet: UTF-8 tende a essere preferito per la rappresentazione esterna.

Che l'applicazione non utilizzi Internet

(Ora, questo potrebbe essere un presupposto valido per il tuo software, ma ...)

Il Web funziona su UTF-8 e una pletora di codifiche più rare . Il concetto TCHAR riconosce solo due: " ANSI " (che non può essere UTF-8 ) e " Unicode " (UTF-16). Può essere utile per rendere le tue chiamate API API compatibili con Unicode, ma è dannatamente inutile per rendere le tue app Web e di posta elettronica compatibili con Unicode.

Che non usi librerie non Microsoft

Nessun altro usa TCHAR . Poco utilizza std :: string e UTF-8. SQLite ha versioni UTF-8 e UTF-16 della sua API, ma nessun TCHAR . TCHAR non è nemmeno nella libreria standard, quindi nessun std :: tcout a meno che tu non voglia definirlo tu stesso.

Cosa raccomando invece di TCHAR

Dimentica che " ANSI " esistono codifiche, tranne quando è necessario leggere un file che non è UTF-8 valido. Dimentica anche TCHAR . Chiama sempre " W " versione delle funzioni dell'API di Windows. #define _UNICODE solo per essere sicuro di non chiamare accidentalmente un " A " la funzione.

Usa sempre le codifiche UTF per le stringhe: UTF-8 per le stringhe char e UTF-16 (su Windows) o UTF-32 (su sistemi simili a Unix) per wchar_t stringhe. Tipi di carattere typedef UTF16 e UTF32 per evitare differenze di piattaforma.

Answer 4

Se ti stai chiedendo se è ancora in pratica, allora sì - è ancora usato abbastanza. Nessuno guarderà il tuo codice divertente se utilizza TCHAR e _T (" "). Il progetto a cui sto lavorando ora sta convertendo da ANSI a Unicode - e stiamo andando sulla rotta portatile (TCHAR).

Tuttavia ...

Il mio voto sarebbe quello di dimenticare tutte le macro portatili ANSI / UNICODE (TCHAR, _T (" ") e tutte le chiamate _tXXXXXX, ecc ...) e assumere unicode ovunque. Non vedo davvero il punto di essere portatile se non avrai mai bisogno di una versione ANSI. Vorrei usare direttamente tutte le funzioni e i tipi di caratteri ampi. Preprend tutti i letterali di stringa con una L.

Answer 5

Introduzione all'articolo di programmazione Windows su MSDN dice

  

Le nuove applicazioni devono sempre chiamare le versioni Unicode (dell'API).

     

Le macro TESTO e TCHAR sono oggi meno utili, perché tutte le applicazioni dovrebbero usare Unicode.

Vorrei attenermi a wchar_t e L " " .

Answer 6

Vorrei suggerire un approccio diverso (nessuno dei due).

Per riassumere, utilizzare char * e std :: string, ipotizzando la codifica UTF-8, ed eseguire le conversioni in UTF-16 solo quando si avvolgono le funzioni API.

Ulteriori informazioni e giustificazioni per questo approccio nei programmi Windows sono disponibili in http://www.utf8everywhere.org .

Answer 7

TCHAR / WCHAR potrebbe essere sufficiente per alcuni progetti legacy. Ma per le nuove applicazioni, direi NO .

Tutte queste cose TCHAR / WCHAR sono lì per motivi storici. TCHAR fornisce un modo apparentemente pulito (mascherare) per passare dalla codifica di testo ANSI (MBCS) alla codifica di testo Unicode (UTF-16). In passato, le persone non avevano una comprensione del numero di caratteri di tutte le lingue del mondo. Presupponevano che 2 byte fossero sufficienti per rappresentare tutti i caratteri e che quindi avessero uno schema di codifica dei caratteri a lunghezza fissa usando WCHAR . Tuttavia, questo non è più vero dopo il rilascio di Unicode 2.0 in 1996 .

Vale a dire: Indipendentemente dal tipo utilizzato in CHAR / WCHAR / TCHAR , la parte di elaborazione del testo nel programma dovrebbe essere in grado di gestire lunghezza variabile personaggi per l'internazionalizzazione.

Quindi in realtà devi fare di più che sceglierne uno da CHAR / WCHAR / TCHAR per la programmazione in Windows:

1. Se la tua applicazione è di piccole dimensioni e non comporta l'elaborazione del testo (vale a dire passare semplicemente la stringa di testo come argomenti), quindi usa WCHAR . Poiché in questo modo è più semplice lavorare con WinAPI con supporto Unicode.
2. Altrimenti, suggerirei di usare UTF-8 come codifica interna e memorizzare i testi in stringhe di caratteri o std :: string. E li converte in UTF-16 quando si chiama WinAPI. UTF-8 è ora la codifica dominante e ci sono molte utili librerie e strumenti per elaborare stringhe UTF-8.

Dai un'occhiata a questo meraviglioso sito Web per una lettura più approfondita: http://utf8everywhere.org/

Answer 8

Sì, assolutamente; almeno per la macro _T. Non sono così sicuro delle cose di carattere largo, comunque.

Il motivo è supportare meglio WinCE o altre piattaforme Windows non standard. Se sei sicuro al 100% che il tuo codice rimarrà su NT, probabilmente puoi semplicemente usare le normali dichiarazioni C-string. Tuttavia, è meglio tendere ad un approccio più flessibile, poiché è molto più facile #definire quella macro su una piattaforma non Windows rispetto a passare attraverso migliaia di righe di codice e aggiungerlo ovunque nel caso in cui sia necessario portare una libreria su Windows Mobile.

Answer 9

IMHO, se ci sono TCHAR nel tuo codice, stai lavorando al livello sbagliato di astrazione.

Usa il tipo di stringa qualunque più conveniente per te quando hai a che fare con l'elaborazione del testo - si spera che sia qualcosa che supporti l'unicode, ma dipende da te. Esegui la conversione ai limiti dell'API del sistema operativo, se necessario.

Quando si ha a che fare con i percorsi dei file, montare il proprio tipo personalizzato invece di usare le stringhe. Ciò ti consentirà di separare i percorsi indipendenti dal sistema operativo, ti fornirà un'interfaccia più facile da codificare rispetto alla concatenazione e alla suddivisione manuale delle stringhe e sarà molto più facile adattarsi a diversi sistemi operativi (ansi, ucs-2, utf-8, qualunque cosa) .

Answer 10

Le uniche ragioni che vedo per usare qualcosa di diverso dal WCHAR esplicito sono la portabilità e l'efficienza.

Se vuoi rendere il tuo eseguibile finale il più piccolo possibile usa char.

Se non ti interessa l'utilizzo della RAM e desideri che l'internazionalizzazione sia semplice come una semplice traduzione, usa WCHAR.

Se vuoi rendere flessibile il tuo codice, usa TCHAR.

Se prevedi solo di usare i caratteri latini, potresti anche usare le stringhe ASCII / MBCS in modo che il tuo utente non abbia bisogno di tanta RAM.

Per le persone che sono "i18n dall'inizio", salva te stesso lo spazio del codice sorgente e usa semplicemente tutte le funzioni Unicode.

Answer 11

Sto solo aggiungendo a una vecchia domanda:

NO

Vai avvia un nuovo progetto CLR C ++ in VS2010. Microsoft stessa usa L " Hello World " ", ha detto Nuff.