Особенности языка mql5, тонкости и приёмы работы - страница 213

Новый комментарий
 
A100 #:

А менять поведение существующих функций и не требуется - достаточно добавить новые правильные функции (с каким-нибудь префиксом\суффиксом), а предыдущие объявить устаревшими с выдачей соответствующего предупреждения

Уничтожить весь смысл FileReadArray? Воспринимайте эти функции, как бэкап куска памяти. Просто байты.

 
fxsaber #:

Уничтожить весь смысл FileReadArray? Воспринимайте эти функции, как бэкап куска памяти. Просто байты.

Т.е. Вы предлагаете сначала создать себе трудности через private, const, а затем героически их преодолевать путем "прямого" доступа к памяти ?

У меня другой подход - если возникает такая потребность - значит программа изначально неправильно спроектирована

 
A100 #:

Т.е. Вы предлагаете сначала создать себе трудности через private, const

Получаю всегда огромную пользу от private/const. Позволяют очень хорошо контролировать архитектуру программы.

, а затем героически их преодолевать путем "прямого" доступа к памяти ?

Никакого преодоления. Все очень просто и логично.

У меня другой подход - если возникает такая потребность - значит программа изначально неправильно спроектирована

Понимаю, что готовы писать все в кучу (без private/const), лишаясь удобства архитектурного контроля ради "чистоты" ООП.

 
Ilyas #:

Функции File... появились, когда приватности и константности не было, пока не думали менять это поведение, т.к. не считаем это критичным.

CharArray<->Struct появились недавно, но пашут отлично с private/const. Надеюсь, пересматриваться не будут.

 
Для чистоты кода, для структур нужно писать методы сериализации и десериализации. Тогда конфликта с приватностью не будет, а константные поля значит не константные, если они могут быть изменены при десериализации
 
fxsaber #:

Понимаю, что готовы писать все в кучу (без private/const), лишаясь удобства архитектурного контроля ради "чистоты" ООП.

Не правильно понимаете - с точки зрения ООП объект самодостаточен (ему не требуются внешние функции) - соответственно конфликта с private не возникает. А если возникает конфликт с const, то как правильно замечено:

это вы их искусственно сделали таковыми
 
fxsaber #:

Понимаю, что готовы писать все в кучу (без private/const), лишаясь удобства архитектурного контроля ради "чистоты" ООП.

скорее наоборот. вы готовы использовать любые лазейки прямого доступа к памяти из удобства вместо использования менее удобного, но более безопасного канонического подхода.

 
TheXpert #:

скорее наоборот. вы готовы использовать любые лазейки прямого доступа к памяти из удобства вместо использования менее удобного, но более безопасного канонического подхода.

Две просьбы:

  1. Покажите код сохранения и загрузки структуры.
  2. Пример опасности неканонического подхода.
 

Так это же баг лютый. Пример:

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]

Память выделена, деструктор при ее освобождении вызван (что про ожидаемое, в соответствии с RAII, поведение, как бы намекает), а вот конструктор при создании объекта, вызвать забыли)))

1...206207208209210211212213214215216217218219220...263
Новый комментарий
Причина обращения: