Newsgroup: it.comp.lang.c++
Titolo: Operatore ||

Salve, sono alle prime armi col c++, volevo avere un parere...
L'istruzione booleana
return [condizione] && [condizione] || [fai qualcosa];
significa che ritorna vero se le 2 condizioni sono verificate,
altrimenti fa qualcos'altro?
Grazie!  :)
-- 
Larin
------------------------------------------------------------------------
Inviato via 
http://www.freenfo.net/usenet
Profilo di Larin: 
http://www.freenfo.net/usenet/member.php?userid=1188

 altrimenti fa qualcos'altro?
Ni.
E' da interpretare come:
return ( ( [condizione1] && [condizione2] ) || [fai_qualcosa()] );
Ovvero: se condizione1 e condizione2 sono vere => ritorna 1 senza
eseguire il fai_qualcosa.
Se una delle 2 condizioni è falsa => esegue fai_qualcosa(), la quale 
restituirà
presumibilmente un booleano o un intero
A quel punto la funzione ritorna false se fai_qualcosa() ha restituito
false (o 0), altrimenti restituisce true.
Però diciamocelo... è un po' una porcata. :)
-- 
Gerolamo 

 
<sorry per il quoting esteso>
Sono curioso: _cosa_ e' una porcata?
-- 
Roal Zanazzi

 Sono curioso: _cosa_ e' una porcata?
mettere su una riga:
return [condizione] && [condizione] || [fai_qualcosa()];
perchè:
- non è chiaro a prima vista cosa succede
- in particolare non è immediatamente chiaro quando e se
  fai_qualcosa() viene chiamata
- è possibile che fai_qualcosa() abbia dei side effect e in
  caso di necessità di debug andare a ricostruire la situazione
  non è certo agevolato dalla chiarezza del codice
insomma, la riga di codice è perfettamente legittima, ma
sarebbe stato più chiaro scrivere:
if( [condizione] && [condizione])
{
    return true;
}
else
{
   bool ret =  fai_qualcosa(); //commento
   return ret;
}
-- 
Gerolamo 

 }
Anche
return (c1 && c2) ? true : fai_qualcosa();
Kiuhnm



Da essempio, anche se è preferribile mettere il ?: (o una
combinazione di && e ||) sul più d'une linea:
    return (c1 && c1)
        || fai_qualcosa() ;
(Anche mi piace con una funzione supplementaria:
    bool
    non_bisogna_fare_niente()
    {
        return c1 && c2 ;
    }
        //  ...
        return non_bisogna_fare_niente() || fai_qualcosa() ;
(Ma tutto dipende infatti delle condizioni.)
--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, 
+33 (0)1 30 23 00 34

 }
Io preferisco la precedente e se proprio vuoi scriverla per esteso
almeno scrivi
bool ret = condizione && condizione;
if ( ! ret )
    ret = fai_qualcosa();
return ret;
E' sicuramente una questione di gusti, ma sarebbe bene comunque
abituarsi all'uso dei costrutti fondamentali del linguaggio (e tenere
lo Stroustrup o il Lippmann-Lajoie-Moo a portata di mano).
Ciao,
Nicola

lo Stroustrup o il Lippmann-Lajoie-Moo a portata di mano).
Concordo sull'abituarsi a comprendere i costrutti.
Non concordo invece sull'usare costrutti che rendano piů compatto
il codice, ma piů difficilmente comprensibile a una prima occhiata.
A tal riguardo il recente thread di Kiunhm ",?:", mi sembra esemplicativo
su dei costrutti che č necessario saper decifrare, ma non trovo conveniente
usare, se non in casi molto semplici e autoesplicativi.
Poi, come dici tu, č sicuramente questione di gusti.
-- 
Gerolamo 

 usare, se non in casi molto semplici e autoesplicativi.
Non direi proprio.
Esiste una corrispondenza 1-1 tra
a;
b;
if (a)
   c;
else
   d;
e
a,
b,
(a) ?
   c
:
   d
Adesso la vedi? Non c'è nulla da decifrare.
Kiuhnm

 condizione2 e' falsa.
Non é chiaro per me. Bisogna gardare la norma per vedere la
precidenza relativa di && e ||, non l'ho in testa. Io metto
sempre parentese, e non ho visto altri che non lo fanno.
É possibile che mi servo di C e di C++ da 25 anni senza li
conoscere? Che non ho il nivello minimo per programmare nei
questi linguaggi?


 questi linguaggi?
D'accordo. In effetti la combinazione tra precedenza e associativita'
da una parte e 'short circuiting' dall'altra spingono anche me a usare
le parentesi per indicare inequivocabilmente cosa intendo.
Una cosa e' pero' aggiungere le parentesi ed un'altra trasformare
l'espressione in un'istruzione if.
Devo dire che quando devo scrivere espressioni booleane complesse sento
talvolta la mancanza degli operatori 'and', 'or' e 'not' del Pascal. Se
da una parte l'assenza del short circuit rende necessario precalcolare
determinati valori, dall'altra la semantica coincidente con l'algebra
booleana e' piu' facile da ricordare.
Forse l'ottimo e' quello che faceva il vecchio IBM Pascal per PC, che
aveva gli operatori 'and then' e 'or else' per specificare le versioni
short circuit.
Ciao,
Nicola

 Adesso la vedi? Non c'è nulla da decifrare.
Cosa non diresti proprio?
E' chiaro che il codice è comprensibile, ma non direi proprio che
è semplice e autoesplicativo.
Ovviamente è una questione soggettiva, ma vogliamo fare un sondaggio
per sapere a quanti risulta esplicativo questo?
a,
b,
(a) ?
   c
:
   d
-- 
Gerolamo 

 per sapere a quanti risulta esplicativo questo?
Le due espressioni sono isomorfe. Punto. Chi non le capisce non pensa. 
Peggio per lui.
Kiuhnm

 short circuit.
Vero, ma non dimenticare che in C++ hai '|' e '&'.
Puoi vederle praticamente come versioni strict (sebbene potrebbero 
occorrere conversioni esplicite a bool).
Kiuhnm


Sei tu che dimentichi che sono contrario alle soluzioni eterodosse ;-)
Ciao,
Nicola

 Chi non le capisce non pensa. Peggio per lui.
Credo che la tua affermazione sia una stupidaggine.
Non è questione di fare qualcosa di capibile, ma di FACILMENTE
capibile.
E' come dire che (quasi) tutti i linguaggi sono equipotenti, e
questa è una buona ragione per scrivere tutto in assembler.
E chi non capisce l'assembler non pensa.
Peggio per lui.
...pensaci...
Per il resto, quiesta discussione mi sembra diventata ormai sterile.
Io chiudo qui.
-- 
Gerolamo 

 E' come dire che (quasi)  [...]
No, non lo č.
Kiuhnm


E chi le capisce, ma deve fare un inutile sforzo mentale solo ed 
esclusivamente perche' tu volevi sfoggiare la tua proverbiale conoscenza 
del C? :)

 del C? :)
Guarda che quello è codice C++. Casualmente, funziona anche con un 
compilatore C :) Inoltre la mente è come un muscolo. Lo sforzo non è 
stato inutile. Neanche la tecnica esposta è inutile.
A quanto pare, non solo la comunità C++ decide quale astrazioni non 
devono essere introdotte, ma decide anche di quali operatori è 
necessario dimenticarsi.
Kiuhnm

sempre parentese, e non ho visto altri che non lo fanno.
Concordo pienamente!

 necessario dimenticarsi.
Io non decido niente. Per me puoi anche riempire il tuo codice di goto, 
nessuno ti dara' mai una multa, al limite ti diranno che scrivi 
spaghetti code :)

 specificare le versioni short circuit.
Come Ada.
--
James Kanze (Gabi Software)              email: 
kanze...@neuf.fr


 Chi non le capisce non pensa.
Capisco che se qualcuno si scarta degli idiomi abituali, le fà
per una ragione, che cerco a capire perche. Cosa apporta
utilisare un idiome poco abituale agli programmatori medii?
--
James Kanze                                           GABI Software


 complessissimo, mà facile a leggere perche era ben indentata.)
