Costrutto do-while con variabile flag

[Sjuanez]

Allora la stessa sensazione l'avrai ogni semestre

Hai già visto i corsi di Harvard e MIT online? sono gratuiti e ben documentati.

[TardoFreak]

No, sto frequentando l'università e, a dire il vero, ne ho più che a sufficienza di quello che mi fanno studiare.

[boiler]

Rientro nel discorso e dico anch'io la mia.

Oltre agli usi descritti, una flag può essere modificata esternamente al loop, come nel caso di un memory-mapped I/O o di qualcosa che viene sovrascritto in un interrupt. In tal caso ricordarsi di dichiararla come volatile.

La condizione logica (quella nelle parentesi tonde) deve ritornare qualcosa che dipende dal linguaggio che stai usando. In C può essere un int qualsiasi. 0 viene interpretato come false, tutto il resto come true.

Sulla diatriba tra l'usare una variabile che viene testata o mettere i test direttamente nella condizione di while: bisogna distinguere due situazioni.
a) il test è un puro test, per esempio isBlonde(r)
b) il test modifica dei dati, per esempio getUartHandler(&UART0, uartID, baud, parity)

Nel caso a), si può fare quello che piace.
Nel caso b) bisogna essere coscienti che alla prima funzione che ritorna false, tutte le susseguenti non vengono eseguite. Per ogni programmatore è abbastanza ovvio, ma è una fonte di errori e non per niente è deprecato dallo standard MISRA (della quale praticabilità si può pensare quello che si vuole, ma malaccio non è).

La soluzione veramente elegante è l'uso di enums, in modo che il metodo getUartHandler non ritorni un semplice true o false, ma uno dei seguenti valori:
UART_ERROR_NOERROR
UART_ERROR_NON_EXISTING_ID
UART_ERROR_ALREADY_INSTANTIATED
...

Il codice diventa così

Codice: Seleziona tutto

uart_instantiation = getUartHandler(&hUart0, uartID, baud, parity);
if (uart_instantiation != UART_ERROR_NOERROR)
   {
      // error handling
   }
// use the uart handler


Questa è tra l'altro l'unica condizione che funziona con un linguaggio veramente strongly typed, come C#.

Codice: Seleziona tutto

int a = 1;
if (a == 1)
   Console.WriteLine("Explicit");
if (a)      // <-- ERROR
   Console.WriteLine("Implicit");


Qui "Explicit" viene stampato, "Implicit" no. L'argomento di if (così come quello di while) deve essere un bool e l'implicit cast non viene introdotto dal compiler come in C++.

Boiler

[WALTERmwp]

Tollerate se non aderisco direttamente all'oggetto del thread ma intendo aggiungere un parere al discorso che si è sviluppato, anche se può apparire scontato il seguito.
Mi riferisco alla presunta o reale efficienza di un codice, scritto in modo più elegante, o criptico, piuttosto che l'adozione di un approccio più diretto e lineare.

Non è per dare "un colpo al cerchio e uno alla botte" ma, oltre alle proprie sensibilità e competenze, credo che certe scelte debbano o possano essere modulate dal contesto, inteso come ambito applicativo.

Questa certo è una ragione

(...) che il fatto di lavorare in grandi team, renda più vantaggioso puntare sulla leggibilità e interpretazione immediata del codice (...)

credo condivisibile, per la quale sia meglio rendere più leggibile il codice, così come chi lavora in completa autonomia può puntare a performance che costringerebbero qualcun altro a più d'una "passata" nel caso si trovasse a seguire i passaggi di quel software.

Però, anche quando il codice lo scrivi, "egoisticamente" pensando solo a te, benché sarà certamente destinato alla visione di altri, per più motivi ivi compresi quelli della manutenzione, ti confronti con delle contraddizioni, solo tue.

