Newsgroup: it.comp.lang.c++
Titolo: [Stile] Signature dei metodi, voi come fate?

Ciao.
Una domanda oziosa: so che nella dichiarazione dei metodi (nello
header, diciamo) di una classe uno puň mettere i nomi di variabili che
piů gli piacciono, o non metterli del tutto. Mi spiego meglio: posso
dire
class pizza
{
	//...
	void pasta(int ciccia);
	//...
};
e poi nell'implementazione
void pizza::pasta(int ciccia){}
oppure, lasciando invariata l'implementazione,
class pizza
{
	//...
	void pasta(int polpo);
	//...
};
oppure
class pizza
{
	//...
	void pasta(int);
	//...
};
Voi come vi comportate?
Per favore togliete "!RemoveMe!" dall'indirizzo per rispondere
Please remove "!RemoveMe!" from the address to reply

 Voi come vi comportate?
Secondo me č meglio mettere comunque il nome del parametro, magari un
nome che faccia capire a cosa serve.
EMG

On Thu, 28 Oct 1999 20:49:11 GMT, sam0284!RemoveMe!@
cdcsun.cdc.polimi.it
(Giulio Agostini) wrote:
Io indico i nomi dei parametri sia nella dichiarazione
che nell'implementazione. Inoltre uso sempre lo stesso
identificatore:
class TWindow {
  ...
  void Move(int dx, int dy);
};
void TWindow::Move(int dx, int dy);
Il motivo e` che spesso uno va a guardare l'header (dichiarazione)
per vedere proprio la signature delle funzioni magari anche con la
speranza di capire a cosa servano i vari parametri. Da qui l'uso
di nomi (significativi) anche nella dichiarazione. L'uso poi dello
stesso nome e` giustificato dal fatto che possibilmente il passo 
successivo e` quello di dare una occhiata all'implementazione per capire
cosa e come lo fa.
Nel caso di parametri non utilizzati uso:
class TWindow {
  ...
  void Move(int dx, int dy, int /* reserved */);
  // o dummy, a seconda dei casi
};
void TWindow::Move(int dx, int dy, int /* reserved */);
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

piů gli piacciono, o non metterli del tutto. 
Io di solito li metto e faccio in modo che chi lavora con me li metta. :)
Lascio nomi "intutivi" nelle dichiarazioni, e - quando necessario, 
nell'implementazione prepongo un underscore "_", tipicamente per i costruttori:
class Pippo {
private: string messaggio;
public: Pippo(const string &messaggio);
};
Pippo::Pippo(const string &_messaggio) : messaggio(_messaggio) {}
oppure, con abbreviazioni "intuitive".. ad esempio tutto il mondo piu' o meno 
capisce "messaggio/message" quando legge "msg", e quindi:
Pippo::Pippo(const string &_msg) : messaggio(_msg) {}
Unica eccezione nei template, a meno di casi particolari, usiamo T, K, etc per 
evidenziare nel codice quali sono i tipi parametri e quali le variabili di 
implementazione del template.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

Personalmente, ripeto il nome invariato nella dichiarazione e nella
implementazione.
class pizza{
void pasta (int ciccia);
...
}
pizza::pasta (int ciccia){...}
Ma solo perchè se vedo:
class pizza{
void farcisci (int, int, int, int*, int&, char*, float)
...
}
non capisco niente dopo 1 secondo che l'ho scritto, per cui non riuscirei
neanche a scrivere l'implementazione :-)
--
Alessandro Monti

void TWindow::Move(int dx, int dy, int /* reserved */);
Io noto che in OWL i parametri non utilizzati vengono lasciati nella
dichiarazione, ma commentati (o addirittura omessi) solo
nell'implementazione. Vedi ad esempio la dichiarazione e
l'implementazione dei metodi MouseEnter e MouseMove della classe
TGadget. Inoltre tali metodi appartengono ad una classe ampiamente
derivabile (la classe TGadget), derivata fino all'inverosimile.
Bye.

derivabile (la classe TGadget), derivata fino all'inverosimile.
TGadget e` una classe che trovo abbastanza ben fatta, nonostante la
presenza di attributi protected e due addirittura public (in effetti un
orrore) e si presta bene ad essere derivata (l'ho fatto piu` volte).


orrore) e si presta bene ad essere derivata (l'ho fatto piu` volte).
Ti riferisci alle sezioni public_data e protected_data del file di
dichiarazione?
In effetti nel commento c'e' scritto che diventeranno private.....
Bye.

 Bye.
Che brutto! Per funzionare da per scontato il meccanismo usato dal
compilatore per passare i parametri e per ripulire lo stack al ritorno
dalla funzione, ovvero e' chi chiama che ripulisce lo stack (ovvero deve
sapere quali e quanti parametri vengono passati). Se si inverte la
convenzione (e' il chiamante a ripulire) il codice si spezza.
Ugh!
Nicola

convenzione (e' il chiamante a ripulire) il codice si spezza.
Tutto questo e` falso, il fatto che un parametro non sia utilizzato non
significa che esso non venga inserito e rimosso nello/dallo stack, 
tant'e` che a call time devi comunque specificarlo.
Evitare di nominare un parametro formale non utilizzato serve
a 2 scopi
1) riservare spazio per future estensioni che non rompano col passato
2) evitare la warning di parametro non utilizzato.
Non e` il parametro ad essere commentato, solo il suo nome:
Es.
intf(int a, int b);   // negli header di OWL
int f(int a, int /* b */) {    // nei file di implementazione
  return a+5;
}
int main() {
  return f(5, 3)+3;


Io avevo capito questo:
int f(int i /*,int j */);
e 
int f(int i, int j) { return i; }
In questo caso penso che il mio commento precedente fosse corretto; Se
e' commentato solo il nome non credo ci siano problemi, salvo una
possibile lievissima inefficenza.
Ciao,
Nicola

Nicola Musatti <Nicola....@ObjectWay.it> wrote in message
38296973...@ObjectWay.it...

No, sarebbero due funzioni differenti (overloading di f). Inoltre, se
funzione membro, la definizione di f(int, int) produce un errore in quanto
manca la dichiarazione - nella classe e' dichiarata f(int). Se la funzione
non e' un membro di classe, sarebbe visibile solo al codice che segue.
Saluti, A.

 possibile lievissima inefficenza.
Commentando tutto il parametro (non solo il nome) per
il compilatore sono due funzioni distinte (altrimenti 
vuol dire che non supporta l'overloading), e quindi il
programma non dovrebbe neanche compilare.
Perche' dici che ci potrebbe essere un'inefficienza?
	Mauro

possibile lievissima inefficenza.
L'inefficienza e` chiaramente quella di inserire un parametro fasullo
nello stack, ma l'effettivo costo sarebbe tutto da valutare (non e` ad
esempio necessario inizializzare tale parametro, basta solo lasciare lo
spazio) e comunque credo del tutto accettabile di fronte alla 
possibilita`  di poter espandere le funzionalita` della funzione
senza rompere col passato.


Oops, devo aver avuto una momentanea regressione al C. E si che non
programmo consapevolmente in quel linguaggio da circa cinque anni...
Ciao,
Nicola
P.S. Per consapevolmente intendo dire sapendo di stare programmando in C
e non in qualcosa che non usa caratteristiche specifiche del C++ ed e'
compilato correttamente da un compilatore C/C++.

Perfettamente d'accordo.
Ciao,
Nicola