[C++] Operazione logica or

[nicone 91]

salve a tutti io ho un problema con l'operazione logica di or

while(i<=14)||(p==Vett[i+1].Cognome){

questo è il codice mi da un errore dicendo di esprimere qualcosa prima || e poi mi dice che devo mettere un ; prima della parentesi graffa

mi sapreste dire come fare per risolvere questo problema.
grazie in anticipo per le vostre risposte

[Alex'87]

Originariamente inviato da nicone 91

while(i<=14)||(p==Vett[i+1].Cognome){

Mancano delle parentesi tonde:

while ((i <= 14) || (p == Vett[i + 1].Cognome)) {
...

[nicone 91]

ah ecco cosa mancava grazie mille

[linoma]

Metti prima p e poi i

[nicone 91]

linoma se inverto la p con la i mi da errore e poi risolverlo devo convertire in intero la p (che è una variabile di tipo char)e la stringa Vett ma facendo cosi quando effetuo la chiamata della funzione il programma si chiude, anche se tengo lo stesso problema se li lascio cosi cmq adesso ti posto la funzione cosi si capisce meglio il mio problema

void cerca(int n, Contatto Vett[]){
int i,j;
int s=14;
char p[100];
printf("dammi il cognome che stai cercando\n");
scanf("%s",&p);
while ((atoi(p) < s) || (i==atoi(Vett[i].Cognome)))
{
i++;
if(strcmp(p,Vett[i].Cognome)==atoi(Vett[i].Cognome)){
printf("il cognome trovato è:\n");
stampa(n,Vett);
}else{
printf("\nERRORE: nessun elemento corrisponde a quello che stai cercando\n\n");
system("PAUSE");
break;
}}}

[linoma]

Scusami avevio letto male

[nicone 91]

non ti preoccupare e normale avendo messo solo una parte del codice

[MdE2005]

Originariamente inviato da nicone 91
linoma se inverto la p con la i mi da errore e poi risolverlo devo convertire in intero la p (che è una variabile di tipo char)e la stringa Vett ma facendo cosi quando effetuo la chiamata della funzione il programma si chiude, anche se tengo lo stesso problema se li lascio cosi cmq adesso ti posto la funzione cosi si capisce meglio il mio problema

Non è questo il modo corretto per esprimersi, rileggi con attenzione ciò che hai scritto.

[deleted_29]

Dò un suggerimento generale, che in questo caso non si applica, o meglio potrebbe, ma in realtà no

---
Il suggerimento è questo: mai usare OR, se non con grandissima attenzione alle ottimizzazioni del compilatore, nella fattispecie "valutazione completa delle espressioni booleane", e l'uso di funzioni o procedure nelle condizioni.

Sostanzialmente se nella condizione OR c'è un "qualcosa" (procedura, funzione, ma anche operatore nel caso di C++) che altera "qualcos'altro" (es. variabili globali) ed il compilatore NON fa la valutazione completa, si possono avere effetti collaterali negativi.

Questi capitano, in generale, quando si compila lo stesso progetto in ambienti diversi (=ottimizzazioni diverse)

supponiamo qualcosa del genere (i<3) || ( cerca(25)==1 )

se la funzione "cerca" fa un'alterazione che io mi aspetto venga sempre eseguita (aggiornare puntatore, fare query etc), potrebbe non essere in realtà mai eseguita da un compilatore ottimizzante quando si accorge che la prima parte dell'espressione è vera.
In pratica fa "i<3"? sì? -> non serve valutare la parte rimanente, in quanto l'espressione OR è già computabile (vera in questo caso)
---
In generale, quindi, suggerisco di NON usare espressioni OR contenenti procedure o funzioni, a meno di non essere assolutamente sicuri che non abbiano side effects, o di aver forzato a "mano" la valutazione completa.

Non usandole mai -> si risolve il problema alla radice.

Non un gran suggerimento... però l'esperienza consiglia di tenerlo presente

EDIT: per inciso il frammento di codice è,ovviamente, adatto solo per fini didattici, non assomiglia a un "vero" programma, però immagino che si tratti di esercizietti basici

[MItaly]

se la funzione "cerca" fa un'alterazione che io mi aspetto venga sempre eseguita (aggiornare puntatore, fare query etc), potrebbe non essere in realtà mai eseguita da un compilatore ottimizzante quando si accorge che la prima parte dell'espressione è vera.

Non è questione di compilatore ottimizzante, gli operatori booleani logici di C e C++ valutano sempre la parte a sinistra e non valutano mai l'espressione a destra se il risultato è già deciso; ciò vale anche se non c'è alcuna ottimizzazione attiva.
Lo standard infatti dice (§6.5.13.4)

Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated.

e a §6.5.14.4

Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares unequal to 0, the second operand is not evaluated.

Questo, oltre che far risparmiare eventuali valutazioni di funzioni inutili, consente di scrivere codice che darebbe problemi con gli operatori logici bit a bit (che valutano sempre ambo i lati dell'espressione); considera ad esempio codice di questo genere:

int * ptr=NULL;
// ...
if(ptr!=NULL && *ptr==10)
{
    // ...
}

Se il && valutasse l'espressione di destra anche dopo aver visto che l'espressione di sinistra è falsa, si avrebbe un segmentation fault per aver dereferenziato un puntatore NULL.

Il discorso che fai sui side-effects è giustissimo, ma è buona norma evitare le funzioni con side effects in generale nelle istruzioni condizionali (salvo casi particolari); d'altra parte gli operatori logici in questione non vanno così "a caso" come hai scritto, la valutazione del codice a destra è sempre condizionata dal risultato di sinistra, e sapendo che questo è deterministico (non dipende da ottimizzazioni del compilatore) lo si può sfruttare in casi particolari.

Un ultimo dettaglio: per come funzionano gli operatori in questione, di fatto sono dei branch nascosti; un'espressione del tipo

if(a && b)
{
    /* ... */
}

di fatto si traduce (a livello di codice macchina) in una roba equivalente a

if(a)
{
    if(b)
    {
        /* ... */
    }
}

il che, se a e b sono espressioni di valutazione immediata, può essere più lento rispetto ad un semplice and bitwise (i branch in generale sono più costosi di una semplice &); vale la pena di tenerne conto qualora si debba lavorare su micro-ottimizzazioni in codice eseguito in un tight loop.