Newsgroup: it.comp.lang.c
Titolo: limiti del preprocessore

Ciao a tutti,
più per divertimento che per reale necessità sto scrivendo il codice
necessario per le operazioni matriciali utilizzando  il preprocessore.
Ad esempio per moltiplicare la matrice A per la matrice B ( entrambe
matrici quadrate 2X2) e mettere il risultato in c verrei utilizzare la
macro:
[...]
PROD(A,B,C,2);
[...]
per ottenere dal preprocessore uno sviluppo simile a questo:
[...]
c[0,0]=A[0,0]*B[0,0]+A[0,1]*B[1,0];
c[0,1]=A[0,0]*B[0,1]+A[0,1]*B[1,1];
c[1,0]=A[1,0]*B[0,0]+A[1,1]*B[1,0];
c[1,1]=A[1,0]*B[0,1]+A[1,1]*B[1,1];
[...]
Potrei scrivere la macro utilizzando direttamente il codice sopra, ma
in sarei vincolato alle sole matrici quadrate 2X2, e poi utilizzare il
preprocessore è un interessante esercizio.
Ho letto su qualche sito che la ricorsione è volutamente impedita dal
compilatore, in pratica date queste due definizioni:
#define x (4 + y)
#define y (2 * x)
'x' verrebbe espanso in '(4 + (2 * x))'.
Non posso neppure eseguire dei calcoli, in pratica se ho questa
situazione
#define x(a) (a)*4
#define y(a) x(a+1)
'y' verrebbe espanso in (a+1)*4. In pratica non posso creare dei
contatori per incrementare gli indici di riga e colonna perché a+1
verrebbe risolto a run time e non a compile time
e non credo esistano delle istruzioni per creare dei cicli.
Non è quindi fattibile utilizzare le macro per questo scopo?
Grazie a tutti,
   Alessio

Nulla ti impedisce di usare dei preprocessori piu' sofisticati del
semplice cpp.

 semplice cpp.
Si, hai ragione, ma penso che le regole di sostituzione del
preprocessore siano soggette ad uno standard e rischierei di
fidelizzarmi ad un prodotto rinunciando alla portabilità.
Trovo molto interessante la possibilità offerta dal c++ di utilizzare
i template e quindi la programmazione generica. Ora vorrei provare a
capire se un approccio simile è possibile anche in c. In parte si.
Utilizzando opportunamente gli strumenti del preprocessore, come ad
esempio l'operatore di concatenazione ## si riesce agevolmente a
creare delle funzioni a compile time specifiche per determinate
tipologie di problemi.
Ma poi mi sono imbattuto in una serie di limitazioni che mi stanno
creando molte difficoltà. Come ad esempio la moltiplicazione di due
matrici. In questo caso non sono riuscito a scrivere codice "generico"
e l'unica soluzione che ho trovato è stata quella di scrivere una
macro per ogni dimensione che mi serve: una macro per matrici 3X3,
4X4 ...
Grazie
   Alessio


wrote:

Mia opinione personale e' che i Template del C++ per fare calcoli
matematici non sono la soluzione giusta.
La mia esperienza personale e' dettata da un prodotto su cui sto
lavorando, che usa i Template per fare crittografia statica.
Il tempo di compilazione e la impenetrabilita' del codice, per non
parlare di limitazione dei vari compilatori su varie piattaforme (non
esiste solo GCC), mi fa pensare che soluzioni di preprocessione con
linguaggi specifici al problema siano invece meglio.
Tra l'altro, e' piu' facile portare un tool di preprocessione (m4 per
esempio) su varie piattaforme, piuttosto che arzigogolare con il
compilatore.
Estendere il linguaggio per far fare al compilatore un lavoro che non
e' suo non mi sembra l'ideale.
Ma come ho detto, e' la mia personale opinione.


Quoto.
Anche perché per scrivere qualcosa di portabile probabilmente si usano
gli autotool, e ci si trova a scrivere in m4 in ogni caso. :-)
Ciao!

 Il tempo di compilazione e la impenetrabilita' del codice[...]
Che intendi per "impenetrabilit�" del codice?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 questo articolo e` stato inviato via web dal servizio gratuitohttp://
www.newsland.it/newssegnala
 gli abusi ad 
ab...@newsland.it
Che se ci dai un'occhiata, ti viene il mal di testa.
Ma appunto, e' una mia opinione, e magari tu ti trovi a tuo agio.
Ma io considero un lavoro tale come 'hacking' del linguaggio. Il
compilatore fa dei salti mortali, e il mio cervello pure...
Piuttosto avrei preferito dei markers nel codice ed eseguire il
calcolo come pre-compilazione.


Allo stesso modo definire strutture dati generiche e compagnia cantante
e' veramente comodo. 
Ma il passo verso l'incubo e' breve. MPL e' uno strumento del demonio.
STL implementata a compile time. La ho usata. Mi sono sentito un figo.
Tempi di compilazione ingestibili, poi ad un certo punto guardi il
codice e:
1. ti rendi conto che chiunque non abbia un forte background di
programmazione funzionale non ha la minima speranza di capire cosa sta
succedendo
2. hai tirato fuori una soluzione evidentemente sovraingegnerizzata o
ottimizzata prematuramente. 
Poi si arriva ad oggetti come spirit. Per semplici cose funziona ed e'
splendido. Appena ci si complica e si esce dai tre esempi della
documentazione, sei in balia di leggere codice che altro che salti
mortali. 
Quindi in definitiva concordo con il tuo giudizio globale. Sono
*leggermente* piu' positivo. E' bello averlo. Bisognerebbe tagliare il
mignolo a chi ne abusa, ecco.
-- 
-riko

 gli autotool, e ci si trova a scrivere in m4 in ogni caso. :-)
Non che sia IT, ma guarda cmake (o al limite scons). Personalmente li
reputo entrambi superiori agli autotools in fatto di semplicita' di uso.
Il problema risolto poi e' lo stesso.
Certo, cmake fa anche di piu', genera sia makefile che file di progetto
per i piu' diffusi IDE, che di questi tempi e' un plus non da poco.
-- 
-riko

In un ambiente produttivo l'accento è sicuramente posato sugli aspetti
di manutenibilità, sulla capacità di evolvere il software a costi
minimi. In una software house  c'è da tenere conto del turn over degli
sviluppatori che devono essere produttivi il prima possibile. Anche
con codice OO si ottengono risultati devastanti se scritto male,
metodi lunghi migliaia di righe, che denotano una approccio
procedurale al problema, ma sono d'accordo che con i template, ed in
generale con la programmazione generica, è molto più facile aumentare
la complessità del codice, inoltre si introduce un' ulteriore
difficoltà: un codice scritto attraverso regole di preprocessore o con
i template è difficilmente debuggabile.  Dipende sempre dal problema,
ma nonostante gli aspetti negativi che sono stati evidenziati, penso
che la programmazione generica dovrebbe essere più utilizzata, anche
utilizzando tool di preprocessore. In generale, anche se non devo
affrontare problemi fortemente legati al tempo ( applicazioni realtime
o con grossi carichi computazionali come negli engine3d ) preferisco
una soluzione che sia la migliore in termini di utilizzo del
processore. E' quasi una problema di "educazione", in fondo in un
ambiente condiviso il processore non lo uso solo io. E' una mia
opinione, o perversione a seconda.
Ciao
   Alessio

 sviluppatori che devono essere produttivi il prima possibile. 
S�, in un mondo ideale. La possibilit� di gestire il "turn over" degli
sviluppatori � una specie di sogno inseguito da tutti i reparti IT. In
realt�, � molto pi� probabile che montagne di codice siano chiuse nella
testa di singoli sviluppatori e sia molto difficile far transitare le
conoscenze. A volte pu� essere un errore, ma a volte no. Secondo me
bisogna stare attenti a non compiere facili deduzioni. Mi spiego: dato il
livello medio della competenza degli sviluppatori, se si dovesse tener in
cos� alta considerazione la possibilit� che il codice passi di mano in
mano, il codice dovrebbe essere molto molto semplice, banale, quasi
ridicolo. Perch� sono in molto pochi, ad esempio, a studiare ed apprendere
bene il C++. La cosa, ammetterai, sarebbe un po' avvilente. A me
piacerebbe avere uno sviluppatore esperto, in gamba, e valorizzarlo,
stimolarlo, coprirlo di soldi per quanto vale (e quindi diminuire il pi�
possibile la probabilit� che vada via) piuttosto che allinearlo ad un
livello medio, sottopagandolo, avvilendone le competenze, pur di restare
ligio al principio del turn over.
Punti di vista :)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 



Su questo sono d'accordissimo.
Quello che mi piacerebbe vedere e' molta piu' documentazione.
In questo modo, anche idiomi sconosciuti o usi 'creativi' del
linguaggio potrebbero essere spiegati.
La mia opinione e' che a volte, certi programmatori assumono che
l'idioma usato nel loro codice sia immediatamente recepito, e usano
l'idioma senza mai spiegarne i motivi.
A volte mi trovo davanti a degli idiomi, come il Pimpl, venir usati
senza reali necessita', senza spiegazione.
Purtroppo ho notato che e' molto difficile fa scrivere documentazione
al programmatore.
L'architetto magari la documentazione la scrive, ma in un documento
separato, prima dell'implementazione, e quindi a volte senza un forte
legame con la realta'.
Lo sviluppatore scopre problemi con il documento, ma non lo aggiorna,
e via via si introducono dei disallineamenti tali da rendere il tutto
insormontabile.
Io mi ricordo le ore passate davanti allo schermo con mio padre per
documentare gli schemi elettrici prima e dopo l'installazione di un
impianto. Una cosa che gli ho sempre ammirato.
Il vantaggio nel mondo dell'elettronica industriale e' che le
procedure e le tecniche non cambiano molto repentinamente. Quindi mio
padre, con esperienza di 50 anni in cantiere, non ha dovuto
stravolgere il proprio modo di lavorare con frequenza annuale.
Nell'IT, c'e' sempre della nuova tecnologia, nuovi metodi, a volte
solo sperimentali, che pero' a volte creano confusione e
incomprensioni.
Se almeno si 'perdesse' piu' tempo a documentare e argomentare le
proprie decisioni in Italiano/Inglese/... piuttosto che scrivere
codice 'auto-documentante', si potrebbe, secondo me, incrementare la
qualita' del codice.
Io oggi giorno scrivo software usando tool di Literate Programming,
introdotto da Knuth nel lontano '83.
Ma sono purtroppo uno dei pochissimi in azienda. E l'unca persona che
apprezzera' il mio lavoro e' quella che ereditera' il codice una volta
che me ne sono andato.


Da quello che ho visto io nei posti dove ho lavorato: in realtà solo i
folli non fanno fare turn-over agli sviluppatori. In un'azienda
mediamente decente, lo sviluppatore avrà sempre in carico quei
progetti che ha creato personalmente, ma svilupperà su quanti più
progetti possibile, e i progetti che egli ha creato saranno modificati
da più persone diverse possibili. L'impatto è anche positivo in
termini psicologici per i programmatori stessi, che non si affezionano
a specifiche soluzioni (che potrebbero da un giorno all'altro essere
obsolete se non fallimentari) e non si rompono le balle a lavorare
sempre sulla stessa cosa.
Per la qualità del software ci sono le revisioni: ogni commit è
firmato, le modifiche registrate - fare porcherie sul codice,
ristrutturare, o cambiare le carte in tavola non è possibile in
maniera facile ed è facile tornare indietro. Se c'è qualcuno fuori
della media della qualità aziendale (o troppo in alto (eccessive
finezze stilistiche o costrutti oscuri, etc.), o troppo in basso
(algoritmi errati, confusione nel codice, etc.)) si deve adattare:
conta il codice, non chi lo scrive.
Per una software house il problema principale è che gli sviluppatori
vanno e vengono (a gruppi di decine alla volta): se l'azienda è nella
situazione in cui, mancando un solo specifico membro, perdesse una
percentuale significativa di produttività allora quell'azienda è già
vicina al fallimento.
Per quanto riguarda la documentazione, si sa che è roba da burocrati o
ingegneri stressati - o detta più sbrigativamente dagli sviluppatori
del kernel linux: "RTFC". Per come la vedo io, basta fare sempre nella
stessa maniera, poi ci si adatta! Il problema sono i cambiamenti :)
Ovviamente tutto il discorso vale per aziende di medie/grandi
dimensioni: per dimensioni minori il discorso è legato solamente ai
rapporti interpersonali tra tutti.
Bon - ad ogni OT rispondo senza ritegno, che schifo.
Ciao!

 al programmatore.
Questo purtroppo � un punto su cui non credo si trover� mai una facile
soluzione. A me, da buon programmatore, non piace per niente scrivere la
documentazione e, se per documentazione si intende quella che mi si
obbliga a scrivere su certi progetti su cui lavoro, posso ben dire che non
serve a nulla (per intenderci quella che rispetta i vari standard di
qualit� e che praticamente nessuno legger� mai, tanto � prolissa e
stucchevole). Io preferisco scrivere codice organizzato bene, leggibile e
coerente, senza la minima sorpresa per chi lo eredita. Ovviamente
documento gli algoritmi e le architetture in maniera approfondita, ma ad
un livello adatto ad un tecnico. Non mi va proprio gi� di mettermi l� a
scrivere romanzi per descrivere ci� che un occhio esperto dovrebbe
riconoscere e saper leggere facilmente.


 vicina al fallimento.
Non � detto affatto. E' lo stesso discorso di un'azienda che possiede un
buon numero di operai specializzati. Se in una fabbrica c'� un elemento
che � veramente in gamba a produrre un pezzo, piuttosto che spingerlo a
non essere cos� bravo perch� altrimenti non trovo nessuno che lo
sostituisca, tendo a valorizzarlo e a dargli pi� soldi, cos� non se ne va.



In un azienda non informatica (specialmente in una fabbrica) sarebbe
un errore imperdonabile: dare stipendi diversi a dipendenti con la
stessa mansione. Magari lo potresti promuovere, ma Dio ti salvi se non
è il più anziano del gruppo.

 stessa mansione.
Se i dipendenti hanno anzianit� diverse, non sarebbe poi cos� scandaloso.
E quanto di fatto accade con gli scatti d'anzianit�.


 riconoscere e saper leggere facilmente.
Perfettamente in accordo.
-- 
-riko


Infatti te l'avevo aggiunto subito sotto ;) Il problema è se vuoi dare
di più ad uno più giovane (cosa poi non così strana visto che in
generale i giovani imparano prima, lavorano di più e in media hanno
più voglia).