Newsgroup: it.comp.lang.c
Titolo: parentesi

Se dovessi mettere le parentesi per rendere precedenza degli operatori
esplicita, come sarebbero?
 ! a -= b == c ++ && * d ++ / -- g
E qui, se le dovessi togliere :
a%= ((((a<2) & (b>>3)) & 15) && (c))
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 a%= ((((a<2) & (b>>3)) & 15) && (c))
Anche questa e` piuttosto oscura ma penso che togliendo le parentesi non 
sia valida.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 a%= ((((a<2) & (b>>3)) & 15) && (c))
Ci puoi arrivare facilmente se tieni presente la priorità degli operatori
C.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 > a%= ((((a<2) & (b>>3)) & 15) && (c))
Io ho ottenuto
a%= ( ( a<2 & b>>3 ) & 15 && c )
e' giusto?


 e' giusto?
Non ho sotto mano la tabella della precedenza tra operatori, se te la
procuri è un attimo verificarlo per conto tuo.


 sia valida.
[...]
Perché non dovrebbe essere valida ?
Basta togliere le parentesi per vedere che lo è.
Supponiamo inoltre che a,b e c non siano subdole macro
o strutture o tipi che non sono consentiti per questi operatori.
Cioè diamo per scontato che il singolo operatore
sia applicabile senza problemi.
Inoltre con tutte le parentesi o senza nemmeno una parentesi
le due espressioni sono equivalenti.
--
Giorgio Silvestri
DSP/Embedded/Real Time OS   Software Engineer


L'operatore * unario ha la stessa priorità di ++ e --.
Quello che entra in gioco in questo caso è
l'associatività.
*,++ e -- associano tutti a destra.
Per questo *d++ equivale a *(d++).
L'effetto è lo stesso ma per un motivo diverso dalla
priorità.
Se invece parliamo di * binario, cioè la moltiplicazione,
allora ha la stessa priorità di /.
La tabella non è corretta in nessuno dei due casi.


 L'operatore * unario ha la stessa priorità di ++ e --.
Sì, è vero.


 Basta togliere le parentesi per vedere che lo č.
In generale, comunque, eliminare le parentesi non traduce necessariamente
un'espressione valida in un'altra espressione valida...


 le due espressioni sono equivalenti.
mi ero fermato a questo
a%= ( ( a<2 & b>>3 ) & 15 && c )
Ovviamente a<2 e b>>3 hanno precedenza su &, ma significato non cambia se
dico
caso1)
( a<2 & b>>3 ) & 15
caso2)
a<2 & b>>3 & 15
nel primo caso pensarei che faccio la parentesi e poi &15, mentre nel
secondo faccio a<2 e poi b>>3 e poi 15 (non so se mi spiego).
Ovviamente se il mio dubbio e' errato, allora posso eliminare
tranquillamente la parentesi.
Poi avevo lasciato la parentesi prima dell'uguale a%= (....) non vuol dire
a=a%(....)
Posso eliminarla senza problemi questa parentesi?



Comunque l'OP voleva sapere di quella espressione in particolare non
in generale.


 Posso eliminarla senza problemi questa parentesi?
In questo caso specifico sì.
Ricorda che:
E1 op= E2  equivale a  E1 = (E1) op (E2)
Osserva le parentesi ...
ma E1 viene valutato una sola volta!
E' importante se l'accesso ha side-effect!
Es: E1 è una variabile volatile o E1 contiene una
chiamata di funzione (sì è possibile).
Allora tutto cambia.
Ma,  come avevo già detto, scartiamo queste possibilità.
Anche perchè forse non era quello che ti interessava sapere.


in generale.
Non vorrei che qualcuno traducesse quello che hai scritto in una
regola generale per capire se un'espressione con parentesi esplicite è
valida o meno.  Comunque, in un gruppo come questo, non c'è alcun
problema nel partire da un'affermazione specifica e portare il
discorso a un livello più generale.

secondo faccio a<2 e poi b>>3 e poi 15 (non so se mi spiego).
Stai particolarmente attento al fatto che l'ordine di valutazione è
dettato dalla precedenza degli operatori, ma l'istante in cui il
compilatore esegue i singoli calcoli non è definito.  Nel senso che,
in un'espressione come la seguente:
a = (a+b)*(b/(c+d))
non è affatto detto che c+d, per esempio, venga calcolato dopo a+b.
Questo è un aspetto importante che conferisce ad espressioni del tipo:
i = i++ + i;
un comportamento indefinito...