Newsgroup: it.comp.lang.c
Titolo: Giochetto strano con il preprocessore

Ringrazio intanto tutti per i consigli sulle variabili extern di qualche 
giorno fa :-)
 
Sto vedendo ora alcuni file di un progetto in cui ho trovato una serie 
di #define e #undefine strani... in pratica:
 
nel file PIPPO.H:
 
#ifndef __PIPPO_H__
#define __PIPPO_H__
 
#define VARGLOBAL extern
 
/* etc. etc. */
 
#endif __PIPPO_H__
 
poi nel file PIPPO.C:
 
#undef VARGLOBAL
 
Nel progetto, tutte le variabili che dovrebbero essere definite extern 
sono invece definite VARGLOBAL, anche nel file PIPPO.C. Ma in 
quest'ultimo, grazie all'undefine, VARGLOBAL non significa nulla, quindi 
ogni variabile globale è definita automaticamente extern nei vari moduli 
e locale nel file PIPPO, giusto? Un modo intelligente per  dichiarare 
automaticamente extern una variabile... o no?
 
Sapete mica dove trovare in internet una lista di "trucchetti" con il 
preprocessore come questo di sopra? Ho provato a cercare "preprocessor 
tricks" con google ma trovo solo consigli banali.

 automaticamente extern una variabile... o no?
 
E' un trucco che, secondo me, non è molto utile.  Rappresenta una di 
quelle automazioni che ti fanno perdere di vista cosa stai scrivendo. 
Perchè mai dovresti preferire scrivere VARGLOBAL anzichè extern?  E 
perchè mai dovresti impigrire il tuo cervello tanto da evitare di non 
scrivere nulla laddove la keyword "extern" *non* ti serve?


Infatti lo ritengo pessimo:
le direttive del processore è meglio utilizzarle il meno possibile, 
proprio quando non se può fare a meno
 
Nel nostro caso basta semplicemente scrivere nell' header
extern int a;
 
e in pippo.c (e solo in pippo.c)
#include "myhead.h"  // l' header che contiene extern int a
int a=0;
 
 
 
 


Fermo restando che anche per me è una cattiva idea, ci sono casi in cui il trucchetto serve, e posso fare l'esempio anche subito visto è presente in un codice che ho sottomano proprio adesso: le variabili globali sono definite nel .h ma devono essere extern quando il codice che include lo header è compilato insieme ad altri, ma non extern quando il codice deve essere compilato da solo, con il suo main (aka nello unit-testing).
 
Per quanto riguarda se esistono liste di "trucchi" del preprocessore non saprei: in generale finché non ti serve non complicarti la vita! Vedrai che prima o poi quando ti tornerà utile te ne accorgerai ;)
 
Ciao!

 scrivere nulla laddove la keyword "extern" *non* ti serve?
 
perche' cosi fai un copy&paste tra un .c e un .h senza star li a dover
aggiungiere oppure togliere l'extern.
Che se hai una variabile cambia poco, se ne hai 100...
E inoltre nel .c sai che quella variabile e' usata anche in altri
files.
 
Ciao Jack

 files.
 
A questo servono i file di intestazione.

 nello unit-testing).
 
Sinceramente non ho ben capito.  Potresti fare un semplice esempio per 
farmi capire il concetto?
 
Cosa intendi per unit-testing?  Probabilmente hai una funzione main() 
che "abiliti" per fare dei test all'interno del modulo .c da testare. 
Penso che anche questa pratica non sia una buona idea: perchè "sporcare" 
il codice finale intercalando il codice di test e preoccupandoti di 
dichiarare in modo diverso le tue variabili?  Alla fine andrai a testare 
un sorgente diverso da quello finale.
 
Molto meglio scrivere un modulo .c/.h (sto semplificando) definitivo per 
l'applicazione e scrivere un test.c (con un main) che utilizza solo quel 
modulo per testarlo approfonditamente.  In questo modo il tuo sorgente 
sarà esattamente lo stesso durante i test e nell'applicazione finale.  E 
non devi sbatterti sul cambio di dichiarazione delle variabili.  Ti pare 
poco?

 files.
 
Se una variabile è usata da altri file, questa è dichiarata senza nulla. 
  Se è dichiarata e usata solo in un file, questa *dovrebbe* essere 
dichiarata static.
 
 

 poco?
 
 
Si, vabè.. e quando hai N .c che fai? N .test? e quando ne modifichi uno come fai compilare e girare il test? e quando un .c a sua volta ne usa due o tre? Evidentemente non l'hai mai fatto e non hai presente le problematiche del caso. Ti conviene prepararti se dovrai un giorno lavorare in un'azienda con s(In ogni caso, un codice che necessita di tretti requisiti di qualità.
 
Ciao!
 
P.S. Scusa il rant, non volevo essere duro o saccente, solo che è la risposta che mi hai dato mi fa capire che un reply preciso avrebbe portato ad altre domande ancora - in caso se ne voglia parlare magari apriamo un altro thread solo sul testing o sui processi di sviluppo.

 sviluppo.
 
Guarda, il testing del software è un argomento estremamente 
interessante, ma non vale la pena parlarne qui.  Stavo semplicemente 
notando come il tuo approccio allo unit-testing mi sembra un attimino 
criticabile.  Poi che si chiami unit-testing, che ci siano mille teorie 
al riguardo, che è fondamentale nello sviluppo di un software di 
qualità... ok, va bene, ma non è questo il punto della discussione.

 Lo unit-testing è fondamentale per qualsiasi prodotto software:
 
Mi interessa (ne ho solo sentito parlare).
Apro un altro thread...

 qualità... ok, va bene, ma non è questo il punto della discussione.
 
Sono contento che non te la sei presa a male per il mio post, spessissimo sono accusato di essere poco diplomatico nei reply ;)
Il concetto di fondo che vorrei esprimere è che se non si ha la visione completa dell'utilizzo del linguaggio (cosa che neanche io ho, ma chi può averla?) bisogna essere cauti nel dare giudizi sull'utilizzo di una feature in un determinato ambiente nel caso quell'ambiente non fosse conosciuto.
Non molto tempo fa ebbi una tirara d'orecchi proprio da un frequentatore di questo NG (credo Vincenzo Mercuri, se non sbaglio) perché sostenni che se si fanno più di tre cicli annidati in un algoritmo questo è sbagliato: ero ovviamente in torto visto che, nonostante la mia asserzione derivasse oltre che dalla mia personale esperienza anche da una credenza diffusa, non ero a conoscenza di determinati algoritmi in cui questa pratica non solo è necessaria, ma indispesabile - algoritmi di nicchia, certamente, ma esistenti e (evidentemente) utilizzati.
Per quanto riguarda lo unit-testing sarò felice di discutere gli approcci più diffusi nella mia esperienza, e in effetti devo riconoscere che il termine fa parte più del gergo dei programmatori ad alto livello che dei programmatori C (ma, come hai detto te, anche se il testing non fa parte del mondo del basso livello, la necessità fa di vizio virtù).
Ciao!

 si fatichi molto a digitare le tue variabili *pensando* di volta in
 
se devi mettere mano al codice scritto da qualcun'altro puo' aiutare
non poco.
 
Ciao Jack


E questo qualcun altro dovrebbe utilizzare la tua stessa convenzione di 
dichiarazione delle variabili?  Mi sembra difficile.