limiti del preprocessore
mrtam...@gmail.com
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
fnegroni
semplice cpp.
mrtam...@gmail.com
> Nulla ti impedisce di usare dei preprocessori piu' sofisticati del
> 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
fnegroni
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.
FtM
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!
Andrea Laforgia
> 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
fnegroni
> fnegroni ha scritto:
>
> > Il tempo di compilazione e la impenetrabilita' del codice[...]
>
>
> --
>
> 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.
Enrico Franchi
> 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.
Gia' che ci siamo, dico anche io la mia. Magari poi ci spostiamo sul ng
IT.
La meta-programmazione templatica e' una gran cosa. E' bellissima. Ma e'
anche una di quelle cose in cui si e' sempre sul bordo di strafare.
Per esempio, il fatto che si possa usare per inserire i numeri in
binario e' qualcosa di bellissimo.
E' qualcosa che aumenta la leggibilita' e volendo non peggiora i tempi
di compilazione (possiamo sempre mettere le costanti nel file di
implementazione e tenerle extern).
<http://www.eptacom.net/pubblicazioni/pub_eng/binary.html>
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
Enrico Franchi
> Anche perch� per scrivere qualcosa di portabile probabilmente si usano
> 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
mrtam...@gmail.com
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
Andrea Laforgia
> In una software house c'� da tenere conto del turn over degli
> 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
fnegroni
> mrtambur...@gmail.com ha scritto:
>
> > In una software house c'è da tenere conto del turn over degli
> > sviluppatori che devono essere produttivi il prima possibile.
>
> 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
> bisogna stare attenti a non compiere facili deduzioni. Mi spiego: dato il
> livello medio della competenza degli sviluppatori, se si dovesse tener in
> mano, il codice dovrebbe essere molto molto semplice, banale, quasi
> bene il C++. La cosa, ammetterai, sarebbe un po' avvilente. A me
> piacerebbe avere uno sviluppatore esperto, in gamba, e valorizzarlo,
> 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 :)
>
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.
FtM
> mrtambur...@gmail.com ha scritto:
>
> > In una software house c'è da tenere conto del turn over degli
> > sviluppatori che devono essere produttivi il prima possibile.
>
> 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
> bisogna stare attenti a non compiere facili deduzioni. Mi spiego: dato il
> livello medio della competenza degli sviluppatori, se si dovesse tener in
> mano, il codice dovrebbe essere molto molto semplice, banale, quasi
> bene il C++. La cosa, ammetterai, sarebbe un po' avvilente. A me
> piacerebbe avere uno sviluppatore esperto, in gamba, e valorizzarlo,
> 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 :)
>
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!
Andrea Laforgia
> Purtroppo ho notato che e' molto difficile fa scrivere documentazione
> 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.
Andrea Laforgia
> Da quello che ho visto io nei posti dove ho lavorato: in realt� solo i
> folli non fanno fare turn-over agli sviluppatori.
Scusa ma perch� un'azienda dovrebbe forzare il turn-over? perch� forzare
la perdita di risorse preziose per rinforzarla con forze nuove? Dal mio
punto di vista bisogna puntare a valorizzare le risorse che si possiede,
creare uno zoccolo duro, rendere allettante restare in azienda, non cadere
invece nella paranoia da cautele. Per quel che riguarda invece la
"rotazione" dei programmatori sui progetti, il problema non � la decenza o
l'indecenza dell'azienda e non � questione di follia o di sanit� mentale,
� questione di possibilit�: molto spesso non � possibile perch� non ci
sono le risorse necessarie, non c'� un numero di progetti tale da far
ruotare gli sviluppatori su cose sempre nuove. Semplicemente, non �
possibile.
> Per una software house il problema principale � che gli sviluppatori
> vanno e vengono [...]
Sorrido nel leggere "software house". Mi sembra un termine un po'
"old-fashioned" in un mondo dell'informatica in cui, al 90%, si fa body
rental.
Dal mio punto di vista, se un'azienda ha un problema di turn-over cos�
massiccio, deve rivedere qualcosa a livello manageriale. Non � normale che
cos� tanta gente si ricambi con frequenza. Vuol dire che non stanno bene.
> situazione in cui, mancando un solo specifico membro, perdesse una
> percentuale significativa di produttivit� allora quell'azienda � gi�
> 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.
FtM
> "old-fashioned" in un mondo dell'informatica in cui, al 90%, si fa body
> rental.
Sì, forse solo in Italia. E infatti l'informatica italiana a livello
mondiale è ... quasi pari a zero?
> Dal mio punto di vista, se un'azienda ha un problema di turn-over così
> massiccio, deve rivedere qualcosa a livello manageriale. Non è normale che
> così tanta gente si ricambi con frequenza. Vuol dire che non stanno bene.
>
No, vuol dire che le aziende di informatica italiane sono costrette,
prendendo un gran numero di consulenti, a vedersi cambiare/stare a
casa/portar via un gran numero di persone, anche contro la loro
volontà. E' la legge italiana del corrente mercato (sia aziendale che
del lavoro in generale) che costringe a fare questo.
Personalmente non sono d'accordo con lo status-quo, ma questo abbiamo
e questo per ora dobbiamo tenerci.
> > situazione in cui, mancando un solo specifico membro, perdesse una
> > percentuale significativa di produttività allora quell'azienda è già
> > 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.
Andrea Laforgia
> No, vuol dire che le aziende di informatica italiane sono costrette,
> prendendo un gran numero di consulenti,
Ma � qui il punto: perch� tutto questo body rental? perch� tutti questi
consulenti? non ha molto senso a mio parere. E anche la parola
"consulente", che dovrebbe avere una sua dignit�, si appiattisce sul
concetto di "semplice manovalanza esterna". Io vedo consulenti restare per
anni presso il cliente e non capisco proprio questa politica: perch� non
assumere? si ridurrebbero anche i costi. Il problema � che nessuno pi� si
addossa il rischio d'impresa dei progetti a corpo, a nessun interessa
avere team di analisti e sviluppatori competenti, tutti si rivolgono ai
pi� comodi progetti su cui � facile fare pasticci per mezzo di freschi
laureati inesperti da spremere con contratti a progetti, intascare gli
esorbitanti compensi e scappare via.
> In un azienda non informatica (specialmente in una fabbrica) sarebbe
> un errore imperdonabile: dare stipendi diversi a dipendenti con la
> stessa mansione.
Se i dipendenti hanno anzianit� diverse, non sarebbe poi cos� scandaloso.
E quanto di fatto accade con gli scatti d'anzianit�.
Enrico Franchi
> 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.
Perfettamente in accordo.
--
-riko
FtM
> > prendendo un gran numero di consulenti,
>
> consulenti? non ha molto senso a mio parere. E anche la parola
> concetto di "semplice manovalanza esterna". Io vedo consulenti restare per
> assumere? si ridurrebbero anche i costi. Il problema è che nessuno più si
> addossa il rischio d'impresa dei progetti a corpo, a nessun interessa
> avere team di analisti e sviluppatori competenti, tutti si rivolgono ai
> laureati inesperti da spremere con contratti a progetti, intascare gli
> esorbitanti compensi e scappare via.
>
Credo perché vengano contati diversamente nei budget. I costi relativi
agli stipendi dei "consulenti" sono facilmente "tagliabili" - chiudi
il progetto, a casa tutti, il costo è zero. Avendo dei dipendenti
fissi questo non è così facile. Il costo per un'azienda per un
dipendente ed un consulente, poi, non è così diversa, e comunque non
vale la libertà di smazzare personale senza problemi in caso di
disastro.
Per quanto riguarda i neolaureati sì, si tratta più semplicemente di
un sistema truffaldino ;-)
Il discorso che "nessuno più si addossa il rischio d'impresa" è facile
per i singoli, ma le medie/grandi aziende hanno altri tipi di valori
(i soldi).
> > In un azienda non informatica (specialmente in una fabbrica) sarebbe
> > un errore imperdonabile: dare stipendi diversi a dipendenti con la
> > stessa mansione.
>
> Se i dipendenti hanno anzianità diverse, non sarebbe poi così scandaloso.
> E quanto di fatto accade con gli scatti d'anzianità.
>
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).