Interesting take on the PLO - page 10

 
Vitaly Muzichenko:

I don't like this design at all in terms of readability and clutter

I agree)))

The only justification for this is debugging)

 
Vitaly Muzichenko:

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

 
Igor Makanu:

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.

 
fxsaber:

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.

 
Vasiliy Sokolov:

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.

 
This is not an OOP problem, but a problem with the general approach to creating EAs. We should count the number of stoplosses by history. In general, this is what a man's head is for, there is no universal solution.
 
Vitaly Muzichenko:

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.

  static bool VirtualOrderSelect( const TICKET_TYPE Index, const int Select, const int Pool = MODE_TRADES )
  {
    return(VIRTUAL::SelectOrders ? VIRTUAL::SelectOrders.OrderSelect(Index, Select, Pool) :
           #ifdef  VIRTUAL_SNAPSHOT_REFRESHTIME
             VIRTUAL::SnapshotPtr ?
             #ifdef __MQL5__ // Выбор по тикету в MT5 - разнообразный набор вариантов.
               (Select == SELECT_BY_TICKET) ? ::OrderSelect(Index, Select, Pool) && VIRTUAL::SnapshotPtr.CopyOrder()
                                            :
             #endif // #ifdef __MQL5__
                                              ((((Index == INT_MIN) || (Index == INT_MAX)) && (Pool == MODE_TRADES) &&
                                               ::OrderSelect(Index, Select, Pool) &&
                                             #ifdef  VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder(true))
                                             #else // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder())
                                             #endif // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY #else
                                               || VIRTUAL::SnapshotPtr.OrderSelect(Index, Select, Pool))
                                  :
           #endif // #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
           #ifdef __MQL5__
             #ifdef __MT4ORDERS__
               ::OrderSelect(Index, Select, Pool)
             #else // __MT4ORDERS__
               false
             #endif // __MT4ORDERS__
           #else // __MQL5__
             ::OrderSelect(Index, Select, Pool)
           #endif // __MQL5__
           );
  }

Logical operations allow for concise writing when using different settings via macros. But it's a horror, of course.


 
Andrey Khatimlianskii:

Taste and colour.... all felt-tip pens are different.

Not true. They only vary in colour, but they all taste the same...))))

 
Vitaly Muzichenko:

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 ?