Errori, bug, domande - pagina 493
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
Non discuto.
ma in questo modo
c'è comunque un arrotondamento, dovrebbe farlo?
Sviluppatori.
Ho accidentalmente messo in loop l'elaborazione dei tick in Expert Advisor, dopo di che è apparso un errore critico di stack overflow.
Il problema è che non ci sono informazioni specifiche nel messaggio su cosa e dove è successo esattamente.
Suggerisco di chiarire il testo di questo messaggio, se possibile si vuole catturare tali problemi (come chiamare un metodo di classe da un metodo chiamato) in fase di compilazione.
Il motivo per cui iCustom() assegna valori arbitrari a quelle celle del buffer, che in realtà non sono state riempite con nulla, non mi è chiaro, così come il motivo per cui non può essere evitato in alcun modo.
Suppongo che abbia qualcosa a che fare con l'allocazione della memoria per l'array di dati corrispondente del buffer dell'indicatore.
Una tale operazione di iCustom(), quando è impossibile determinare l'origine e la verità dei dati, mi sembra inammissibile e crea ulteriori rischi per l'utente.
Se iCustom() assegna comunque alle celle del buffer valori arbitrari e incoerenti con quelli reali,
perché non assegna valori uguali a Empty_Value a queste celle come è implementato in MT4?
Così almeno il loro status sarebbe chiaro.
Sviluppatori.
..........., se possibile vogliono catturare problemi come questo (come chiamare un metodo di classe da un metodo chiamato) al momento della compilazione.
Io sono contrario. Renderebbe il compilatore eccessivamente complicato e quindi meno affidabile.
È compito del programmatore tracciare la ricorsione errata.
Ma vorrei che il messaggio di errore contenesse il nome della funzione che ha fatto traboccare lo stack.
Nessuno, tranne l'autore, può decidere con quali valori di buffer inutilizzati debbano essere riempiti. Tu dici Empty_Value, ma io, per esempio, voglio che sia 0, o qualcos'altro. Qualsiasi valore vogliate, inizializzatelo con esso.
Questo è corretto e logico. Ma il problema è che le celle del buffer che l'utente non ha riempito con nulla (!), la funzione iCustom() riempie periodicamente con spazzatura arbitraria a sua discrezione. È normale che sia così?
Io sono contrario. Renderebbe il compilatore esorbitantemente complesso e quindi meno affidabile.
Sta al programmatore tracciare la ricorsione errata.
Ma vorrei che il messaggio di errore contenesse il nome della funzione che ha fatto traboccare lo stack.
Sì, volutamente non complichiamo il motore di lavoro (è nativo 32/64 dopo tutto) con meta-informazioni.
La ricorsione è di solito facile da catturare - dipende direttamente dalla dimensione delle variabili locali, e ci sono pochi posti del genere in un programma.
Questo è corretto e logico. Ma il problema è che le celle del buffer, che l'utente non ha riempito con nulla (!), la funzione iCustom() riempie con spazzatura casuale a sua discrezione.
Se l'indicatore personalizzato non riempie correttamente il suo buffer, questo indicatore personalizzato è colpevole.
E se questo indicatore personalizzato invia i suoi risultati attraverso iCustom, è doppiamente colpevole, poiché inganna gli utenti.
Se un indicatore personalizzato non riempie correttamente il suo buffer, significa che questo indicatore personalizzato è colpevole.
E se questo indicatore personalizzato dà i suoi risultati attraverso iCustom, è doppiamente colpevole, perché inganna gli utenti.
Se un indicatore personalizzato non riempie correttamente il suo buffer, la colpa è di questo indicatore personalizzato.
E se questo indicatore personalizzato invia i suoi risultati attraverso iCustom, è doppiamente colpevole, perché inganna gli utenti.
Ancora non capisco, cosa vi impedisce di rendere il programma non solo efficiente, ma anche conveniente? Se ricordo bene, il ragionamento per l'assenza di inizializzazione integrata dei buffer degli indicatori nella 5 è di ottimizzare la velocità. In questo caso lo sviluppatore dell'indicatore deve codificare da solo le stringhe di inizializzazione ("zeri"), che prima in quattro veniva eseguita dal kernel. Quindi, l'efficienza risultante non sembra migliorare, e l'usabilità ne soffre. Ma visto che è stato deciso di farlo in questo modo per qualche motivo, perché non renderlo facoltativo? Cioè potremmo introdurre un'altra #proprietà, specificando se i buffer devono essere inizializzati automaticamente o no.
Per riassumere, ripeterò l'idea che ho già espresso una volta: il compito della piattaforma, che è MT, è di proteggere l'utente (il programmatore) da possibili "errori" il più possibile.
Questo è corretto e logico. Ma il problema è che le celle buffer che l'utente non ha riempito (!) con nulla, iCustom() riempie periodicamente con spazzatura arbitraria a sua discrezione.
In realtà, è una regola comune: l'inizializzazione degli array è a discrezione dell'utente. Un array non inizializzato contiene valori casuali dalla memoria allocata. L'utente potrebbe avere una buona ragione per non inizializzare l'array inutilmente (per risparmiare tempo, per esempio). A volte risparmio tempo in questo modo quando sono sicuro che non dovrò leggere e "mangiare" quella spazzatura prima che ci sia la vera informazione.
Non vedo alcuna malizia da parte di MQ. Mi opporrei piuttosto se iniziassero "profilatticamente" a rallentare i miei programmi.