2 - Amiga Magazine Online

sarli alla propria superclasse. In questo modo la classe si
comporta come se possedesse contemporaneamente anche
tutti i metodi delle sue superclassi fittizie.
Una osservazione interessante è che questo sistema per-
mette di supportare automaticamente anche i metodi che
verranno definiti in versioni future delle superclassi, senza
alcun bisogno di modificare o ricompilare la classe stessa.
L'unico requisito indispensabile è che i valori numerici as-
sociati ai metodi siano sempre distinti tra due diverse clas-
si. Questa caratteristica è garantita per tutte le classi built-in
di lntuition, e dovrebbe esserlo anche per quelle progettate
da terze parti. I1 condizionale è d'obbligo perché, per evita-
re conflitti di questo tipo, la Commodore aveva stabilito
che gli sviluppatori di nuove classi pubbliche richiedessero
al gruppo di West Chester l'assegnazione dei valori da usa-
re per i nuovi metodi e per gli attributi. Un sistema simile
era stato adottato dalla Electronic Arts per l'assegnazione
dei chunk ID per i file IFE. Purtroppo il fallimento di Com-
modore e il conseguente smantellamento del laboratorio ri-
cerca ha costretto gli sviluppatori esterni a "inventare" dei
numeri, facendo molta attenzione per evitare conflitti con
tutte le classi già esistenti. Comunque, per quante precau-
zioni si prendano, la mancanza di centralizzazione non
può garantire l'assenza totale di conflitti di questo tipo.
A cosa può servire un oggetto con due o più superclassi?
Un esempio banale è un gadget simile al LISTVIEW-KIND
della GadTools, che riporta in uno string gadget la selezio-
ne corrente. Anziché creare due oggetti distinti e intercon-
netterli manualmente ogni volta, può risultare più comodo
creare una classe "strlistviewgclass" che ne incapsuli la ge-
stione. Una classe di questo tipo dovrebbe implementare
tutti i metodi e gli attributi delle classi "listviewgclass" e
"strgclass".
Tecniche di debug
I1 debug di una classe Boopsi può essere pii1 difficoltoso
rispetto a un programma qualsiasi. Le tecniche classiche di
debug sono spesso inefficaci, perciò è necessario usare
qualche accorgimento che permetta di trovare più facil-
mente i bug.
Innanzitutto, dal momento che alcuni metodi dei gadget
vengono chiamati sotto il contesto dell'input.device, usan-
do un normale debugger non è possibile bloccarne l'esecu-
zione mediante l'inserimento dei breakpoint e tanto meno
eseguire il codice un'istnizione per volta. I1 motivo è sem-
plice: se 1'input.device si blocca, si blocca anche I'interfac-
cia utente e non è più possibile controllare il debugger.
La soluzione più semplice per questo problema consiste
nell'usare un cross-debugger su un secondo computer che
comunica con il primo tramite un cavo null-modem o un
altro tipo collegamento bidirezionale. I1 cprx del SAS/C è
probabilmente l'unica scelta possibile, sebbene abbia la
tendenza a inchiodarsi quasi più spesso dei programmi che
pretende di debuggare. Enforcer, Mungwall e gli altri t001
di sviluppo canonici possono essere di aiuto soltanto se il
loro output viene inviato a un terminale remoto, sempre
via seriale.
Non è neppure possibile scrivere informazioni di debug
usando le normali f~~nzioni di I/O della dos.library, e tantomeno
quelle della libreria standard del C, perché
l'input.device è un task e non un processo, quindi non
può usare funzioni della dos.library. Di nuovo, un terrninale
remoto è la soluzione migliore.
La libreria linkabile debug.lib contiene delle funzioni come
kprintf( ), che permettono di ottenere facilmente un output
formattato sulla seriale interna presente in tutti i modelli di
Amiga. Se non si dispone di un computer da usare come
terminale, è sempre possibile utilizzare la porta parallela
linkando con la ddebug.lib [con due "d"]. Una comune
stampante Centronics, collegata alla porta parallela, è adat-
ta allo scopo.
I1 file "Debug.hn, che trovate nei sorgenti che accompagna-
no questo articolo, contiene qualche macro di uso genera-
le. Durante la scrittura dei metodi conviene inserire il mag-
gior numero possibile di controlli di validità sui parametri
usando le inacro ASSERT( ) e CHECK-PTR( ). Queste ma-
ero producono un output soltanto quando non viene sod-
disfatta la condizione specificata oppure quando un punta-
tore non è valido. i controlli vengono completamente eli-
minati quando si compila senza opzioni di debug.
Una causa molto comune di problemi con gli oggetti Boo-
psi è l'overflow dello stack. I1 task input.device ha uno
stack di soli 4 kb, che bastano a malapena per far girare un
complesso network di oggetti che comunicano tra loro
scambiandosi messaggi costruiti sullo stack. All'interno del
dispatcher di un oggetto Boopsi evitate di dichiarare varia-
bili automatiche di grandi dimensioni e di chiamare funzio-
ni in modo ricorsivo. In caso di bisogno, è possibile esten-
dere lo stack usando StackSwap( ). A
Bibliografia
- Amiga ROM Kmel Refmnce Manual: Librarie5 (3rd editioni
- 3.1 Native Dewloper Toolkzt
- Am&a Beyeloper CB 1. I
- Boop.5i Refivence: htp://~~2c~.w..utah.edzr/-stucWhmp.ri.html