Qual è l'uso di nomi di caratteri universali negli identificatori in C ++


11

Lo standard C ++ (l'ho notato nel nuovo, ma esisteva già in C ++ 03) specifica i nomi dei caratteri universali, scritti come \uNNNNe \UNNNNNNNNche rappresentano i caratteri con punti di codice unicode NNNN/ NNNNNNNN. Ciò è utile con i letterali di stringa, soprattutto perché sono definiti esplicitamente anche i letterali di stringa UTF-8, UTF-16 e UCS-4. Tuttavia, i letterali dei caratteri universali sono consentiti anche negli identificatori. Qual è la motivazione dietro questo?

La sintassi è ovviamente totalmente illeggibile, gli identificatori possono essere alterati per il linker e non è come se ci fosse una funzione standard per recuperare i simboli per nome comunque. Quindi perché qualcuno dovrebbe effettivamente usare un identificatore con letterali universali di caratteri al suo interno?

Modifica: dal momento che esisteva già in C ++ 03, la domanda aggiuntiva sarebbe se hai effettivamente visto un codice che lo utilizzava?

Risposte:


6

AGGIORNAMENTO - questa risposta, sebbene sembrasse avere un senso per me e per gli altri, risulta in gran parte sbagliata (e sufficientemente sbagliata riguardo all'intenzione, da essere effettivamente semplicemente sbagliata). Poiché (come sottolineato in un commento di AProgrammer) non è consentito utilizzare UCS al di fuori delle costanti di stringa quando lo stesso carattere potrebbe essere rappresentato normalmente nel set di caratteri di base. Quindi, non usarlo per sfuggire alle parole chiave, come nel mio esempio; e non usarlo per rendere gli "identificatori" come 23skiddosfuggendo a2. Potrebbe ancora essere usato per rendere i nomi compatibili con le lingue esterne, immagino, ma solo, sembra, quando quei nomi iniziano con una lettera o un carattere esteso e contengono solo lettere, cifre, sottolineature e caratteri estesi - che sembra troppo restrittivo per supportare adeguatamente tale intento. Quindi deve essere che l'intento principale sia (come nella risposta di AProgrammer) consentire questi caratteri extra negli identificatori e abilitare gli editor di sorgenti in cui questi caratteri sono visualizzati graficamente, pur consentendo al file sorgente di essere in chiaro ASCII.


I programmi C ++ possono chiamare funzioni scritte in altre lingue. È una buona strategia da parte del comitato di standardizzazione garantire che il C ++ sia interoperabile con altre lingue che potrebbero consentire caratteri non alfanumerici o unicode nei nomi delle funzioni, anche se tali lingue non esistono ancora. Lo standard non deve specificare come funzionerà a livello di linker, ecc .; ma è bene disporre di un meccanismo specifico per consentirlo.

Non è necessario guardare al futuro per vedere un uso per questo. Supponiamo di avere una vecchia libreria C con una funzione chiamata catch(o protetta, o mutabile) ... e voglio chiamarla da C ++. E per qualsiasi motivo non posso o non voglio modificare il codice C (A proposito, ho dovuto più di una volta confrontarmi con il vecchio codice C che utilizzava un nome di funzione che era diventato una parola chiave C ++ ...)

Con i nomi UC posso scriverlo in un'intestazione e quindi chiamare 'catch_func ()':

extern "C" {
       int catc\u0068( int a, int b );  // C 'catch()' function
}
inline int catch_func( int a, int b ) { return catc\u0068(a,b); }

Certo è brutto, ma non importa dal momento che è solo in un posto nell'intestazione. Lo stesso approccio potrebbe essere usato per creare stub per chiamare funzioni in altre lingue e funziona anche se i nomi sono parole chiave C ++ o unicode, oppure contengono spazi .o altri segni di punteggiatura incorporati

Varie altre lingue hanno dispositivi che consentono la creazione di identificatori che non seguono il modello generale; per esempio in Verilog, \abcdè un identificatore equivalente a abcd, ma \whilee \23skidooe \44.e2anche identificatori, che hanno bisogno del prefisso barra rovesciata per essere visto come tale. A causa del modo in cui Verilog viene utilizzato, è importante consentire qualsiasi nome, in cui si riferiscono a interfacce esterne.


Caso d'uso interessante. Anche se sospetto (quando possibile) sarebbe meglio scrivere un piccolo file C per tradurre il nome (e quindi utilizzare l'identificatore C ++) e avere C ++ che chiama la funzione C.
Thomas Eding,

1
Non puoi scrivere che per due motivi, il primo UCS al di fuori della stringa e i letterali dei caratteri non possono fare riferimento al carattere nei set di base senza rendere il programma deformato, in secondo luogo se tale clausola non era presente, l'UCS viene gestito nella fase 1 della traduzione e quindi non ci sarebbe differenza nella gestione tra un UCS riferito ad un personaggio nell'insieme base e il personaggio stesso.
AProgrammer

4

Consente a un sistema che consente ai caratteri unicode nell'identificatore di esportare la sorgente in un formato compilabile su qualsiasi compilatore conforme standard. Cioè è un modo per codificare unicode sul set di caratteri di base (più o meno come quoted-stampabile è usato per la posta elettronica, i sistemi che sanno meglio sono in grado di fare un lavoro migliore, altri sistemi funzionano ancora).


2

Qualcuno potrebbe voler creare un identificatore usando un carattere di lingua straniera che non è accessibile sulla tastiera o sul dispositivo di input. In alternativa, l'identificatore può contenere un carattere che non è stampabile usando il carattere o le capacità di output del dispositivo, ma l'IDE vuole mostrare una rappresentazione accurata.


4
Nel primo caso, l'identificatore non sembrerebbe avere quel carattere, quindi il codice sarebbe illeggibile e l'identificatore non conta davvero per la macchina. E per il secondo, la rappresentazione in IDE è un problema completamente separato.
Jan Hudec,

1

C ++ richiede che i caratteri estesi effettivi che compaiono letteralmente nella sorgente si comportino in modo identico ai nomi dei caratteri universali. Consentire nomi di caratteri universali negli identificatori consente ai programmatori di utilizzare caratteri estesi negli identificatori.


Sono supportati i caratteri estesi effettivi, devono comportarsi come corrispondenti caratteri universali. Ma non devono essere supportati.
Jan Hudec,

1
È vero, ma in qualche modo manca il punto, che è che se il comitato vuole specificare che le implementazioni che supportano i caratteri estesi dovrebbero supportare l'uso di quei caratteri negli identificatori, ciò richiede che gli UCN siano autorizzati negli identificatori. Vale a dire gli UCN sono consentiti negli identificatori, non necessariamente perché è così leggibile e tutti amano codificare manualmente i nomi in esadecimali, ma perché se la specifica vuole consentire l'uso di caratteri estesi negli identificatori, lo fa specificando che gli UCN sono consentiti negli identificatori.
bames53,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.