Features of the mql5 language, subtleties and tricks - page 213

New comment
 
A100 #:

And there is no need to change the behaviour of existing functions - it is enough to add new correct functions (with some prefix/suffix) and declare the previous ones obsolete with a corresponding warning

Destroy the whole sense of FileReadArray? Think of these functions as a backup of a piece of memory. Just bytes.

 
fxsaber #:

Destroy the whole point of FileReadArray? Think of these functions as a backup of a piece of memory. Just bytes.

So you want to first create difficulties for yourself through private, const and then heroically overcome them through "direct" memory access?

I have a different approach - if such a need arises, it means that the program was improperly designed from the very beginning

 
A100 #:

I.e. you propose to first create difficulties for yourself via private, const

I always get great benefit from private/const. They allow you to control the architecture of the program very well.

and then heroically overcome them with "direct" memory access?

No overcoming. Everything is very simple and logical.

My approach is different - if such a need arises, it means that the program was wrongly designed from the very beginning.

I understand that they are ready to write everything in a heap (without private/const), depriving convenience of architectural control for the sake of "purity" of OOP.

 
Ilyas #:

The File... appeared when privacy and constancy didn't exist, we didn't think to change this behaviour yet, as we don't consider it critical.

CharArray<->Struct appeared recently, but they work fine with private/const. Hopefully they won't be revised.

 
For code cleanliness, serialization and deserialization methods should be written for structures. Then there will be no privacy conflict, and constant fields are not constant if they can be changed during deserialization
 
fxsaber #:

I understand that you are ready to write everything in a heap (without private/const), depriving convenience of architectural control for the sake of "purity" of OOP.

You misunderstand - from OOP point of view the object is self-sufficient (it does not need external functions) - therefore there is no conflict with private. And if there is a conflict with const, as correctly noted:

It is you who have artificially made them so
 
fxsaber #:

I understand that you are ready to write everything in a heap (without private/const), depriving convenience of architectural control for the sake of "pure" OOP.

You are willing to use any loopholes of direct memory access out of convenience instead of using less convenient but safer canonical approach.

 
TheXpert #:

rather the opposite. you are willing to use any loopholes of direct memory access out of convenience instead of using the less convenient but safer canonical approach.

Two requests:

  1. Show the code for saving and loading the structure.
  2. An example of the dangers of the non-canonical approach.
 

Well, that's a fierce bug. Example:

class C{
   static uint count;
   const uint number;
public:
   C():number(++count){PrintFormat("C[%i]",number);}
  ~C(){PrintFormat("~C[%i]",number);}
   uint Number() const {return number;}
};
uint C::count=0;

void OnStart()
{
  C c[3]={};
  for(int i=0;i<ArraySize(c);Print(c[i++].Number()));
}
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]

The memory is allocated, the destructor is called when it is released (which hints at the expected behaviour according to RAII), but the constructor is forgotten to be called when the object is created)))

 

I have not seen it before.

1...206207208209210211212213214215216217218219220...255
New comment
Reason: