Interesting take on the PLO - page 10
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
I don't like this design at all in terms of readability and clutter
I agree)))
The only justification for this is debugging)
I don't like this design at all in terms of readability and clutter
that was originally my question
the last examples are@fxsaber's statement that there will be 100% different codes at runtime. i posted the disassembler from the debugger a couple pages ago - the codes are 90% the same
I'm not talking about failing to return simple constructs that read without problems
the developers wrote somewhere and here similar information
only found this:
switch is a safe goto that uses a jump table. That is, the 'case' address is calculated usingan integerkey in switch. Because of this switch is extremely efficient even compared to if-else, not to mention more advanced collections like dictionaries.
Doesn't this have the negative effect of writing any quality code with the expectation that "the compiler will brush it up to the optimum"?
With one style of writing, you know for sure that the compiler will do the right thing. With another style you just have to trust that the compiler is smarter.
Given cross-platform, different compilers, etc., I choose to be aware of what you are doing in the code.Only the compiler knows exactly what it will do. Today's compilers have staggering euristics. They adapt to the average coder and already know better what he or she needs. The best thing a compiler can do is write simple, straightforward code with short functions. It is easier and more efficient for the compiler to analyse the source code graph consisting of many function nodes to build the resulting program. This can only have a positive impact on performance as the needed functions are inlined in the right places.
switch is a safe goto that uses a jump table. That is, the 'case' address is calculated fromthe integerkey in switch. Because of this, switch is extremely efficient even compared to if-else, not to mention more advanced collections like dictionaries.
cool! this is useful information
thanks!
Many people recommend writing small classes. The same Eckel says: "create classes for a single, clearly defined purpose".
I'm working on an EA right now, and I'm going to write a little simplification for an example. There is one of parameters "Reach max stoploss". When getting SL it should work as return counter up to zero and stop EA's work, and when getting TP it should reset to initial value, with value displayed on the panel.
I have made a separate class for this counter. It turns out that it changes from several points, from OnInit when setting input parameters and from the panel input field after order closing (sl and tp change value differently). Also, the main function is called from OnTick() to keep track of the maximum number of stoplosses to stop the EA.
The class seems to be very simple. But it turns out that this small class affects other objects located in the panel (input box, buttons). It affects the operation of other functions. And when there are a dozen of such small classes, it is already difficult to track which functions change the object or which methods of some objects can change the state of other objects.
I want to know how to organize the interaction of objects with each other in the best way to reduce the confusion, are there any good articles or books with examples of codes, diagrams on this subject and good explanations? Please share what helped anyone to learn how to write well designed architectures.
I don't like this design at all in terms of readability and clutter
Taste and color.... all felt-tip pens are different.
It was a contrast to the "little monster":
Forum on trading, automated trading systems and trading strategy testing
Interesting opinion about OOP
fxsaber, 2021.01.31 01:09
A little monster.
Logical operations allow for concise writing when using different settings via macros. But it's a horror, of course.
Taste and colour.... all felt-tip pens are different.
Not true. They only vary in colour, but they all taste the same...))))
I don't like this design at all in terms of readability and clutter
Why?
On the contrary, with two "ifs" it's much easier than with the "or" operator.
It's easier to trace one condition first, and leave the function if it's true, and then check another condition, and leave too, if it's true, than try to guess the result of a complex condition with logical "or" (which can be easily confused with "and"), and trace both ways of return.
It's pretty funny to read below that "the justification for such is debugging", because it means that such code is much more understandable (otherwise why is it in debugging ?).
"Apotheosis" I consider one expression by fxsaber, about which he himself could not say how it works, stating simply that "the code has been repeatedly tested, and it works". That, in my opinion, should not be the case:
ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType) { const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE); const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE); return((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN) || ((iFillingMode & (otfFilingType + 1)) != otfFilingType + 1)) ? (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT)) ? ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK)) : otfFilingType); };This code checks ifthe otfFilingTypeorder can beexecuted, and returns it if it is available on strSymbol, otherwise it is correct.
I have absolutely no idea how it works. And only rely on fxsaber's authority.
Maybe someone can explain ?