Corso C# 8 (da zero) ITA Win/Mac/Linux – #05: tipo cha… — Transcript

Un paio di informazioni di servizio prima di continuare. La prima, mi avevate chiesto se non era possibile attivare gli stessi analizzatori di codice già visti per Visual Studio anche per il Visual Studio Code.

Beh, la risposta è sì, ce l'avete già nel plugin che vi ho fatto installare l'altra volta, e cioè il C# for Visual Studio, questo, Code, basato su OmniSharp.

È già quest'ultimo che include quegli analizzatori di codice.

Ma non solo attivati, al limite, e come si fa? Qui nelle estensioni, andate sulla rotellina in corrispondenza del plugin, Extension Settings.

E andate ad assicurarvi che ci sia la spunta vicino alla voce, questa qua, OmniSharp, Enable Roslyn, che è il compilatore utilizzato da Visual Studio.

Non è attivo di default perché è in stato ancora parzialmente sperimentale, ma secondo me funziona già abbastanza bene.

Condivido sempre prendendo dai vostri post, ringraziamo Paolo Russo che ci segnala un paio di estensioni piuttosto potenti per l'analisi e scrittura del codice.

Una è questo Visual Assist della Whole Tomato.

E questo Supercharger. Io non li ho provati personalmente, quindi ci stiamo fidando di Paolo Russo.

Verificate magari prima che non ci siano incompatibilità nelle descrizioni e cose di questo tipo.

Sono entrambi estensioni per Visual Studio, poi non so se vi sia il corrispondente per il Visual Studio Code. Entriamo allora nel vivo di questa puntata.

In quella precedente abbiamo introdotto per i tipi principali, char, string, numeri interi e floating point e booleani, le costanti letterali.

Che sono il modo più semplice di introdurre valori di quei tipi all'interno del codice. Da oggi riprenderemo uno dopo l'altro tutti questi tipi in dettaglio.

E preferisco iniziare un nuovo progetto, sempre .NET Core, che chiamiamo tipo char, tipo_char_video5.

Char, così piccolo e così ricco di particolari. Ad esempio, una cosa che lascia un dubbio spesso ai neofiti.

Ma perché ce n'è bisogno? Abbiamo visto che esiste già la possibilità di introdurre delle stringhe in questo modo, e questo allora un carattere.

Perché c'è bisogno di un tipo specifico per indicare quella che apparentemente è la stessa cosa?

E cioè questo. Le stringhe, vi ricordo, sono delimitate dalle virgolette, i char, i singoli caratteri, invece dagli apici.

Per una motivazione completa dovrei introdurre tecnicismi che sono troppo per il livello, almeno quello iniziale sicuramente della playlist.

Per cui dovrete accontentarvi di un'approssimazione, di una spiegazione intuitiva. Le stringhe, che possono contenere anche migliaia di caratteri, sono molto più flessibili nella programmazione dei semplici char.

Tranne molto, vedremo infatti che dispongono di comandi per concatenarsi tra di loro, a formare stringhe più lunghe, potremmo sapere di quanti caratteri sono formate.

Potremmo accedere ai singoli caratteri se necessario, avremo comandi per eliminare gli spazi in testa, in coda, inutili, trasformarli in maiuscolo, in minuscolo e tante altre cose.

Questa flessibilità, è intuitivo, comporta una complessità interna della classe string piuttosto elevata. La classe char e i suoi oggetti letterali sono più snelli e quindi fanno pagare un prezzo minore per servizi di cui non si ha bisogno.

Io sono convinto che sapere, almeno a livello approssimativo, come ciascun tipo di dato viene rappresentato internamente nella memoria del PC, aiuta molto a capire poi quello che si può fare e al supporto che ci si può aspettare lavorando con ciascuno dei tipi disponibili.

Senza questi dettagli che sto per introdurre, ad esempio, un programmatore proveniente dal mondo C C++ potrebbe non cogliere o addirittura non capire il perché il tipo char in C# occupa 16 bit.

Mentre da sempre c'è questa equazione, che poi a volte è fallata, in C e C++, char uguale sempre un byte, 8 bit.

È fallata perché su alcune piattaforme hardware abbiamo che il byte non è di 8 bit, ma per dire di 7 o di 4.

Come penso molti di voi sapranno, la prima tabella di codifica dei caratteri, una delle più diffuse, quantomeno, è l'ASCII e usava soltanto 7 bit su 8 per motivi che adesso qui non sto ad approfondire.

In tempi piuttosto brevi, però, l'ottavo bit fu utilizzato per estendere la capacità di rappresentazione di questa tabella fino a 256 simboli, e ciascuno di questi, quindi, ha bisogno solo di un byte per essere codificato.

Ma l'esplosione dell'informatica ha reso insufficiente anche questo schema. Siamo maturi per l'introduzione di tabelle ancora più grandi.

L'Unicode, nella sua prima versione, prevedeva la possibilità di differenziare tra 65.536 simboli, siamo intorno al 1995, coevi con la nascita di Windows.

Ecco spiegato l'arcano. I progettisti, gli architetti software di Windows, scelsero quello che al momento sembrava lo schema più furbo di rappresentare internamente la RAM per Windows, intendo, i caratteri.

Uno schema 16 bit che ricalcava i 16 bit dell'Unicode di quei tempi. Ed è così anche oggi.

Windows internamente rappresenta i simboli del nostro alfabeto con una codifica 16 bit. Questa codifica ha un nome internazionalmente noto e internazionalmente adottato dagli organismi internazionali.

Eh, per fortuna non ne sta usando uno tutto suo.

Lo schema è chiamato codifica UTF-16.

Infatti, quando si sta per introdurre, ne parleremo tra poco, una variabile, cioè un contenitore per valori di tipo char, con C#, il pop-up d'aiuto che otteniamo come descrizione di quel tipo di identificatore dice System.Char.

E sotto, la parte bianca è importante.

Rappresenta un carattere come un code unit UTF-16.

Occhio però, questo non vuol dire che tutti i caratteri saranno sempre e solo rappresentati utilizzando 16 bit.

Perché la questione, la faccenda è un po' più complicata di quello che sembra.

Vediamo perché. Premesso che poi a tutti gli effetti ce ne fregheremo e lavoreremo semplicemente come se fosse sempre così.

L'Unicode si è ulteriormente espanso, la tabella è diventata mostruosa, è suddivisa in plan, sono 17 plan, e vedete lì sulla sinistra, impilati uno sotto l'altro.

Ciascuno contiene 65.536 caratteri.

In tutto, fate i conti, fanno 1.114.112 simboli.

Finalmente tutti gli alfabeti del mondo, delle lingue presenti, ma anche passate, lingue antiche.

Ah, qui neanche 16 bit bastano più, non tanti di più, eh, a livello teorico, ne basterebbero 21, 20 e rotti per chi mastica un po' di binario.

Il che però porta a 24, perché non si può andare se non a multipli di 8, 3 byte. Questo, se adottassimo, sarebbe molto sconveniente, ora vi dico semplicemente anche il perché.

Una codifica a lunghezza fissa, cioè, immaginate di poter indicare uno qualunque di questi, un milione e rotti di simboli, per cui in RAM, ma anche su disco, utilizzare anche per le vecchie nostre letterine della tabella ASCII, 3 byte.

Una tragedia, perché d'un botto avremmo triplicato lo spazio occupato sui dischi. E tragedia della tragedia, d'un botto aver reso incompatibili tutti gli applicativi con gli schemi di salvataggio dei dati.

Sono stati allora inventati degli ingegnosi sistemi di codifica che alla base hanno ancora l'Unicode, ma che non l'utilizzo permettono un bel risparmio.

I due più diffusi sono l'UTF-8 e l'UTF-16.

Sì, quello visto prima in Visual Studio.

L'idea di base è quella di utilizzare meno byte per i simboli più comuni. Ad esempio, l'UTF-8 utilizza un solo byte per tutti quei simboli che già erano presenti nella tabella ASCII.

Molto conveniente e non rompe neppure la compatibilità con i vecchi software, provate a pensare se d'un botto tutti i software che utilizzavano un file di testo, passando all'Unicode, dovessero essere riscritti per adattarsi.

Eh, costosissimo.

Non sorprende allora che l'UTF-8, per quanto riguarda la memorizzazione su disco e anche lo scambio delle pagine web, eh, guardate nell'intestazione HTML, spesso c'è quel UTF-8.

Sia stato universalmente, dicevo, adottato.

Per i simboli un po' meno comuni si utilizzano due byte con UTF-8, per quelli ancora meno comuni tre, per quelli più rari quattro byte.

Uno in più, quindi, di quelli teoricamente necessari, ma è il prezzo che si paga per avere la codifica variabile, perché alcuni bit, quelli che avete lì in rosso, servono a far capire a chi legge il documento se è iniziata una sequenza da un byte, due byte o tre byte.

Poi c'è l'UTF-16, la scelta qua è diversa, di usare fin da subito, come primo step, due byte, e quindi avere da subito la possibilità di agganciare 65.536 simboli.

Ma a volte potrebbero servirne di più.

E allora ecco che andremo ad aggiungere altri 16 bit.

Per cui una codifica UTF-16 può utilizzare o due byte, quando è sufficiente, o quattro.

UTF-8 e UTF-16 coesistono, hanno vantaggi e svantaggi.

E come dicevo, il .NET adotta come formato interno per il tipo char, la classe char, proprio l'UTF-16. E tornando a Visual Studio, ci accorgiamo di questa non ingombrante presenza dell'UTF-16.

Oltre che in quei piccoli box descrittivi, dal fatto che, se serve, abbiamo davvero la possibilità di inserire nel nostro codice codifiche UTF-16.

Ovvio che non lo facciamo per le normali lettere dell'alfabeto, punteggiatura, sarebbe ridicolo. Lo faremmo per simboli, diciamo, speciali, non so, anche le smile, le faccine e altri simboli grafici.

Però, lavorando a console, come stiamo facendo adesso, non è possibile sperimentare come potremmo fare invece col JavaScript in un browser, perché le capacità di rappresentazione in output della console sono abbastanza limitate.

Per cui si va a lavorare sostanzialmente con la vecchia tabella ASCII, lavorando a console. Sì, qualcosa di più potremmo fare passando per l'UTF-8, impostando la console in modalità UTF-8 e utilizzando quei codici.

Però, insomma, sarebbe esagerato, fermiamoci pure qui.

Comunque, questa è la codifica della lettera A maiuscola.

Dovete leggere il tutto in esadecimale, la U sta per UTF Unicode.

41 è 65, che è il codice ASCII della vecchia tabella della A maiuscola.

Eccola qui. Ora, come dicevo, ci dimentichiamo di questa cosa.

E vi propongo una piccola situazione banale, ma che ci mette in crisi, perché ci fa capire che ci mancano gli strumenti per poter procedere.

E ce ne occuperemo, ovviamente, nel prossimo video.

Eccoci qua. Immaginiamo che l'utente abbia comandato in qualche modo la cancellazione di un dato.

Un record di un cliente, quello che volete.

E noi, per sicurezza, si voglia chiedere conferma.

Quindi possiamo tranquillamente stampare il titolo di un menù, poi le due opzioni che diamo all'utente.

Premi la C se vuoi confermare e premi A se vuoi annullare.

E poi, come conferma, hai scelto, e vabbè, poi procedere.

Eh, già, ma dov'è che lo mettiamo questo tasto?

Non possiamo saperlo ora quello che sceglierà, magari tra un mese, un qualunque utente.

Scopriamo di aver bisogno, al di là di queste costanti letterali, di un qualche contenitore per depositarci dentro valori del tipo che ci serve.

E poter recuperare gli stessi valori per i calcoli successivi.

Stiamo chiedendo a gran voce quel che in informatica, nella programmazione in particolare, prende il nome di variabile.

A risentirci.