2015-08-12 10 views
17

Sia x qualsiasi membro del set di caratteri di origine di base. 'x' e L'x' sono rispettivamente membri del set di caratteri di esecuzione di base e del set di caratteri di larghezza di esecuzione di base.Relazione tra 'x' e L'x 'e widen (' x ')

È vero che i valori interi di 'x' e L'x' devono essere uguali? Sembra che lo standard non lo richieda, il che ha senso. Si può teoricamente usare EBCDIC come il set di caratteri stretto e Unicode come set di caratteri ampio.

È vero che std::use_facet<std::ctype<wchar_t>>(std::locale()).widen('x') deve essere uguale a L'x' in alcune (o nessuna) locale? In questo caso ha senso richiedere questo, ma non riesco a trovare tale requisito nello standard. Allo stesso modo, è std::use_facet<std::ctype<wchar_t>>(std::locale()).narrow(L'x') lo stesso di 'x'?

Se quanto sopra non è vero, allora, che uno di questi

std::wcout << L'x'; 
std::wcout << ct.widen('x'); 

dovrebbe uscita x? ct è un aspetto della lingua appropriato.

+0

Il compilatore di Microsoft ha Windows ANSI come set di caratteri stretti e Unicode come set di caratteri esteso. Anche se Windows ANSI è Windows ANSI Western i codici non sono gli stessi. Particolarmente fastidioso, l'Euro segno €. –

+0

@ Cheersandhth.-Alf € non è nel set di caratteri sorgente di base, nessun problema qui. –

+0

A seconda della lingua nazionale in cui è installato Windows, € è nel set di caratteri di esecuzione. Ciò include per gli Stati Uniti e la Norvegia. Devi ignorare la documentazione errata che afferma che il set di caratteri di esecuzione è ASCII, perché credendo che finiresti per produrre programmi con risultati errati, e non sarebbe in grado di dare un senso agli avvertimenti del compilatore. ;-) –

risposta

7

C'è poco che può essere garantito in pratica sui set di caratteri ampi, perché gli standard C e C++ richiedono che tutti i caratteri ampi possano essere rappresentati con un singolo valore di codifica, mentre lo standard nella programmazione Windows è codificato in UTF-16 largo testo. Originariamente il testo di Windows era semplicemente Unicode a 16 bit originale, ora chiamato UCS-2, che è ancora utilizzato nelle finestre di console di Windows e che è conforme ai requisiti C e C++. UTF-16 è un'estensione di UCS-2 che utilizza due valori di codifica, denominati una coppia surrogata, per caratteri al di fuori del piano multilingue multilingue di base di Unicode, a.k.a il BMP.


Re

E 'vero che i valori integrali di 'x' e L'x' devono essere uguali? [Quando x è un membro del set di caratteri di base di origine C++]

Il set di caratteri fonte principale è un sottoinsieme di ASCII, e quasi tutti esistenti codifiche di carattere generale, tra cui in particolare le codifiche Unicode, sono estensioni di ASCII. C'è un'eccezione, vale a dire le codifiche di caratteri EBCDIC di IBM (ci sono più varianti). Tuttavia, se è ancora usato, allora è su mainframe IBM.

Quindi in pratica si ha quella garanzia, ma nel formale non ce l'hai. Ancora più importante, però, è irrilevante. Ad esempio, il set di caratteri di base dell'origine manca del segno $, di cui non ci si può aspettare di fare a meno, vale a dire limitarsi al set di caratteri sorgente di base non è una proposizione pratica.


Re

E 'vero che std::use_facet<std::ctype<wchar_t>>(std::locale()).widen('x') dovrebbe essere pari a L'x' in qualche (o qualsiasi) locale [Se x è un membro del C++ set di caratteri di base di origine]

Per lo stesso motivo per i letterali, sì in pratica, no nel formale (poiché codifiche come EB CDIC sono supportati), e anche questo è irrilevante per il professionista.

In particolare, per l'in-practice, una considerazione più rilevante è che Microsoft Visual C++ ha (non documentato) Windows ANSI come set di caratteri di esecuzione e UTF-16 come codifica di caratteri estesi. Per esempio. sulla mia macchina il set di caratteri di esecuzione è Windows 1252, a.k.a Windows ANSI Western. E alcuni personaggi, in particolare €, hanno codici di caratteri Unicode totalmente differenti. Peggio ancora, potrebbe esserci solo un set di caratteri ristretto che potrebbe essere usato come set di caratteri di esecuzione in cui la codifica UTF-16 di alcuni caratteri userebbe una coppia di valori di codifica surrogati. E in tal caso widen non può nemmeno rappresentare il risultato; non c'è spazio per questo.

+0

Vedere aggiornamento rif. seconda domanda. –

+0

Visual C++ non è conforme poiché alcuni caratteri non possono essere rappresentati come un singolo 'wchar_t'. Se escludiamo quei caratteri e postuliamo che lavoriamo solo con UCS-2, allora tutto sembra OK, perché Windows ANSI e UCS-2 presumibilmente hanno i primi 127 caratteri identici in qualunque tabella codici. –

+0

@ n.m .: Hai ragione che Visual C++ *** e ogni altro compilatore Windows C e C++ *** è formalmente non conforme. AFAIK è dovuto alla sciocca politica degli anni '90 nei comitati C e C++, standardizzando la formulazione che era incompatibile con una pratica ben consolidata. Ciò significa che il formale non ti aiuta veramente in quest'area, perché qui il formale è di così bassa qualità (è pura politica) che è assolutamente inutilizzabile. –