In effetti la molteplicita' di modi in cui possono essere codificati
queste esempi e' cio' che ci consente di esprimere sfumature di
significato. Sono d'accordo con te che se dovessi scrivere un'azione
sottoposta a condizione, probabilmente scriverei:
if ( condizione() )
  azione();
anche se azione restituisse un booleano. In particolare penso che sia
sempre bene cercare di rendere nel codice la coesione dei concetti che
si devono rappresentare. E' anche per questo che non spezzerei la
condizione che ho presentato come esempio qualche giorno fa. In quel
caso c'e' anche l'aspetto della regolarita', che sarebbe meno evidente
fattorizzando la mia condizione in funzioni separate.
Ciao,
Nicola

 utilisare un idiome poco abituale agli programmatori medii?
Quando programmo prendo delle decisioni e queste NON dipendono da cosa 
pensano i programmatori medi. Hai idea di cosa significhi medio oggi?
Il mio codice sarà eventualmente letto e studiato dal ricercatore medio, 
non dal progammatore medio.
Del resto si occupa di algebra dei linguaggi. Che speranze può avere di 
modificare con successo un tale codice un programmatore che non è in 
grado di capire una semplice espressione C++?
Kiuhnm

 grado di capire una semplice espressione C++?
Guarda che non si tratta di non capirla, si tratta del fatto che, tra 
centinaia di migliaia di linee di codice, se ri riesce ad evitare di 
filosofeggiare su ogni riga, è meglio.
Ti consiglio un libro, "Code Complete 2" di Steve McConnell: è molto ben 
fatto, ed è incentrato sulle pratiche di buona programmazione in ambito 
professionale.
Ciao,
Zeppe

 programmatore medio.
!!! ROTFL !!!
Kiuhnm


Chiaramente ho detto quanto ho detto perche' e' quanto ho visto *sempre* 
per esperienza personale, giusto a scanso di equivoci.
Comunque vedi, il problema č che il ricercatore NON fa il programmatore 
di lavoro. E' semplicemente un'altra cosa, studia altre cose, non č 
interessato a molti aspetti che per un programmatore professionista sono 
essenziali. E viceversa: il programmatore č molto meno interessato ad 
argomenti piů squisitamente teorici, che per lui sono superflui, mentre 
per il ricercatore sono essenziali.
Sfortunatamente, e lo dico per esperienza diretta, molti ricercatori 
credono di essere, in virtu' della posizione che ricoprono, in una 
specie di iperuranio rispetto ai professionisti normali (che in realta' 
la maggior parte delle volte sono persone in gamba esattamente come 
loro, se non di piu'), e questo li porta ad assumere atteggiamenti pieni 
di boria e di presunzione, parlando anche di cose che non conoscono in 
modo altezzoso, e piuttosto ridicolo.
Quindi, io ti consiglierei di non rispondere !!! ROTFL !!! dando credito 
alla mia teoria, ma di riflettere invece su quanto certe persone qui nel 
ng stanno cercando di dirti ormai da un numero pressoche' infinito di 
post, almeno da quanto ho visto: ti sembrera' strano, ma non siamo tutti 
tonti!
Scusate per il post un po' OT.
Ciao,
Zeppe

 !!! ROTFL !!!
Sei un pelo borioso. Lavorando in una spin-off universitaria, ho letto e 
revisionato il codice di diversi dottorandi e ricercatori e mentre 
alcuni raggiungono l'eccellenza (e quindi, contrariamente a quello di 
cui si discute, scrivono codice ben leggibile) la maggior parte scrive 
spaghetti-code e non conosce la differenza tra "delete" e "delete[]".

 spaghetti-code e non conosce la differenza tra "delete" e "delete[]".
