Errori, bug, domande - pagina 2564
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
?
è una situazione strana, tutto al di fuori della classe ha funzionato per molto tempo con gli staichiq. e io sto solo facendo un gran casino per questo.... Solo per divertimento, riproducete voi stessi il codice:
Vedete un'istanza dell'oggetto? ed esiste in MQL ;)
SZZ: Ed esiste a livello di aiuto... qual è il tuo problema con me?
https://www.mql5.com/ru/docs/basis/oop/staticmembers
Tutte le stesse regole si applicano alle statiche (private, protected, public), solo che non richiedono la creazione di un oggetto.
Non in generale: per esempio, uno statik pubblico non può essere limitato in una classe derivata
hmmm... Come spiegare l'assurdità della situazione... Ti ho suggerito di leggere i post degli amministratori (sviluppatori), ti ho mostrato l'aiuto che hanno scritto, cosa vuoi da me con le tue foto?
Non penso perché sia così, leggo il forum e l'aiuto, e faccio come raccomandato dagli sviluppatori. Se pensate che sia necessario, scrivete al "comitato per la protezione degli standard C++", all'ONU... Beh, almeno l'amministratore nel PM, se debole, ma poi bloccare i messaggi degli sviluppatori e ottenere il vostro modo!
ZSY: io in qualche modo riesco a inserire il codice sorgente e non le immagini, perché il tuo non l'ha fatto?
2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4
L'unico bug nel codice è nell'accesso al metodo privato. Questo bug è apparso di recente.
La funzione ChartOpen restituisce sempre 0 nel servizio. Anche se il grafico stesso si apre.
L'unico bug nel codice è nell'accesso al metodo privato. Questo bug è apparso di recente.
Pensavo di aver dimenticato qualcosa, così ho riletto come si comporta la statica in C#https://metanit.com/sharp/tutorial/3.6.php
I membri statici della classe sono comuni a tutti gli oggetti della classe, quindi dovete riferirvi ad essi con il loro nome di classe:
Si noti che i metodi statici possono fare riferimento solo a membri statici della classe. Non possiamo indirizzare metodi non statici, campi, proprietà all'interno di un metodo statico.
In MQL, la statica è inizializzata prima di eseguire OnInit(), ora discutiamo la visibilità globale dei metodi privati per la statica.... questo comportamento della statica in MQL - se si usa la statica, significa che non usiamo le caratteristiche di protezione dei dati di una classe, imho
quanto è grande l'insetto? - il modo in cui gli sviluppatori lo faranno, ho detto che il comportamento nelle operazioni di contesto è determinato dal programmatore (l'operatore di risoluzione del contesto è l'operatore con la massima priorità nel linguaggio! ), e il compilatore aiuterà correttamente - beh, come succede))
funziona così?
nel complesso, fa il lavoro
PS: aggiornato a 2145 - il codice con la statica si comporta allo stesso modo, se rimarrà così per mezzo anno, si scoprirà che questo è il comportamento previsto della statica ;)
UPD: ricordate, come si dice in gergo tutto questo - dirty tricks! ))) - Cercate molti esempi sul web, dove questo comportamento è accettato come standard del linguaggio, e dove è legato a un compilatore specifico del produttore. In Python, eval() non interrompe effettivamente l'esecuzione lineare del codice? - Beh, alcuni lo fanno e altri no perché il comportamento è imprevedibile.
UPD: controllare su 2145 la mia domanda di un mese fahttps://www.mql5.com/ru/forum/320733#comment_12989063
https://www.mql5.com/ru/forum/320733#comment_12958594
non è cambiato nulla, su un controllo di tipo bool il compilatore non ha imparato a scrivere avvertimenti - questo è molto spiacevole, stavo cercando un errore nel mio codice, anche se ero sicuro che il compilatore MQL controlla sempre la corrispondenza dei tipi
Quanto è un bug? - Qualunque cosa gli sviluppatori facciano, è così che sarà.
È ovvio che il bug sarà risolto.
Non è cambiato nulla, il compilatore non ha imparato a scrivere avvertimenti su bool quando controlla i tipi
Il casting automatico dei puntatori e dei tipi numerici in bool è molto comodo.
non è cambiato nulla, su bool quando controlla i tipi il compilatore non ha imparato a scrivere avvertimenti - questo è molto spiacevole, stavo già cercando un errore nel mio codice, anche se ero sicuro che il compilatore MQL controlla sempre strettamente la corrispondenza dei tipi
Non c'è perdita di dati durante questa fusione. O 0 o non 0.
Un altro caso è quando double -> qualsiasi tipo intero (fino a int32 incluso)
Con questa fusione, non c'è perdita di dati. O 0 o non 0.
Un'altra cosa è quando si fa il casting di double -> qualsiasi tipo intero (fino a int32 incluso)
ma il contrario?
Stavo cercando un bug nel mio codice
All'inizio ho scritto un test, ma ho usato prima int , poi ho rinunciato ad usare bool, ma non ho sistemato tutto il codice, non ricordo, ma era così:
Sono abbastanza pronto per tale comportamento ora, ma perché sto scrivendo su di esso ... beh, nel controllo delle condizioni MQL in if() - controlla strettamente i tipi? qualsiasi uso di operazioni non booleane emette un avviso? - E nello stesso modo in cui ho scritto in C# in VS2017 - il mio codice di esempio non si compila e MQL non lancia un avvertimento. A mio parere, per coloro che sono nuovi alla programmazione in MQL, tale comportamento implica alcune sorprese.
È ovvio che il bug sarà risolto.
Non voglio discutere, ma la mia opinione è che non si dovrebbe fare affidamento sul controllo da parte del compilatore quando si lascia la classe tramite la statica così come l'uso dell'operatore di risoluzione del contesto,
cioè se scrivete un metodo/campo statico o usate ::: - non fate affidamento sul compilatore