Discussione su "Come scrivere una DLL per MQL5 e scambiare dati in 10 minuti". - pagina 3
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
Sarà possibile creare semplici DLL con i mezzi di mcl5? In parole povere, scriverli in un editor e compilarli...?
E dove trovare il compilatore e il linker con tutte le librerie di Windows e il Platform SDK?
Si può fare molto più facilmente - scaricare e installare Visual Studio 2008 Express gratuito e fare le DLL necessarie in esso.
E dove trovare il compilatore e il linker con tutte le librerie di Windows e il Platform SDK?
Puoi fare qualcosa di molto più semplice - scaricare e installare Visual Studio 2008 Express gratuito e usarlo per fare le DLL necessarie.
La questione non è essere liberi...
La questione è che ho dovuto scaricare e installare un mostro per il bene di un piccolo.
Comunque, grazie per la tua risposta...
Un'altra piccola domanda...
Cosa bisogna scaricare da questa pagina:
http://www.microsoft.com/express/Downloads/
è
Visual C++ 2008 Express Edition
o tutti
Tutti - Installazione offline del file immagine ISO
?
Visual C++ 2008 Express Edition
È sufficiente.
Grazie, lo sto scaricando ora.
Ma è tutto in un file (800 mb).
Non mi fido molto dell'installazione della rete...
Abbiamo metodicamente creato 4 generazioni di linguaggi di trading dal 2001 con un'enorme comunità di trader. I concorrenti stavano morendo, i loro linguaggi di controllo non si stavano sviluppando, ma noi stavamo lavorando, lavoravamo e continueremo a lavorare.
Ma dove trovare compilatore e linker con tutte le librerie di Windows e Platform SDK?
Puoi fare molto più facilmente - scarica e installa il gratuito Visual Studio 2008 Express e usalo per creare le DLL necessarie.
Prima di tutto dobbiamo scoprire quali sono i "loro" linguaggi di controllo, delimitare le "loro" funzioni e poi scoprire cosa significa il "loro" sviluppo. Non parlo di concorrenti, ma di lingue. Come potete vedere, i programmi e i sistemi di trading vivono tra una varietà di shells circostanti, anche sotto winndas abbiamo C++/.net/JScript/shell script/ e altri, e giustamente sottolineato sopra, che non ha senso cercare di trascinare tutto all'interno della piattaforma di trading - creare qualche DLL, o fornire timer, scambio di dati e così via dovrebbe essere basato su strumenti già disponibili e ampiamente conosciuti del sistema operativo stesso, add-ons liberamente disponibili. moduli (ad esempio, il framework .net in costante sviluppo con le sue versioni runtime) + i più potenti strumenti di sviluppo e debugging - perché preoccuparsi di una bicicletta o di una prossima generazione di Trading OS come Chrome OS ovunque?
IMHO lo sviluppo del linguaggio di scrittura TC dovrebbe servire i compiti specifici del commercio, cioè la raccolta di informazioni, l'analisi, i test, la gestione del commercio e l'integrazione con altri sistemi - tutto questo può e IMHO dovrebbe essere fatto ad un alto livello di strumenti di sviluppo moderni, cioè integrando ed estendendo il quadro standard selezionato usando metodi generalmente accettati (OOP, ecc.). Il compito non è quello di scrivere una piattaforma autonoma e autosufficiente su una miscela di C / C + + o qualsiasi altra cosa, ma prima di tutto una scrittura di alta qualità le basi della piattaforma di trading, i suoi servizi, API e interfaccia utente. Il compito di integrare la piattaforma di trading che abbiamo già, anche se è la migliore, è inevitabile. Un semplice esempio è AutoTrading. Probabilmente è chiaro che l'avvio di Windows con autologin e terminale МТТ nella cartella Start del sistema operativo - è già un anacronismo dannoso, abbiamo bisogno di un normale servizio di Windows per far funzionare i robot indipendentemente dai login degli utenti (server?). Giocare con le DLL potrebbe non essere necessario, basate la piattaforma su, diciamo, .net. Scrivere in C#, managed C++, Delphi, J++ e un sacco di altra roba. IMHO questo era dovuto alla paura degli sviluppatori di rendere troppo estensibile e flessibile una piattaforma che sarebbe stata molto più difficile da controllare rispetto a qualsiasi sandbox sottoscrivibile.
Quante volte ho sentito esattamente queste parole - perché reinventare la ruota, perché non prendere java, Net, ecc. come base. E io stesso ho iniziato a scrivere le mie prime strategie di trading esattamente 11 anni fa, quando non c'era nessuna idea di API per un conto di trading.
Prendete le API pronte di diversi broker e fate le vostre soluzioni, per l'amor di Dio.
Solo che la pratica dimostra che solo i programmatori chiedono API grezze. E per un programmatore pronto ad andare "mano nella mano" per scrivere il sistema, ci sono 1000 trader che vogliono testare le loro strategie su un quadro pronto e sicuro.
I neofiti chiedono l'API, a volte la ottengono, e poi passa un mese di agonia e capiscono che l'API per scrivere anche la più semplice strategia di trading non è sufficiente, e tutto ciò di cui hanno bisogno è un ambiente di mercato già pronto. Si scopre che non c'è mercato per i programmi più semplici senza API, che gli acquirenti non sono interessati a essere legati a un terminale, ecc. E il desiderio di scrivere di più viene invariabilmente perso.
Il normale sviluppo di un ambiente di autoprogrammazione nelle piattaforme di trading richiede un framework sicuro con una sandbox rigida, altrimenti nessuno condividerà gli script per paura dei trojan. Se non condividono, la comunità morirà e così la lingua.
La comunità non è composta da 50, 100 o 500 programmatori (che saranno felici di pulirti/strofinare i piedi), ma da decine e centinaia di migliaia di commercianti che usano sistemi con un minimo di complessità.
A proposito, solo MQL4.community riceve più di 30 000 visitatori unici ogni giorno, e stimiamo che ci siano ben oltre un milione di utenti di MetaTrader 4 in tutto il mondo.
Nella build 240 i wrapper sono stati semplificati, il tasso di chiamata è ora di 19.911.000 chiamate al secondo.
Quante volte ho sentito queste esatte parole - perché reinventare la ruota, perché non usare java, Net ecc. come base. Ma io stesso ho iniziato a scrivere le mie prime strategie di trading esattamente 11 anni fa, quando non c'era praticamente nessuna API sul mio conto di trading.
Questo è un modo di dire. E anche dopo 11 anni qualcosa doveva cambiare :)
Prendete le API pronte di diversi broker e fate le vostre soluzioni.
A volte la gente è tentata di farlo. E perché non cercare di migliorare la situazione, soprattutto se la posizione lo permette?
Ma la pratica dimostra che solo i programmatori chiedono l'API grezza. E per ogni programmatore che è pronto a scrivere "mano a mano" il sistema, ci sono 1000 trader che vogliono verificare le loro strategie su un quadro pronto e sicuro.
Crudo è un concetto relativo. Tuttavia, a volte un'API è meglio di niente. O peggio, sono costretti ad usarli a causa delle limitazioni intrinseche della piattaforma.
Sul tema dei quadri "sicuri", il dibattito è aperto, cosa proteggiamo, da chi e come.
I neofiti chiedono un'API, a volte la ottengono, poi passa un mese di agonia e si rendono conto che l'API non è sufficiente per scrivere anche la più semplice strategia di trading, e hanno bisogno di un ambiente di mercato pronto per tutto il resto. Si scopre che non c'è mercato per i programmi più semplici senza API, che gli acquirenti non sono interessati a essere legati a un terminale, ecc. E il desiderio di scrivere di più viene invariabilmente perso.
Questo è ciò di cui stiamo parlando - non API, ma framework estensibile con interfacce specializzate, su misura per compiti specifici! Legarsi al terminale non interessa a nessuno, ma i broker "amano" legarsi. Naturalmente, bisogna dispiacersi per loro.
Un normale ambiente di sviluppo per l'autoprogrammazione nelle piattaforme di trading richiede un framework sicuro con una sandbox rigida, altrimenti nessuno condividerà gli script per paura dei trojan. Se non condividono, la comunità morirà, e così la lingua.
Mi permetto di non essere d'accordo con te, ma sono aperto a cambiare idea e a modificare la mia posizione. Citate un esempio dalla storia delle piattaforme commerciali di autoprogrammazione in cui la potenza (eccessiva) di un particolare ambiente di sviluppo disponibile ha superato la paura degli utenti e ha condannato tale ambiente alla distruzione e all'estinzione. Sono d'accordo che permettere di spuntare le chiamate DLL in MT non risolve praticamente nulla a questo proposito, specialmente se c'è una ragione giustificabile per ricorrere alle DLL.
La comunità non è composta da 50, 100 o 500 programmatori (che vi puliranno/strofineranno volentieri i piedi), ma da decine o centinaia di migliaia di commercianti che usano sistemi con un minimo di complessità.
È allora che bisogna decidere fin dall'inizio, piuttosto che cercare di sgrammaticare l'OOP per un ragazzo che ha una vaga idea di programmazione. Parlando specificamente dei sistemi di autotrading, dai ai trader un minimo di complessità e crescerà in un massimo di complessità sotto la coperta di un'interfaccia grafica (e, alla fine, un incubo per il programmatore del sistema) - non è più facile non ingannare nessuno e permettere la massima flessibilità nella creazione di sistemi, piuttosto che cercare di trovare un compromesso di ciò che è permesso, in modo che funzioni per il 95% dei casi (leggi - "tutti tranne qualche spennatore sono molto felici, questo è il modo in cui la nostra azienda si posiziona")?
A proposito, MQL4.community riceve oltre 30 000 visitatori unici ogni giorno e abbiamo stimato che ci sono oltre un milione di utenti di MetaTrader 4 in tutto il mondo.
Cosa farete con queste statistiche? Chiaramente, dal punto di vista del business, le società di brokeraggio hanno il 98% di poveri trader che hanno comprato un bell'Expert Advisor nel terminale di trading con senza dubbio alcune grandi caratteristiche...
Cara Pisara,
Cerchiamo di essere chiari: c'è una discussione tra un teorico e un praticante. Certo, nessuno vi proibisce di lottare per la "pace nel mondo", ma tenete conto di più fattori del "perché non migliorare?
Ради бога, берите готовые API разнообразных брокеров и делайте свои решения.
Иногда к этому склоняют. А почему бы не постараться улучшить ситуацию, тем более если позиция позволяет?
Questo è quello che ho scritto - non lo userete, perché non volete impegnarvi nel lavoro di routine. Dovrete avere tutto su un piatto d'argento - tutti gli indicatori, tutto l'ambiente di mercato, tutta la storia in diversi periodi, ecc. E ci dovranno essere dei grafici, perché non potrete manipolare tutti gli indicatori nella vostra mente.
Quindi, in effetti, avete bisogno di un terminale completo. E noi ve lo diamo: MetaTrader 5 + MQL5 + DLL. Chiamatelo framework o dateci semplicemente il terminale in codice sorgente/componenti (perché è questo che volete).
I programmatori pensano erroneamente che sia "potente" essere in grado di scrivere script per sistemi di trading in linguaggi nativi non protetti, e poi sono sorpresi che nessuno usi le loro creazioni. Ecco perché muoiono prima di nascere. Quelli che hanno sviluppato e creato comunità di utenti, pensano molto più profondamente (perché hanno ricevuto i colpi prima) e non fanno questi errori.
La chiamata di DLL controllata (disabilitata di default) è accettabile, ma scaricare DLL fatte da qualcun altro nel vostro terminale di trading è un buco grande come un Internet Explorer 6 senza patch.
Per informazioni, le statistiche di Google Trends sui terminali di trading con automazione: