Embedded_54

72 / 86

EMBEDDED 54 • NOVEMBRE • 2014 72
SOFTWARE
C++
Limitare (o evitare) l’uso dell’allocazione dinamica
della memoria. L’utilizzo della memoria dinamica nei
sistemi safety-critical è di norma fortemente soggetto a
restrizioni, e spesso sconsigliato. Il fondamento logico di
questa raccomandazione è che usando l’allocazione dina-
mica della memoria si aumenta la probabilità che il siste-
ma embedded possa incorrere in bug, e tenda ad assume-
re un comportamento non deterministico e impredicibile,
con impatti sulle performance. L’allocazione statica della
memoria consente invece di ottenere un pieno determini-
smo ed evitare bug di tal genere.
Sintassi per le istruzioni condizionali. Quando si uti-
lizzano le istruzioni if, else, while, for, do e switch, occor-
re evitare costrutti che possono portare a scrivere codice
non valido. Dopo ogni istruzione, ciascun blocco deve es-
sere racchiuso tra parentesi graffe, anche se è vuoto o
contiene solo una riga. Ad esempio:
Fonte PQRA
Scrivere codice conforme allo standard C++ ISO
2011. Una raccomandazione generale (implementation
compliance) riportata nello standard di codifica HIC++
V4.0 spiega che l’attuale versione del linguaggio C++ è
quella definita dallo standard internazionale ISO/IEC
14882:2011.
L’osservanza di questo criterio è fondamentale, perché sul
mercato esistono compilatori che spesso forniscono fun-
zionalità che oltrepassano quelle definite nello standard
sopra citato, e un uso sregolato di tali caratteristiche fini-
rebbe per ostacolare la portabilità del codice.
Adottare tool di automazione della verifica della con-
formità del codice. Sul mercato esistono vari prodotti e
strumenti software in grado di automatizzare l’analisi del
codice sorgente, per controllarne e verificarne la confor-
mità secondo le regole definite dalle diverse versioni degli
standard di codifica, come ad esempio MISRA-C++ o JSF
AV C++.
Evitare il codice implementation-defined, o con com-
portamento non definito. Un altro criterio essenziale da
rispettare è non indirizzarsi verso lo sviluppo di costrutti
sintattici e codice, cosiddetto, ‘implementation-defined’
(definito dall’implementazione), o con un comportamento
‘unspecified’ (imprecisato) o ‘undefined’ (non definito).
Infatti, un codice di questo tipo non è portabile e viene
bandito dagli standard di codifica. A differenza di un co-
dice conforme allo standard, e compilabile da qualunque
compiler fedele agli standard stessi, un costrutto del lin-
guaggio C++, catalogato come implementation-defined,
potrà essere implementato a seconda del compilatore in
modi differenti, manifestando comportamenti definiti e
documentati, con eventuale specifica di quali sono quelli
consentiti.
Quando invece il codice è ‘unspecified’, significa che il
comportamento dell’implementazione non è necessaria-
mente documentato.
Infine, il comportamento ‘undefined’ del codice indica che
gli standard non pongono alcun requisito da soddisfare
per l’implementazione: quindi il compilatore potrebbe
fallire durante la compilazione di porzioni di codice, an-
dare in crash, produrre in modo silente risultati scorretti
o, anche, eseguire in maniera fortuita proprio ciò che lo
sviluppatore intendeva ottenere.
Naturalmente, in questi pochi punti abbiamo solo eviden-
ziato alcuni aspetti rilevanti che riguardano le migliori
pratiche di codifica del codice. Per una trattazione più ap-
profondita e completa è possibile consultare le specifiche
linee guida e documenti (ad esempio HIC++) - in alcuni
casi scaricabili liberamente online – che raccolgono tutte
le principali regole e best practice di programmazione per
il linguaggio C++.
Nota
*La prima parte è stata pubblicata sul n. 52-giugno 2014
con il titolo “Software embedded, le linee guida per un co-
dice di qualità”
Online su
emb/52/#64