È ora di convertire le librerie in MQL5 - pagina 6

 
victorg:

In realtà, non c'è niente di sbagliato nell'accesso diretto ai dati.

Andiamo, narratore. La sicurezza è fondamentale. Tanto più quando il terminale con EAs e indicatori è in funzione 24 ore al giorno, e tutto è "appeso" con denaro reale e accesso. In questo caso, il programmatore non dovrebbe avere paura di usare una dll di terze parti, e quello che usa "insidiosamente" tali dll - "hara-kiri".
 

Dobbiamo separare le aree in cui "esagerare è meglio che non esagerare" è davvero applicabile e utile.

Secondo me, il principio "Safety Comes First" dovrebbe essere applicabile solo al Mercato e al Cloud. L'acquirente sta pagando per un prodotto che è naturalmente assicurato e quindi chiuso, e non c'è modo di controllare la sicurezza del prodotto. Pertanto, il mercato deve dare all'acquirente una garanzia al 100% della sicurezza di tutti i prodotti. E nel caso del cloud, tutti i computer cloud devono essere protetti al 100% contro il malware.

E in tutti gli altri casi, non riguardanti la distribuzione di prodotti software attraverso il mercato e il loro acquisto attraverso questo servizio, così come l'utilizzo del cloud, l'intera responsabilità per l'uso di dll non provati è dell'utente.

Con questo approccio, si possono evitare molti degli attuali problemi di degrado delle prestazioni e della funzionalità del linguaggio MQL5 a causa del "Safety first".

 
joo:

Pertanto, il mercato è obbligato a dare al cliente una garanzia del 100% sulla sicurezza di tutti i prodotti.

Come immagina questo? Tu, come venditore, affitti un marketplace da MK e pretendi che il padrone di casa sia responsabile al 100% della sicurezza del tuo prodotto, mentre chiudi parte del codice nel dll. Assurdo.
 
abolk:
Come ve lo immaginate? Tu, come venditore, stai affittando un mercato da MK e pretendi che il padrone di casa sia responsabile al 100% della sicurezza del tuo prodotto. Questo è assurdo.

Il mercato dà già una garanzia di sicurezza del prodotto, perché vieta l'uso di dll esterne da parte dei prodotti. E gli stessi programmi MQL5 lavorano nella sandbox interna sicura del terminale.

Non sapevi di questo?

 
victorg:

Presumo che dovrete cambiare molte cose.

E tu provaci.

Le DLL ragionevoli sono originariamente scritte per l'integrazione con altri sistemi e quindi hanno semplici interfacce esterne sotto forma di funzioni grezze. I loro file di intestazione sono semplici.


In realtà, non c'è niente di sbagliato nell'accesso diretto ai dati. Dopo tutto, MetaTrader stesso è probabilmente scritto in C/C++, e niente. Inoltre, i linker di solito permettono anche inserti di assemblaggio, e anche questo va bene. Ricorda che MetaTrader in esecuzione sotto Windows utilizza direttamente o indirettamente un sacco di dll di sistema, e non c'è niente di sbagliato in questo.

Temo che lei non sia affatto nella conversazione sulla sicurezza e non abbia idea di cosa stiamo parlando.


Non credo che dovremmo privare l'utente del suo diritto di scelta. Mi piacerebbe molto l'opzione in cui posso prendere, per esempio, ALGLIB-dll e il suo file header nativo(i) e usare una libreria affidabile senza toccarla con le mie "mani malvagie", ma semplicemente dire al compilatore MQL che questo è un file header C++, non quello MQL.

Prendete la libreria e usate le funzioni esportate dagli header con piccole (se necessario) modifiche.

Pensare che si possa prendere qualsiasi file *.H da un linguaggio C/C++ insicuro e usarlo in un altro linguaggio (anche più sicuro) è un completo fraintendimento delle lingue. Si può sognare, ma non si può pretendere.

La libreria ALGLIB è già stata portata a MQL5 e sarà disponibile nel codice sorgente.


Potrebbe sorgere la domanda: e se questa libreria fosse maligna e pericolosa? Ma ho deciso di usarlo io stesso.

Fate questa domanda qualche milione di volte per capire il numero di utenti finali di MetaTrader, e valutare la qualità del pensiero e la responsabilità di quei milioni di intervistati.

Per questo ci prendiamo cura della sicurezza originale dell'ambiente.


In altre parole - MQL può essere sicuro quanto si vuole, ma se ho osato usare qualcosa di esterno, allora è un mio problema.

Usa la DLL - nessun problema per uso personale.
 
Renat:

Pensare che si possa prendere qualsiasi file *.H da un linguaggio C/C++ non sicuro e usarlo in un altro (e ancora più sicuro) linguaggio è un completo fraintendimento delle lingue. È possibile sognare, ma è impossibile esigere.

La libreria ALGLIB è già stata portata in MQL5 e sarà disponibile nel codice sorgente.

Forse ho espresso la mia opinione invano (tra l'altro non ho preteso nulla). E sulla mancanza di comprensione delle lingue, hai assolutamente ragione. Più leggo e capisco, meno capisco. Non capisco perché se si riscrive ALGLIB per mql5, e poi lo si compila con un compilatore esterno(visualc) in DLL, allora la libreria sarà più sicura da questo che in caso di compilazione diretta del codice sorgente originale della libreria in DLL in una volta sola?

Bene, ok. Che sia così.

 
victorg:

Non capisco perché se si riscrive ALGLIB in mql5 e poi si compila con un compilatore esterno(visualc) in una DLL,

Hai sbagliato un po'. La riscrittura in MQL5 è progettata per non usare DLL, ma per includere tutti i pacchetti matematici necessari direttamente nel codice sorgente MQL5.
 
Renat:
Abbiamo fatto un enorme lavoro di messa a punto del compilatore MQL5 per rendere più facile la conversione delle librerie esistenti scritte in altri linguaggi.

E lo sviluppo del linguaggio MQL5 continua. Nuove caratteristiche dovrebbero apparire presto, incluso un potente profilatore di codice.

Ora abbiamo due compiti da svolgere:
1) selezionare librerie di terze parti utili per la conversione
2) raccogliere volontari per realizzare progetti di conversione (noi li finanzieremo).

Vorremmo iniziare con una lista di potenziali progetti. Aiuto con link e brevi descrizioni, per favore.

Dal momento che ALGLIB è già stato portato apparentemente la domanda principale sull'argomento è"quale altra libreria Open Source gli utenti vorrebbero vedere?"

 
Urain:
Dal momento che ALGLIB è già in fase di porting apparentemente la domanda principale dell'argomento è "quali altre librerie open-source gli utenti vorrebbero vedere?"

Sì, l'ho chiarito nel mio primo post:

Ora siamo di fronte a due sfide:
1) scegliere librerie open-source utili per la conversione

 
Rosh:
Avete sbagliato un po'. La riscrittura in MQL5 è progettata per non usare DLL, ma per includere tutti i pacchetti matematici necessari direttamente nel codice sorgente MQL5.

Scusate, sono davvero confuso con la promessa capacità di compilare codice C/C++ in una DLL direttamente dal metaeditor.

Ma per me non è ancora chiaro, perché fare il porting, quando la libreria è già pronta all'uso come DLL? Si scopre - ho comprato un libro in un negozio e prima di leggerlo l'ho trascritto in un quaderno.

Devo aver sbagliato di nuovo qualcosa. Non scriverò più.

Motivazione: