Newsgroup: it.comp.lang.c++
Titolo: Lezioni di stile

Ok il post puo' sembrare strano ( e lo č )
ma sto passando ( da un anno circa ) grossi problemi per quanto
riguarda lo stile dei miei programmi. Io vengo dal pascal dove il mio
prof mi aveva "imposto" ora che sono passato a linguaggi C++like (
java, php ecc ecc ) non so + che stile usare ok per la nomeclatura ma
esempio una classe devo definirla cosi
class TPippo {
    metodo1 {
        ...
    }
    metodo2 {
        ...
    }
    metodo3 {
        ...
    }
}
oppure
class TPippo
{
    metodo1
   {
        ...
    }
    metodo2
    {
        ...
    }
    metodo3
    {
        ...
    }
}
la if mi piace molto in questo modo
if ( ... ) {
  ..
} else {
  ...
}
al contrario di
if ( ... ) 
{
   ...
}
else 
{
   ..
}
e in tutto questo come si comportanto i vari private/public? non tanto
in java che vanno ripetuti ogni volta ( un po' seccante ) ma per
esempio in C++ dove si dichiarano una volta sola e valgono per tutti i
metodi e proprieta sottostanti
gli enum non mi piacciono molto preferisco + l'accopiata variabile +
#define voi che ne pensate?
altra cosa
tra const e #define voi cosa preferite ?
 
( ok queste non sono molto sullo stile ma visto che c'ero l'ho messe )
Il Razziatore,
The Only Good Windows is an uninstalled Windows
-----------------------------------------------
E-MAILs : IlRazziat...@NOSPAMnetscape.net
ICQ     : 67552596
-----------------------------------------------
Founder of MediaPlayer Project
http://mpp.iwebland.com

  
#define

 tra const e #define voi cosa preferite ?
Scott Meyers dedica il PRIMO capitolo del suo "Effective C++"
a spiegare perchè const è meglio di #define.
Personalmente non me la sento di contraddirlo... :-)
ciaociao
-- 
Gerolamo

  
Variabili 'const', indubbiamente. O anche 'enum'. Mai #define.
I nomi introdotti con #define possono inaspettatamente interferire con il 
codice altrui (e anche con il nostro). Non possono essere mantenuti in un 
namespace. Non trovo buone ragioni per usare #define.
Max

 Ok il post puo' sembrare strano ( e lo è )


 tra const e #define voi cosa preferite ?
#define. Quella che da' meno casini in termini di interoperabilità
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!

 tra const e #define voi cosa preferite ?
"const". I debugger ti trattano meglio. :-)
Ciao!
-- 
---
*************** | Have you ever retired a human by mystake?
*** Azathot *** |
*************** | To contact me, ask me gently. Thanks.

 #define. Quella che da' meno casini in termini di interoperabilità
Seeeee.... questa dove l'hai letta, in un README di qualche prodotto 
Microsoft... tipo l'MSDN? <g>


 [CUT]
Personalmente se lavoro sotto Windows uso:
if( espressione )
{
	istruzioni
} else {
	istruzioni
}
while( espressione )
{
	istruzioni
}
int foo()
{
	istruzioni
}
class NomeClasse
{
	protected:
		NomeClasse();
}
etc.
Sotto unix (GNU/Linux in particolare) uso:
if( espressione ) {
	istruzioni
} else {
	istruzioni
}
while( espressione ) {
	istruzioni
}
int foo()
{
	istruzioni
}
class NomeClasse
{
	protected:
		NomeClasse();
}
etc.
Questo perche' cerco di adattarmi al metodo utilizzato dalla maggioranza 
dei programmatori per quella piattaforma.
Per i define... solitamente uso quelli, per abitudine. Penso pero' che 
sia piu' corretto usare i define per compilazioni condizionali e per 
costruire macro "vere" (passatemi l'espressione imprecisa), non per 
definire costanti. Per queste e' meglio usare le costanti e gli enum.
Non sono daccordo con l'espressione "Scegliete lo stile che vi pare ma 
siate coerenti, cioè usate sempre quello nell'ambito del vostro codice".
Questo e' il requisito minimo. Valido se uno lavoro solo su piccoli 
progetti che porta avanti da solo. Nella maggior parte dei lavori invece 
  dobbiamo collaborare con altre persone, integrare il software scritto 
da noi con quello scritto da altri, lavorare in piu' persone sugli 
stessi sorgenti etc. Se ogni sviluppatore fa quello che vuole sai che bello!
Ciao.
  -Ema-

 Seeeee....
bene, ora dimostra che:
 - hai capito cos'ho detto
 - quello che ho detto non è vero


  - quello che ho detto non è vero
Ne hai veramente necessità oppure è solo un modo per evitare di sentirti 
umiliata?
Ciao.


  - quello che ho detto non è vero
Ecco cosa puo' succedere con le define:
#include <stdio.h>
#define MUL(a,b)    a * b
inline __mul(int a,int b){ return a * b; }
int main (int argc,char *argv[])
{
    printf("Risultato: %d\n",MUL(2+3,5));
    printf("Risultato: %d\n",__mul(2+3,5));
    return 0;
}
Ivan

#define MUL(a,b)    a * b
basta mettere (a)*(b)


 basta mettere (a)*(b)
Scusa, quanto fa:
        int a=10;
        MUL( a++, a )
?


 Andrea
Mi sembra l'unica regola saggia assieme a questa: 'usate uno stile
leggibile' dove la definizione di leggibile è tutta da inventare :-)
Io ho visto svariati stili e non ho mai avuto difficoltà con quelli che si
usano definire 'coerenti', cioè hanno una logica e soprattutto si mantengono
per tutto il codice. Quando lavoro su codice scritto da altri mi adeguo al
loro stile (se c'è!).

?
110, perke?


 110, perke?
Perché la versione macro viene espansa alternativamente a
        (a++) * (a) => 10 * 11 => 110
        (a++) * (a) => 10 * 10 => 100
a seconda dell'ordine di valutazione, mentre la versione "inline" viene 
espansa (più correttamente) a
        10 * 10 => 100
Ciao!


 
Beh qui si stava parlando di #define contro const il che non include IMHO 
il discorso delle macro

 espansa (più correttamente) a
Non mi pare esatto quello che dici. Il problema sussiste sia nel caso della 
macro sia in quello della funzione. Questo codice:
    func( a++, a );
non produce un comportamente definito. Questo non dipende dal fatto che 
'func' sia una vera funzione o una macro, bensì dalle regole stabilite in 
[5.4]: l'ordine in cui vengono calcolate le espressioni e l'ordine in cui 
hanno luogo i side-effect non è specificato, e prima del successivo 
sequence-point, il valore precedente la modifica deve essere ricavato 
soltanto per determinare il valore che dev'essere memorizzato.
L'esempio classico degli inconvenienti legati all'uso delle macro è quello 
in cui la definizione della macro stessa fa riferimento più volte allo 
stesso argomento. Esempio:
 #define mul_by_2(a)   ( (a)+(a) )
 result = mul_by_2(++a); // argh... cose orrende!
Max

 non produce un comportamente definito. 
Sicuro? Non deve essere garantito l'uso della variabile PRIMA 
dell'incremento? E la chiamata a funzione, purché non faccia uso di 
reference, non agisce su COPIE di valori, i cui valori rimangono inalterati 
dall'operazione di post-incremento?


 dell'incremento? 
Lo Standard dice: "the prior value shall be accessed only to
determine the value to be stored". 
Mi pare che nell'espressione in questione questa regola venga violata.
Max

  
Const, quasi sempre.
Ma qui (e anche in altre casi) la scelta dipende dal tipo e dalle 
caratteristiche del progetto.
Es. se devo scrivere del codice che deve essere portato su una 
piattaforma dove il compilatore C++ potrebbe avere problemi di aderenza 
allo standard del linguaggio, magari uso i #define.
-- 
Roal Zanazzi