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
Oh, ora capisco.
Renat, ho un suggerimento da molto tempo, ed è esattamente sull'argomento. Per favore, fai un named typing per gli array, almeno per quelli statici (tutti gli altri tipi lo hanno già).
Cioè possibilità di dichiarare per esempio: typedef Int8 = int[8];.
Si può fare facilmente attraverso le strutture. Non lo complicheremo affatto.
Questo è facilmente realizzabile attraverso le strutture. Non complichiamo troppo le cose.
Bene, facile, è quello che facciamo! Ma di cosa ho bisogno? Una cosa semplice ?
Non pensi che il tuo rasoio Occam e il nostro (utente) rasoio Occam siano due rasoi molto diversi. Tu con il tuo minimalismo, tendi a creare un tale surplus negli utenti, che Occam dovrebbe impiccarsi al recinto più vicino.
Se ci tenete così tanto alla semplicità, allora rendete possibile passare i soliti subarray nelle funzioni! Tutti saranno felici, e i minimalisti sono felici.
// A proposito, funziona bene in F4 - anche per quelli dinamici. :)
Statico, naturalmente.
Oh, fantastico. È facile. È quello che facciamo! Ma di cosa ho bisogno? Sul piano ?
Le strutture che ho proposto sono un modo standard di creare nuove entità.
Non c'è bisogno di eccitarsi per niente.
Attualmente, in mql5, dobbiamo fare un sacco di passi in più e scrivere un sacco di codice storto a causa dell'impossibilità di passare subarray nelle funzioni.
State parlando di puntatori a blocchi di memoria incontrollabili, il che è completamente vietato in MQL5.
In MQL5 ogni oggetto/tipo deve essere controllabile - questo è un requisito diretto per la sicurezza della lingua.
Se avete bisogno di passare parte di un array, dovreste usare il passaggio di riferimento all'array stesso e la sua posizione. Questo vi darà il pieno controllo sull'array stesso.
State parlando di puntatori a blocchi di memoria incontrollabili, il che è completamente vietato in MQL5.
In MQL5 ogni oggetto/tipo deve essere controllabile - questo è un requisito diretto per la sicurezza della lingua.
2. Se volete passare parte di una matrice, usate passare un riferimento alla matrice stessa e la posizione nella matrice. Questo funzionerà per il controllo completo dell'array stesso.
Inoltre, è l'unico posto dove la denominazione non è implementata, quindi si adatta bene all'ideologia dell'universalizzazione delle entità linguistiche.
2. Tutti uguali: in primo luogo, è storto, e in secondo luogo, non è affatto universale. Suggerisci un modo(1) per copiare un mql-array bidimensionale in un buffer OpenCL senza inutili riscritture e wrapping in strutture, o(2) usando (per un uso veloce) la tua funzione ArrayCopy(...) per array non uniformi.
// Scusate per la bruschezza del post precedente. Davvero inutile. Mi sono eccitato al "non complichiamo le cose". In quanto porta solo a complicazioni.
2a. Penso che il tuo "vincolo di monodimensionalità" per funzioni come ArrayCopy() possa essere attenuato in molti casi in modo indolore con una clausola elementare nei commenti: "La funzione funziona anche con gli array multidimensionali, purché l'array multidimensionale sia copiato nella sua interezza. "
Molti problemi scomparirebbero. // Ma non tutti, naturalmente.
1. Questo era il mio suggerimento di introdurre la denominazione e quindi la tipizzazione rigida, soprattutto perché questo è l'unico posto non coperto dalla denominazione, quindi si adatta bene all'ideologia di universalizzazione delle entità linguistiche.
Temo che non abbia voluto notare la coincidenza della descrizione:
Il secondo modo è molto più pulito, potente e controllabile. Non c'è alcuna ragione per inventarne un'altra più debole usando il metodo esistente.
2. fare la stessa cosa. Tutti uguali: primo, è storto, e secondo, non è affatto universale. Suggerisci un modo(1) per copiare un mql-array bidimensionale in un buffer OpenCL senza inutili riscritture e wrapping in strutture, o(2) per usare (per la velocità) la tua funzione ArrayCopy(...) per array non dimensionali.
In primo luogo, non è storto. In secondo luogo, la sicurezza è superiore a qualsiasi metodo di ottimizzazione nello stile dell'accesso diretto e incontrollato alla memoria. Cioè, la domanda "come posso versare direttamente un blocco binario in un'entità supervisionata" è una domanda generale e fondamentale (poco risolvibile) per tutti i linguaggi.
Se avete a che fare con trasferimenti di array tra diversi sistemi (in OpenCL), è importante pensare a una struttura dati semplice e direttamente compatibile.
Guardate la più semplice classe CLBufferWrite multi-typed function bound per un facile trasferimento di dati.
State parlando di puntatori a pezzi di memoria non controllati, il che è completamente vietato in MQL5.
E a proposito, stai condensando. Il compilatore conosce la dimensione dell'array che viene passato nel punto in cui il parametro viene passato.
Genera anche un errore quando si cerca di farlo. :) Un'altra cosa è che bisognerebbe introdurre una parametrizzazione implicita supplementare ad ogni chiamata di funzione (più o meno come mi consigli di fare esplicitamente). Ma la soluzione da parte vostra sarebbe molto più universale - per esempio, usando la vostra libreria standard di funzioni e oggetti. Le stesse ArrayCopy() e FileWriteArray() funzionerebbero senza problemi.
Puoi accompagnare le tue affermazioni con semplici esempi, per le persone come me. MetaDriver ti capisce, ma la gente come me non capisce di cosa stiamo parlando senza esempi? E vuoi essere consapevole di quello che sta succedendo.
Temo che questo sarà un sostituto della documentazione. Cercate in una ricerca - c'è solo una tonnellata di informazioni là fuori.
Accesso sicuro ad alcuni membri dell'array:
Tenendo conto che il compilatore è molto affilato per le funzioni in linea, infatti, la funzione può essere completamente costruita nel luogo della chiamata e tutto l'overhead sarà ridotto a zero.
Ciò significa che, in MQL5, non si può avere paura di scrivere piccole funzioni "corrette" - hanno un destino standard full inline con l'ottimizzazione appropriata.
Questo significa che i costi di trasferimento dei parametri e di indicizzazione sono ridotti.
E a proposito, stai condensando. Il compilatore conosce la dimensione dell'array che viene passato al momento del passaggio dei parametri.
Da quando tutti gli array sono diventati statici, così come tutti gli indici e le dimensioni?
Poiché gli array sono quasi sempre dinamici e gli indici sono variabili, non possiamo fare alcun controllo statico serio al momento di una chiamata. Dovete solo fare controlli meta/rtti ed è per questo che è così importante avere accesso all'intero oggetto/descrizione e non lavorare su un pezzo di memoria a caso.
Le stesse ArrayCopy() e FileWriteArray() funzionerebbero senza problemi.
Non preoccupatevi, tutto è stato pensato molto tempo fa.
Le conseguenze della rottura dei principi di sicurezza che conosciamo molto bene è il modo "in aprile abbiamo risolto altri 12 bug critici per uscire dalla macchina virtuale e ottenere il controllo del sistema".