2009-08-27 4 views
5

Io sono nel processo di apprendimento C++ e sono imbattuto in un articolo su MSDN qui:Che cosa utilizza Microsoft come tipo di dati per le stringhe Unicode?

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

Nel primo esempio di codice l'una riga di codice che la mia domanda riguarda è la seguente:

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

Più precisamente il prefisso L. Ho letto un po 'e correggo se ho torto :-), ma questo è per consentire stringhe unicode, cioè per preparare un set di caratteri lungo. Ora durante il mio leggere su questo mi sono imbattuto in un altro articolo sulle tecniche Adavnced stringa in C qui http://www.flipcode.com/archives/Advanced_String_Techniques_in_C-Part_I_Unicode.shtml

Si dice che ci sono un paio di opzioni, tra cui l'inserimento della testata:

#define UNICODE 

O

#define _UNICODE 

in C, ancora una volta indicare se ho torto, apprezzare il vostro feedback. Inoltre mostra il tipo di dati adatto per queste stringhe Unicode essere:

wchar_t 

Si getta nella mischia una macro e una sorta di tipo di dati ibrida, la macro essere:

_TEXT(t) 

che prefissi semplicemente la stringa con L e il tipo di dati ibrido come

TCHAR 

che si sottolinea consentirà unicode se l'intestazione è lì e se non ASCII. Ora la mia domanda è, o più di un'aspirazione che vorrei confermare, Microsoft userebbe questo tipo di dati TCHAR che è più flessibile o c'è qualche vantaggio nell'impegnarsi ad usare wchar_t.

Anche quando dico che Microsoft usa questo, più specificamente per exmaple nelle librerie ATL e WTL, qualcuno di voi ha una preferenza o ha qualche consiglio in merito?

Cheers,

Andrew

+0

Grazie per il feedback di tutti! Apprezzalo! :-) –

risposta

12

per tutti i nuovi software è necessario definire Unicode e utilizzare wchar_t direttamente. Usando ANSI stirngs tornerai a perseguitarti.

Dovresti semplicemente utilizzare wchar_t e le versioni estese di tutte le funzioni CRT (ad esempio: wcscmp anziché strcmp). Le macro TEXT e TCHAR ecc. Esistono solo se il tuo codice deve funzionare in ambienti ANSI e UNICODE che ritengo che raramente il codice debba fare.

Quando si crea una nuova applicazione Windows utilizzando Visual Studio UNICODE viene automaticamente definita e wchar_t funzionerà come un built-in.

1

TCHAR cambia il suo tipo a seconda se UNICODE è definito, e dovrebbe essere usato quando si vuole codice che è possibile compilare per Unicode e non Unicode.

Se si desidera elaborare in modo esplicito solo i dati UNICODE, sentirsi liberi di utilizzare wchar_t.

5

Risposta breve: l'infrastruttura ibrida con il tipo TCHAR, il _TEXT() macro e le varie _t* funzioni (_tcscpy viene in mente) sono un ritorno ai tempi in cui Microsoft aveva due piattaforme coesistenti:

  1. Windows La linea NT era basata sulla rappresentazione della stringa Unicode
  2. La linea Windows 95/98/ME era basata sulla rappresentazione di stringa ANSI.

Rappresentazione stringa qui significa che tutte le API di Windows che prevedevano o restituivano una stringa all'app utilizzavano una o l'altra rappresentazione per queste stringhe. COM ha aggiunto ancora più confusione dato che era disponibile su entrambe le piattaforme e le stringhe Unicode previste su entrambi!

In quei vecchi tempi era consigliabile scrivere codice "portatile": ti veniva richiesto di utilizzare l'infrastruttura ibrida per le stringhe in modo da poter compilare per entrambi i modelli semplicemente definendo/indefinendo UNICODE e/o _UNICODE per il tuo app.

Poiché la linea Windows9x non è più rilevante (per la maggior parte delle app) è possibile ignorare tranquillamente il mondo ANSI e utilizzare direttamente le stringhe Unicode.

Attenzione però che Unicode ha rappresentazioni multiple oggi: come si è sottolineato sopra la convenzione Unicode implicita da wchar_t è la rappresentazione UCS-2 (tutti i caratteri codificati in parole di 16 bit). Esistono altre rappresentazioni ampiamente utilizzate in cui ciò non è necessariamente vero.