C++ ... whats next? - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Hello,
I would suggest go for C and not C++
if you are wanting to use a broker that uses mql5 then it works with C#... MQL4 brokers (still most of them) use C++, while C# works with MQL5 or cAlgo from Spotware, so decide which broker you want to use first, find out what platforms they support, and then learn the language required...There is no need to go and learn c++ until you pass out, a lot of the grunt work is done for you within mql5... start writing trade strategies now, you can also try C# with ninjatrader from ninjatrader.com
Thanks Maxim,
As I don't have a formal computer programming education (... and as I'm now 45), I think that I will never be able to mix those things so much.
I selected C/C++ because it seems that they will be the key stones for my planned works for my retirement :) By mastering C/C++,
1. I think that I will be able to excel in coding EAs in MQL 5,
2. I think that I will be able to use C/C++ seamlessly with Matlab,
3. If needed, I will be able to move easily to GPU programming,
4. If really needed, I will be able to do some Windows tasks.
...
I decided to study concurrency in C++ after my introductory study mentioned in my original post and then later I think to study Open CL ... any gap here, any objection?
But you must be prepared for the following:
1) making every new DLL under MetaTrader is hard work
2) MT5 has improved security and prevents the use of debuggers
3) a long process cycle:
- Modified the C ++ source code
- launched a compilation ("make" the project)
- transferred the resulting DLL to MetaTrader
- Run scripts / indicators / experts for testing.
- any system error will require a restart MT - although it continues to work, but the environment of your DLL is "destroyed"
4) for each significant release of MetaTrader, you need to check the operation of ALL your DLLs
and finally - MQL works quickly with calculations and shifting the calculating part to the DLL is simply inefficient.
for a compact (and most importantly brief) record of algorithms and easy communication with the "outside world".
Those who worked with scripting languages, they know that they are very effective in terms of convenience and speed of development.
I chose tcl and make the ATcl library.
Before making such a choice it was necessary to conduct a rather serious study of the issue,
and considered many "candidates". Among them were python, rubj, javascript (ecma), lua and
even purely scientific julia and scilab (near matlab analogue).
If you are interested, I can tell you what and why it was eliminated.
I missed the MQL capabilities of a higher-level language
for a compact (and most importantly brief) record of algorithms and easy communication with the "outside world".
Those who worked with scripting languages, they know that they are very effective in terms of convenience and speed of development.
I chose tcl and make the ATcl library.
Before making such a choice it was necessary to conduct a rather serious study of the issue,
and considered many "candidates". Among them were python, rubj, javascript (ecma), lua and
even purely scientific julia and scilab (near matlab analogue).
If you are interested, I can tell you what and why it was eliminated.
Of course ... please.
I added your link to my favorites and I hope that I will look at the ATcl library soon just after my C++ study done.
Firstly, I ask you to excuse me - English is not my native language and I do not speak it well. Therefore, I first write large texts in Russian and then publish it in part with the help of google translate. Russian original of the following can look here: http://nektomk.ru/atcl:why
Here I quote only the abstracts from my entries, but still a large volume is obtained. I will be glad to any discussion and criticism - this will help me make the project better.
Why an additional language
Briefly, for what it would be desirable to use scripting language inside MQL:
algorithms are written very compactly and are quickly developed.
and fast mathematical calculations. Arrays are not first-class entities, but dynamic structures are rather difficult to program. For the sake of justice - it has justifications and partly it is solved by the «Standard Library»
trading platform language
only inside the graph and at the same time programmers calculate the pixels, I want to cry. 2018, the 21st century, trading platform. In any language there are 1-2-3 modern, full-featured, stable framework for user interfaces.
analytical software and so on. You need the means to interact with this
and all others easily clung to him already. All modern languages have mechanisms for adapting external modules from other languages.
Limitations and drawbacks of the solution
Of course, the solution will have obvious limitations and drawbacks, this too must be immediately understood and accounted for the scope of application:
this language with its libraries and tools on the computer.
* can not be sold through «market mql5.com»
MT Features and System Requirements
Known features of MetaTrader work, which significantly influence the choice of the language for embedding:
the main system requirement follows from this:
«should be able to run several independent instances of the interpreter (or virtual machine language) on 1 system thread.»
and one great wish (to make the impossible possible):
«it is desirable that the language / interpreter has a» continuation «that is, it allows the return of the intermediate result with the preservation of its own state»
User requirements (my)
To learn a new programming language is not so difficult, the more I have a presentation about their device, and I consistently looked at almost everything. Of course, I had my requirements / wishes for them (with a few explanations):
Forth, Lisp, C, C ++
Forth and Lisp immediately disappeared, the first is too low, the second is so sharply different from MQL that using it is a dissonance. Although anyone who wrote in MQL «translator of arithmetic formulas» or «calculator with brackets» almost realized one of them. depending on the applied method of parsing expressions
C and C ++, such interpreters, for example, Cling (https://root.cern.ch/cling) used in the analysis of CERN data, do not seem to be suitable. Using scripts like C ++ within a C ++-like language will not make the recording of algorithms easier or faster.
Remained the following group of popular languages: Python, Ruby, R, JavaScript, Lua, Tcl
I am ready to talk about the analysis of each of them in terms of integration with Metadrader.
But a little later, that there was time for discussing what was already said
Just write the code.
Practice makes perfect.
I am ready to talk about the analysis of each of them in terms of integration with Metadrader.
But a little later, that there was time for discussing what was already said
Thanks a lot for your post.
As I'm now just a reader -not writer- of MQL codes, I'm not in the position of discussing the thoughts in your post.
But, I would really like to read the opinions here of other experienced programmers.
So it's my opinion that once you understand OOP concepts and basic design patterns then it's time to dive into MQL
I agree.
Have a look at Python.
I agree.
I would suggest you search the CodeBase (see above) for various EAs and Indis and study them, start them change them and see what happens.
There are even single and series of articles (as well from above) like Graphical Interfaces or Cross Platform EAs with lots of described and commented code!
Strongly agree.
You will gain insights from others' code examples that you won't get in any book.
I would add to this: read the programming-related questions on this forum. Try to answer them.
My final comment:
You should be coding at the same time that you are reading. Leverage your book learning with experiential knowledge, and the only way to do that is to write code—even if it's bad code.