Programmazione Competitiva per sviluppatori .Net (Finale di stagione)

[fve5]

I meno attenti avranno pensato che con C♯ si sarebbe conclusa l’epopea dei nostri due eroi all’interno dell’architettura .Net. Chi invece ha posto più attenzione allo svolgersi della vicenda avrò notato non poche incongruenze: dov’è finito Windows™ Vista? Non c’è un IDE (o meglio un ISE) Microsoft ancora non esplorato?

Grazie al provvidenziale aggiornamento di AtCoder, che solo 5 giorni fa è diventato il primo (almeno a nostra conoscenza) giudice online a supportare Microsoft PowerShell™, possiamo presentare a tutti voi quest’ultimo episodio della serie.

Come anticipato la macchina utilizzata (che per la prima volta è quella di @fve5) gira Windows™ Vista e come ambiente di scriptaggio abbiamo usato Windows™ PowerShell™ ISE.

Normalmente non mi addentrerei nei dettagli di come tutto questo sia stato possibile, ma far funzionare Windows™ Vista è stato talmente più doloroso rispetto a tutti gli altri sistemi operativi finora utilizzati, che è doveroso fare un resoconto, quantomeno breve, del processo.

• Per cominciare, il kernel di Windows™ Vista non supporta la maggior parte delle applicazioni moderne, per tanto è stato necessario estendere il kernel per installare (oltre a Chrome) i driver USB.
• Il kernel esteso (hostato su ximonite.com) era buggato, di conseguenza, per evitare che il sistema BSODasse in momenti randomici, è stato necessario patchare a mano acpi.sys, cambiandone 4 ottetti con un editor esadecimale runnato come amministratore (per chi non fosse abituato ai sistemi Microsoft, è circa l’equivalente di runnare come root).
• Ad ogni boot, il kernel vorrebbe eseguire chkdsk per controllare che il disco sia coerente.
• pagefile.sys (una sorta di swapfile microsoftiano) occupa 24 gigaottetti, obbligandoci a ridimensionare la partizione di Windows™ Vista in fretta.
• Microsoft Visual Studio™ 2005, 2008, 2010 e 2013 non si sono voluti installare (né col kernel esteso né senza), obbligandoci a ripiegare su 8.1 per l’episodio in C♯.

Il problema di oggi è: A - i i’s. Si tratta di un problema piuttosto semplice, ma considerato che esiste un solo contest tra cui scegliere i problemi non avevamo molte alternative.

Elenchiamo ora i vantaggi di usare PowerShell (in particolare PowerShell 2, la versione utilizzata da noi):

• Tutta l’architettura .Net è accessibile mediante la sintassi [Classe]::Membro. Unica eccezione il metodo new, che verrà introdotto solo in versioni più nuove di PowerShell. Il Cmdlet chiamato New-Object può sopperire a questa mancanza.
• Gli operatori di comparazione sono i più chiari che si siano mai visti: qualcuno potrà mai avere dei dubbi su cosa facciano -lt, -eq o -ne?
• Le variabili sono tutte prefixate con il dollaro ($), questo permette di capire con uno sguardo che cosa è una variabile e che cosa no.
• I valori di ritorno non salvati in una variabile sono stampati su stdout. Per evitare questo comportamento, si può castare a void usando la sintassi [void].
• Come sempre quando di parla di .Net, le stringhe sono immutabili. Ma l’architettura viene in nostro soccorso implementando System.Text.StringBuilder.

Concludiamo in bellezza con l’ultimo codice della serie:

$N = [System.Int32]::Parse([System.Console]::ReadLine())
$sb = New-Object System.Text.StringBuilder

for ($i = 1; $i -le $N - 2; $i++) {
    [void]$sb.Append($i.ToString() + " ")
}
[void]$sb.Append($N.ToString() + " ")
[void]$sb.Append(($N - 1).ToString() + " ")

for ($i = $N; $i -gt 1; $i -= 2) {
    for ($_ = 0; $_ -lt ($i - 2); $_++) {
        [void]$sb.Append($i.ToString() + " ")
        [void]$sb.Append(($i - 1).ToString() + " ")
    }
    [void]$sb.Append($i.ToString() + " ")
}

[System.Console]::WriteLine($sb.ToString())