Nell'ambito dell'automazione sono men che rari i casi nei quali, dopo avere parametrizzato funzioni e ottimizzato i passaggi dell'elaborazione, in fase di avviamento iniziano i "problemi".
Quando i comportamenti delle macchine cominciano ad "allontanarsi" dalle tue aspettative, intanto che prendi coscienza e tra te e te cerchi di resistere alla tentazione d'attribuire le responsabilità a qualche poltergeist, siccome non riesci a seguire gli eventi ... inizi a "smontare" quello che hai costruito.
Ti trovi allora nella condizione di semplificare quello che ti aveva dato soddisfazione realizzare perché ora non ti consente d'indagare bene sul problema.

Può essere per il fatto, appunto, di avere condensato "troppo" delle elaborazioni oppure per aver scelto di parametrizzare privandocisi quindi della visibilità sui risultati intermedi della funzione.
Allora, tra un "ma perché l'ho fatto ?" (te lo chiedi ma lo sai benissimo ...) e un "ma chi me lo ha fatto fare ?" (anche questo la sai benissimo, ma te lo chiedi ugualmente ... ) cominci a duplicare e poi a far "esplodere" quelle condensazioni.

Ovvio che qui gioca un ruolo importante l'abilità individuale e chi è molto bravo non incontra inconvenienti simili ma per la maggior parte di noi comuni mortali fanno parte di esperienze vissute.
Da queste poi bisogna trarre insegnamento, ma questo è un altro discorso ...

Saluti

[Sjuanez]

Bene, Walter, questo mi porta proprio ad una riflessione che sto facendo da un po di tempo. Quindi grazie.

Ho iniziato a dare un'occhiata a Python, che è un linguaggio il cui stile porta ad essere molto, ma molto sintetici.

E' vero che ci sono ragazzi che ormai lo "parlano" naturalmente e sono sicuramente ottimi programmatori, ma io ancora faccio qualche sudata difronte a ricorsività non commentate o funzioni di funzioni di funzioni. Ereditarietà non chiare...

Diciamo che faccio fatica a seguire tutto a mente e se fosse scritto in maniera più rilassata lo leggerei come un fumetto! Mancando come al solito la giusta documentazione

Però credo sia un mio difetto di prontezza o acume, in quanto chi fa queste cose tutti i giorni ha sviluppato ormai, giustamente, un uso dei linguaggi che va ben oltre quello che io padroneggio.

Stando alla metafora della lingua, parlo ad un livello da scuola media e lì fuori ci sono un sacco di fluenti!!!

Speriamo solo che il tempo e l'impegno portino qualche miglioramento!

[boiler]

Ho iniziato a dare un'occhiata a Python, che è un linguaggio il cui stile porta ad essere molto, ma molto sintetici. pianto e stridore di denti.

[simo85]

Io sono sempre fedele al C, (C++ ogni tanto) e Assembly.

Sarò all'antica e di basso livello, ma non tradiscono mai.

[WALTERmwp]

(...) Quindi grazie. (...)

... prego, si figuri.

Saluti

[Sjuanez]

Io a parte le pietre miliari della scuola (COBOL, Pascal, GW Basic), vidi un pochino di assembler per curiosità, ma non ci ho mai scritto nulla.

C, C++, Java, visual basic li vidi tutti per divertimento, ma molto poco approfonditamente.

PHP è quello che conosco un po meglio, ma non è che sia una cima. JavaScript forse fa storia a se, però diverte.

Python me lo sono ritrovato seguendo i corsi del MIT ed è divertente, e prima che a boiler stridessero i denti , mi sembrava più sintetico degli altri (già che mi togli le parentesi, un po mi disoriento).

Forse è cambiato lo stile di insegnamento, forse sono rimasto indietro io. Che vi devo dire, ai miei tempi non si faceva a gara a chi riusciva a far stare tutto su una riga.

Penso che Walter si riferisse pure a questo aspetto. Non c'è niente di male, ma io ci soffro ad interpretare codice scritto così da altri. Ripeto, probabilmente è che non sono allenato/istruito a farlo.

[boiler]

Io sono sempre fedele al C, (C++ ogni tanto) e Assembly.

In ambiente "alto" (applicazioni, non microcontroller) li trovo un po' anacronistici.
C# ha un paio di pochi punti dolenti, ma incredibilmente molti punti a suo favore.

Boiler