Parlo esclusivamente di ricercatori che si occupano di linguaggi di 
programmazione e sistemi di sviluppo.
Penso che se ogni programmatore studiasse i linguaggi dal punto di vista 
formale, cambierebbe idea su molte questioni.
La cosa più importante da imparare è che un approccio va valutato nella 
sua interezza. Molti anni fa pensavo che i matematici fossero persone il 
cui unico scopo nella vita fosse quello di esprimere cose facili in 
termini difficili. Soltanto molto dopo ho capito che le cosse non stanno 
così. Un buon matematico deve essere in grado di assimilare definizioni 
e astrazioni in poco tempo in modo da potersene servire immediatamente.
L'informatico, da matematico, deve avere la stessa capacità. Cambia solo 
la materia d'interesse.
E' per questo motivo che mi scandalizzo quando qualcuno mi dice che il 
codice non è chiaro.
Dopo aver detto che A_{BCD} := A(f(B),C)+D, mi aspetto di poter usare 
A_{} senza problemi.
Per es., ho ritenuto utile introdurre nel mio codice il costrutto
for_in (index, bitmap)
   

:=
{
   tmp = bitmap;
   unsigned index;
   while (tmp != 0)
   {
     index = find_first_and_zero(tmp);
     

   }
}
dove find_first_and_zero(tmp) determina l'indice del bit (in tmp) meno 
significativo uguale a 1, azzera tale bit e restituisce l'indice.
Nota: tmp è accessibile in 
, ma ha un nome molto lungo e improbabile.
Es:
Se bitmap = 110101,
for_in (i, bitmap)
   cout << i << endl;
stampa
0
2
4
5
Detto questo, mi aspetto che chiunque sia in grado di capire e usare 
for_in senza problemi.
Questo è quello che farei in matematica se dovessi riscrivere in 
continuazione la stessa cosa. Di conseguenza è quello che faccio anche 
quando programmo.
Le astrazioni introdotte fanno parte del programma non del linguaggio.
Non ho di fatto cambiato il linguaggio, ma il programma. Questo è un 
punto che il 90% di voi sembra non capire. Pazienza.
Avete praticamente trasformato un difetto in una regola.
Un grave difetto di molti linguaggi è che non è possibile introdurre le 
astrazioni in modo naturale.
Per es. M = {{a,b,c,d},{e,f,g,h},{i,j,k,l}} rappresenta una matrice in 
modo meno naturale di
a b c d
e f g h
i j k l
E' bene inserire astrazioni che rispecchino il proprio modo di pensare.
Astrazione dopo astrazione, si arriverà a programmare usando un 
linguaggio che non sembrerà più il C++.
Prendete un libro di matematica su un qualche argomento che non 
conoscete e andate verso le ultime pagine. Cosa trovate? Equazioni 
lunghe e difficili? Raramente. Quello che troverete è forse una formula 
del tipo:
f = [SS V_a]_b
Dire, a questo punto, "non si capisce niente" è da ignoranti.
Purtroppo, molte persone tenteranno di leggere il libro e si perderanno 
dopo le prime 100 pagine. La matematica è difficile. E' un dato di 
fatto. Significa che l'autore ha fatto un pessimo lavoro?
Può darsi, ma solitamente significa che non tutti sono in grado di 
acquisire una simile mole di informazioni con sufficiente precisione.
Chi riuscirà a studiare tutto, si ritroverà tra le mani strumenti molto 
potenti e sarà in grado di esprimere in modo semplice concetti di una 
complessità molto elevata.
Purtroppo, una simile elasticità mentale si acquisisce. Non basta essere 
intelligenti (è una condizione necessaria, ma non sufficiente).
Quando si lavora a un progetto di programmazione molto grande, è normale 
iniziare a creare definizioni, nuove astrazioni, ecc...
L'ideale sarebbe creare proprio un linguaggio apposito. Purtroppo, il 
C++ non è all'altezza da questo punto di vista (pochissimi linguaggi lo 
sono), ma cerco ciononostante di sfruttarlo al massimo. E' per questo 
motivo che limiterò l'uso del C++ alla parte di livello più basso.
Questo è il mio pensiero. Non ho nessuna intenzione di convincere altri 
a pensarla come me. Questo è semplicemente il mio modo di lavorare.
Kiuhnm

Quindi, io ti consiglierei di non rispondere !!! ROTFL !!! 
Ragazzi, sono anni che tale "Kiuhnm" imperversa per i gruppi dicendo
di lavorare a progetti supersegreti di cui non può parlare.  Ora si è
inventato d'essere un ricercatore.  Lasciatelo fa', è un troll ;-)
Secondo me non ha mai scritto 'na riga di codice...