Errori, bug, domande - pagina 706
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
1.
Per creare array di puntatori a strutture (array) e poi inizializzarli for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. per conservare array solidi (impacchettati) di dati significativi.
Importante quando si ha a che fare con l'uscita dei dati nei buffer grezzi di OpenCL (o l'invio alla DLL, la scrittura su file, ecc.)
Allo stesso tempo, è possibile riordinare gli accessi ai dati (per esempio, quando si ordinano i puntatori) senza riscrivere i dati.
Un linguaggio con esecuzione sicura non dovrebbe esporre/dare accesso diretto.
Le classi hanno più protezioni ed è per questo che hanno una maniglia.
Non ci saranno maniglie per altri oggetti, perché la sicurezza è più importante.
In OpenCL, qualsiasi tipo di dati può essere usato per passare dati, incluse le strutture. Lì si usa il void*. Basta preparare dati uniformi nel formato richiesto e mettersi al lavoro. Anticipando la domanda "non voglio farlo in quel modo, voglio farlo a modo mio", risponderei che non puoi farlo - la sicurezza è più importante.
1. qualsiasi tipo di dati può essere usato per il trasferimento dei dati in OpenCL, incluse le strutture. Lì si usa il void*. Basta preparare dati uniformi nel formato richiesto e mettersi al lavoro. Anticipando la domanda "non voglio farlo in quel modo, voglio farlo a modo mio", risponderò che non puoi farlo - la sicurezza è più importante.
2. un linguaggio con esecuzione sicura non dovrebbe esporre/dare accesso diretto.
Il punto è che per tutte le classi, comprese le più primitive, il compilatore mql5 crea VMT, con il corrispondente campo nascosto negli oggetti (puntatore a VMT). E questo puntatore nel buffer grezzo (file) è troppo per me. Non solo è spazzatura che occupa spazio, ma rompe anche l'allineamento dei pacchetti in modo inappropriato (i buffer OpenCL hanno un allineamento a 128 bit). Questo è il punto. Le classi sono allettanti da usare: sono comode per lavorare in mql. Ma... vedi sopra.
In Delphi c'è un buon esempio di implementazione alternativa. VMT e, di conseguenza, i puntatori a VMT appaiono nelle classi solo dopo che il primo metodo virtuale appare nella gerarchia della classe. Se fosse lo stesso in mql5, la situazione sarebbe molto più gestibile. Si potrebbero usare classi senza metodi virtuali invece di strutture e non ci sarebbero "add-on" dannosi per la struttura.
Ora ho incontrato una situazione in cui l'implementazione di una classe astratta (destinata all'ereditarietà) che incapsula un array di strutture non si presta a servizi ereditati (come l'ordinamento). Sostituire un array di strutture con un array di classi risolve questo problema, ma crea un altro.... (vedi sopra).
E non sto chiedendo nessun "accesso diretto" e non sono interessato a nessun indirizzo aritmetico. Perché spaventate i bambini per niente? :) l'handle di mql5 non è nemmeno vicino a un puntatore "grezzo". E se lo è (surrettiziamente) - quindi il vero buco di sicurezza è qui, non nell'implementazione degli handle (pseudo puntatori) a qualsiasi dato utente.
---
In questo momento le tue strutture sono effettivamente classi senza funzioni virtuali (e VMT, rispettivamente). Quindi va bene, basta aggiungere alcune funzioni di classe (handle) a loro. Allora non avrete neanche così tanto bisogno di puntatori agli array (potete avvolgerli in strutture se necessario).
Il punto non è che voglio farlo a modo mio; il punto è che per tutte le classi, comprese le più primitive, il compilatore mql5 crea VMT con il corrispondente campo nascosto negli oggetti (puntatore a VMT). E questo puntatore nel buffer grezzo (file) è troppo per me. Non solo è spazzatura che occupa spazio, ma rompe anche l'allineamento dei pacchetti in un modo completamente inappropriato (i buffer OpenCL hanno un allineamento a 128 bit). Questo è il punto. Usare le classi è allettante: sono comode per lavorare in mql. Ma... vedi sopra.
In Delphi c'è un buon esempio alternativo di implementazione. VMT e, di conseguenza, il puntatore a VMT appare nelle classi solo dopo che il primo metodo virtuale appare nella gerarchia della classe. Se fosse lo stesso in mql5, la situazione sarebbe molto più gestibile. Si potrebbero usare classi senza metodi virtuali invece di strutture e non ci sarebbero "add-on" dannosi per la struttura.
Ora ho incontrato una situazione in cui l'implementazione di una classe astratta (destinata all'ereditarietà) che incapsula un array di strutture non si presta a servizi ereditati (come l'ordinamento). Sostituire un array di strutture con un array di classi risolve questo problema, ma crea un altro.... (vedi sopra).
E non sto chiedendo nessun "accesso diretto" e non sono interessato a nessun indirizzo aritmetico. Perché spaventate i bambini per niente? :) l'handle di mql5 non è nemmeno vicino a un puntatore "grezzo". E se lo è (surrettiziamente) - quindi il vero buco di sicurezza è qui, ma non nell'implementazione degli handle (pseudo puntatori) a qualsiasi dato utente.
Si vuole costruire un sistema complesso con dati astratti (il che significa già un sacco di metadati e relazioni interne) e poi consegnarlo a un ambiente OpenCL incontrollato dove può essere modificato in modo ingannevole. Ecco perché permettiamo solo a semplici oggetti e array di operare liberamente senza la possibilità di sovrascrivere le tabelle virtuali.
In realtà stai chiedendo indirettamente l'accesso diretto attraverso la "libertà delle costruzioni astratte". Questo è un argomento che abbiamo esplorato bene e coperto architettonicamente per il bene della sicurezza. Le classi in MQL5 vivono secondo le proprie regole con un'enfasi sulla sicurezza. Altri tipi non avranno maniglie. Invece degli handle per i tipi e le strutture semplici, potete usare gli indici negli array.
Le maniglie stesse in MQL5 sono corrette (crescendo da uno), potete controllare.
1. vuoi costruire un sistema complesso con dati astratti (il che significa già un sacco di metadati e relazioni interne), e poi consegnarlo a un ambiente OpenCL incontrollato dove può essere modificato in modi intelligenti. questo è il motivo per cui permettiamo solo a semplici oggetti e array di operare liberamente senza la possibilità di sovrascrivere le tabelle virtuali.
2. in realtà stai chiedendo indirettamente l'accesso diretto attraverso la "libertà delle costruzioni astratte". Questo argomento è ben studiato da noi e coperto architettonicamente per il bene della sicurezza. Le classi in MQL5 vivono secondo le proprie regole con un'enfasi sulla sicurezza.
Le maniglie in MQL5 sono corrette (crescendo da uno), potete controllarlo voi stessi.
Voglio passare dati rigorosamente puliti nel buffer senza metadati (handle). Non ho bisogno di questi metadati nel buffer, sono d'intralcio. E non potrò nemmeno metterceli - CLBufferWrite() non li lascerà entrare. E questo è corretto.
2. In realtà non sto chiedendo alcun accesso diretto, posso usare la DLL per l'accesso diretto (se ne ho bisogno).
aPointer = memcpy(a,a);
risolverà il problema di ottenere un puntatore grezzo. Renat, cerca di entrare nel vero problema. Non inventare nulla che non esista " realmente". Tutto ciò che esiste realmente - l'ho descritto direttamente e senza sottigliezze nella richiesta. Nel modo più costruttivo possibile e con una piena comprensione dei problemi di sicurezza.
3. È fantastico.
--
Non dovreste assolutamente fare la creazione e la cancellazione dinamica delle strutture (new, delete). Nemmeno in alcun modo. Allora non sorgeranno nemmeno problemi di sicurezza. Capisco qual è il problema "realmente" (per metterlo nella tua lingua). C'è un problema di definizione di un tipo reale per gli oggetti dinamici. Per le classi è molto probabilmente risolto analizzando un puntatore a VMT. Tuttavia: nessuna struttura dinamica, nessun problema.
Pensateci, cos'è un "manico" in relazione a un'entità di qualsiasi dimensione?
Si possono fornire handle a oggetti di numero ragionevole (classi, file, ecc.). Ma se andate in un'area di array di qualsiasi dimensione, qualsiasi handle ha solo la possibilità di essere un riferimento diretto a un pezzo di memoria. Altrimenti la tabella di mappatura "handle -> memory" consumerà ancora più memoria dell'entità a cui si fa riferimento.
E in base alla disposizione di sicurezza, non si possono avere handle che sono puntatori diretti alla memoria. Ecco perché non ci sono maniglie per "qualsiasi entità non limitata".
Renat:
1. si possono fornire maniglie a oggetti di numero ragionevole (classi, file, ecc.). Ma se andate in un'area di array di qualsiasi dimensione, qualsiasi handle ha solo la possibilità di essere un riferimento diretto a un pezzo di memoria. Altrimenti la tabella di mappatura handle -> memoria consumerà ancora più memoria dell'entità a cui si fa riferimento.
2. E in base alla clausola di sicurezza, non si possono avere handle che sono puntatori diretti alla memoria. Ecco perché non ci sono maniglie per "qualsiasi entità non limitata".
1. Costruttivo è una buona cosa. Stavo pensando. Il problema è stato sollevato esattamente in relazione alle strutture massicce. Per le strutture piccole il tempo di copia è comunque breve. Penso che i problemi possano sorgere qui solo a causa dell'irragionevolezza dell'utente, ma si può "stupidamente" riempire la memoria comunque (con buffer di indicatori, per esempio). Non suppongo che qualcuno preferisca lavorare con handle su strutture statiche senza alcuna particolare necessità. E se si fa un overflow di memoria, è colpa propria. Non preoccupatevi tanto delle sciocchezze popolari, non c'è modo di prevenire (e nemmeno di prevedere) tutto in ogni caso. :)
2. No, no. Non c'è bisogno di puntatori diretti, ma non sarebbe male avere degli handle, anche "per qualsiasi entità illimitata". L'importante è che non ci sia l'obbligo di usarli, così ci sarà abbastanza memoria per tutti. :)
Non capisco cosa stai abbaiando qui. Se volete delle maniglie, dichiarate le vostre strutture come classi, tutto qui.
Se volete un accesso diretto alla memoria, scrivete una DLL.
Non capisco perché ti stai rompendo il collo qui.
1. se volete delle maniglie, dichiarate le vostre strutture come classi, tutto qui.
2. se volete avere accesso diretto alla memoria, scrivete una DLL.
1. Questo è il punto: è problematico. Non ho bisogno di scrivere un array di classi nel buffer (ed è impossibile). Ho bisogno di scrivere strutture lì. E lo voglio rapidamente (senza effettivamente riscrivere da classi a strutture). E le maniglie sono necessarie per l'accesso riordinato (per l'ordinamento, inoltre, con chiavi diverse).
Un sostituto potrebbe essere la mia tabella di indicizzazione - ma allora non posso fare una classe che incapsuli il lavoro con un array di strutture con la possibilità di ereditarlo, insieme ai servizi un tempo prescritti (ordinamento e ricerca binaria).
2. Non lo voglio! !! Smettila di fare un caso per me su due piedi! :))
No, non faremo tali manipolazioni. Questo è un vero e proprio male, di cui saremo ritenuti responsabili fino alla fine.
La soluzione ideale sarebbe quella di classi parametrizzabili
class MyClass<T> { T MyArray[]; .... };Ma non ne parlo più, forse dovrei?