Errori, bug, domande - pagina 312

[Rashid Umarov]

Academic:

Questo avvertimento non dovrebbe essere dato, perché la funzione ObjectGetDouble passa un riferimento e l'istruzione if controlla la verità restituita da entrambe le chiamate, e quindi solo se entrambe le funzioni restituiscono true allora queste variabili sono gestite, il che significa che entrambe le variabili non possono non essere impostate al valore corretto.

Il compilatore non si espande così tanto per assicurarsi che queste variabili saranno necessariamente inizializzate come risultato di una chiamata a ObjectGetDouble. Provate invece a scrivere la vostra variabile, dove il valore del parametro di input passato per riferimento sarà impostato esplicitamente. Cosa dirà il compilatore?

[Academic]

Rosh:
Il compilatore non si espande abbastanza per assicurarsi che queste variabili saranno necessariamente inizializzate come risultato di una chiamata ObjectGetDouble. Provate invece a scrivere il vostro, dove il valore del parametro di input passato per riferimento sarà impostato esplicitamente. Cosa dirà il compilatore?

Rashid, non è affatto "coscienza", è matematica.

[Slava]

Academic:

Rashid, non è affatto "coscienza", è matematica.

1. Esiste una cosa come la "valutazione abbreviata delle espressioni logiche".

2. Il compilatore non può sapere con certezza se la variabile passata per riferimento sarà popolata.

3. Un avvertimento è proprio questo, un avvertimento per attirare la vostra attenzione sulla possibilità che si verifichi un problema.

[Rashid Umarov]

Academic:

Rashid, non è affatto "coscienza", è matematica.

Ok, definiamo una tale fusione

bool AlwaysGood( double & param)
  {
   return true;
  }

C'è una garanzia qui che la variabile param sarà inizializzata?

[Academic]

Rosh:

Ok, definiamo una tale ffruncture

C'è qualche garanzia che la variabile param venga inizializzata?

Questa è una funzione in cui il risultato "param" NON viene cambiato. Quindi qui l'avvertimento dovrebbe essere dato al 1000% :)

La soluzione standard qui è questa: se c'è un ramo di esecuzione del codice dove il valore non può essere cambiato, si considera che questa funzione non cambi il valore. E genererà un avvertimento.

Rashid, vuoi che prenda uno qualsiasi dei moderni compilatori C++ e C e compili tale codice e sono sicuro che nessuno di loro darà un avvertimento di sinistra.

Inoltre, se si hanno tali "problemi" con il rilevamento di queste cose, improvvisamente si comincia ad avere un dubbio molto forte che non ci sia alcuna ottimizzazione in quanto tale. O c'è?

[Slava]

Academic:

Rashid, vuoi che prenda uno qualsiasi dei moderni compilatori C++ e C e compili un codice simile e sono sicuro che nessuno darà un avvertimento sinistro.

Di cosa stiamo discutendo?

PS Ci sarà sicuramente un messaggio (forse qualche riga sotto)

[Slava]

Academic:

Questo non è chiaramente un miglioramento, soprattutto se ci sono tali "problemi" con il rilevamento di queste cose, allora si insinua il GRANDE dubbio che non ci sia alcuna ottimizzazione in quanto tale. O c'è?

La funzione ObjectGetDouble è fuori dal controllo del compilatore perché ha un'implementazione indipendente (cioè di libreria)

[Dmitriy Skub]

Academic:

Se guardate l'aiuto per ObjectGetDouble:

---

Restituisce vero o falso a seconda del successo della funzione. Se ha successo, il valore della proprietà viene messo nella variabile di destinazione, passata per riferimento dall'ultimo parametro.

---

Quindi, concludiamo che il riempimento della variabile di ricezione non è garantito in caso di errore. Ecco perché il messaggio del compilatore è valido.

IMHO.

[Sergey Chalyshev]

C'è qualcosa che non è sincronizzato nell'ultima build.

Fare un piccolo EA:

int OnInit()
  {
   Print("Все нормально!"); 
   return(0);
  }

Esecuzione del tester,

2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Tutto è OK!

Apporto modifiche al mio EA:

int OnInit()
  {
   Print("Тестер, Аууу, ты где?"); 
   return(0);
  }

Lo compilo, eseguo il tester e risponde:

2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 Tutto normale!

Aiuta solo a riavviare il terminale.

[Slava]

Serj_Che:

C'è qualcosa che non è sincronizzato nell'ultima build.

Facendo un piccolo EA:

Esecuzione del tester,

2011.02.22 11:54:21 Core 1 2011.02.07 00:00:00 Tutto è OK!

Apporto modifiche al mio EA:

Lo compilo, eseguo il tester e risponde:

2011.02.22 11:57:55 Core 1 2011.02.07 00:00:00 Tutto normale!

Aiuta solo a riavviare il terminale.

Mi dispiace. Una nuova build sarà rilasciata oggi o domani senza questo sfortunato errore.