Quando la ricerca è caso; quando il caso diviene ricerca.
A volte mi rendo conto che è colpa mia: non può essere altro che colpa mia.
Mi rendo conto, dicevo, che mi inerpico sempre nei percorsi più complessi: a volte per necessità, a volte per puro spirito d’avventura.
I miei folli progetti di sviluppo (per fortuna non nell’ambito professionale) hanno una ciclo di vita lunghissimo (dalla progettazione al rilascio); in verità tipicamente hanno un tempo infinito, ossia non vedono quasi mai la fase di rilascio. E sia.
Non per questo i miei progetti non sono “vitali”: quasi vivono di vita propria.
Nascono, muoiono, risorgono, si modificano, mutano, si trasformano, si rinnegano e si rinnovano.
Insomma, un gran casino !
Però, di contro, passano le stagioni, gli anni, e con questi arrivano affascinazioni e finanche innamoramento per tecniche o tecnologie, idee e promesse: e a confusione si aggiunge quindi confusione.
Non di rado infatti progetti nati con un linguaggio di programmazione sono proseguiti con un altro, ne hanno assimilato, esteso, inglobato parti. In aggiunta a ciò accade anche che progetti destinati ad un certo sistema operativo sono stati manipolati, trasformati, portati ad altri sistemi, passando per cambio di linguaggi e interfacce, da testo a grafica, da C a ObjC, passando per C++ e linguaggi a corollario (leggi uso massiccio di yacc/lex). Entropia o indecisione?
E’ per questa frenesia informatica dunque che nell’ennesimo capovolgimento di progetto ho pensato di sperimentare ibridazioni tra C++ e ObjC; non certo per un colpo di calore o altra infermità mentale: in realtà “semplicemente” come tentativo estremo di migrare un progetto già in C++ verso ObjC, riutilizzando il più possibile fino a completamento della migrazione.
E ovviamente, per non farmi mancare nulla, ho voluto vedere come poterlo fare anche al di fuori del “caro vecchio” XCode ove avreio deciso (dubbi?) di collocare il progetto destinato al rilascio (quando?), ovvero su una piattaforma Linux con gcc-obj e FoundationLib istallati.
Questo in piena filosofia iLinux.
I primi passi nell’ibridazione C++ – ObjC, ovvero ObjC++, li ho quindi compiuti in ambiente Linux, su distribuzione Fedora 7 (kernel 2.6.23.17-88.fc7).
Istallato il compilatore (gcc-objc-4.1.2-27.fc7), Foundation (libFoundation-devel-1.1.3-10.fc6) e qualche dipendenza, mi rendo conto di una prima stranezza: yum (che ho usato per l’istallazione) istalla la medesima versione di Foundation sia su FC7 che FC8, con un tag che si riferisce a FC6. Va bene la stabilità del software, ma questo appare troppo !!!
E ripenso che è già un *miracolo* che in distribuzioni “standard” siano presenti componenti software afferenti in qualche misura al progetto GNUStep, tanto caro a noi di iLinux.
Quindi mi faccio coraggio e proseguo l’esperienza.
Preparo un sorgente sperimentale per togliermi qualche dubbio sulla conformità e compatibilità del compilatore e delle librerie alla documentata ibridazione di C++ e ObjC, ivi comprese la gestione eccezioni C++ e corollari vari.
Ecco il sorgente:
/*
* esempio.mm
*
*
*/
#import <objc/objc.h>
#import <objc/Object.h>
#import <Foundation/Foundation.h>
/**
* Una classe C++
*
*/
class A
{
public:
A()
{
printf("Class A created\n");
};
void error( void)
{
throw int();
};
};
/**
* Una "classe" ObjC
*
*/
@interface MyClass : Object
{
}
- (void) sayHello;
@end
/**
* Il programma
*/
int main()
{
id anObject; // untyped
A * aptr;// typed/dynamic
A clazz;// typed/static class C++
anObject = [MyClass alloc];// Una classe ObjC
aptr = new A();// Una class C++ dinamica
// Gestione eccezioni C++
try
{
aptr.error();
clazz.error();
}
catch( ... )
{
printf("Trap eccezione\n");
}
[ anObject sayHello ];
return 0;
}
/**
* Implementazione classe ObjC
*/
@implementation MyClass : Object
{
}
- (void) sayHello
{
printf("Hello, World!\n");
}
@end
Provo dunque a compilare questo intreccio di tecnologie:
$ g++ -lobjc -lFoundation esempio.mm
Poteva andare bene? Ovviamente no! Invece che il prompt mi ritrovo 3 righe molto irritanti, che segnalano un errore di compilazione:
/usr/include/real_exception_file.h:68: error: expected identifier before ‘class’ /usr/include/real_exception_file.h:68: error: expected `:' before ‘;’ token /usr/include/real_exception_file.h:68: error: expected identifier before ‘;’ token
L’errore è inequivocabilmente collocato in un file esterno alla mia creazione farneticante: infatti è un file distribuito con il pacchetto “libFoundation-devel”. Ma questo non mi è di sollievo.
Un ostacolo imprevedibile si pone infatti davanti al mio obiettivo di integrazione; la presunta stabilità di libFoundation è crollata: ha un bug !!! Accidenti a quella postilla “.fc6” nel numero di versione!
Mi calmo: dopo tutto solo un “pazzo”, perso nei fumi di una farneticante ibridazione linguistica, poteva trovare un bug simile.
La riga 68 del file “/usr/include/real_exception_file.h” parla chiaro: è l’ibridazione il vero problema.
L’argomento di un metodo di interfaccia ObjC (NSException) ivi definita utilizza una parola che è chiave per il solo C++: e io che vado ad utilizzare? Il C++.
E’ evidente che in realtà il 99% del codice ObjC non usa ibridazioni, o al più usa del semplice C: dunque questo errore è destinato ad evidenziarsi solo a pochi “eletti”, o forse “sfigati”. E io come al solito in questa ultima categoria mi ci trovo assai spesso, isolato in percorsi tortuosi ed intricati: questa volta però, per fortuna, almeno non in un vicolo cieco.
Imbraccio il mio editor preferito (VIM) e altero rozzamente la riga 68 cambiando l’identificatore incriminato in “aClass”. Non contento mi costruisco anche un file per eseguire una patch, visto che il problema mi si riproporrebbe su qualsiasi FC6,7,8 ove dovessi trovarmi a lavorare in ObjC.
Per rendere la scoperta più “ufficiale” mi sono curato di segnalare la presenza dell’errore su http://bugzilla.redhat.com: Bug 467165 (2008-10-16 03:04:57 EDT). Ora ho anche la coscienza a posto.
Servirà a qualcuno la soluzione di questo bug?
Resta comunque quella sensazione di solitudine nel mio viaggio attraverso intricati percorsi di sviluppo software.