Вопросы по ООП в MQL5 - страница 11

Новый комментарий
 
Dmitry Fedoseev:

И кстати о птичках.. дескрипторы это тоже указатели. И знаете ли, от самого слова, ничего не меняется, дескриптор ли, указатель, идентификатор.

физическая реализация этих слов уже давно скрыта от пользователей

имхо примерно так:

- дескриптор - привязан к методу реализующему этот функционал в системе

- хэндл, все как у дескриптора, но его реализует ОС

- указатель и идентификатор подразумевают, что это работа с физической памятью

 
Dmitry Fedoseev:

А если в функцию надо передать указатель, чтобы в функции создать объект, вот так работает:

class CObj{
   public:
   int f(){
      return(33);
   }
};

CObj * obj;

void OnStart(){
  z(obj);
  delete(obj);
}

void z(CObj & o){
   o = new CObj();
}
Вот собственно и все, что вы хотели знать про ООП, но боялись спросить)))

Угу, гениально.

Вот эти 17 строчек это собственно все, что вам надо знать про квалификацию Федосеева как программиста.

2019.07.05 15:19:56.309    invalid pointer access in 'test13.mq5' (11,5)

 
Vasiliy Sokolov:

Добрый день. Память компьютера имеет одинаковую производительность не зависимо от того, используется ли она в контексте стека или кучи. Сам менеджмент динамической памяти зависит от реализации сборщика мусора: например это может быть подсчет ссылок как в Питоне (более медленный вариант) или анализ эпох поколений объектов с обходом графа исполнения в background процессе (Net CLR). Какой вариант используется в MQL неизвестно, однако можно предположить его крайнюю эффективность, т.к. пользователю MQL5 доступен оператор delete напрямую, что значительно упрощает работу самого GC. В связи с этим Ваши опасения по поводу overhead'a при использовании new напрасны - смело используйте динамическую память.

Что касается "переполнения стека" то встретится с этим кейсом в современных системах можно разве что при использовании сложной рекурсии или при ошибке в рекурсивном алгоритме. Современная программа всегда работает в защищенном режиме OC в виртуальном адресном пространстве, с динамической подгрузкой страниц памяти, поэтому не переживайте: стек не закончится:)

Благодарю за доходчивое пояснение.
Я почему то думал, что в mql вызов на стек происходит быстрее, чем на кучe, тем более мы не знаем реализацию сборщика мусора.
По этому и возникли такие вопросы, что лучше использовать для быстродействия создания объекта, авто или динамику.
Да я понимаю что всё зависит от конкретной задачи, но к примеру возьмем отправку торговых заявок.
И поставим себе задачу, максимально правильно создавать объекты для быстродействия выполнения обработки.
Имеем пользовательский класс описанных методов торговых заявок.
Количество экземпляров класса и его методов по сути нам известно.
И как вы предполагаете "стек не закончится"

Отсюда интересует вопрос, каким способом лучше создавать и удалять объекты? Автоматически или динамически?
Мне пришла мысль вообще сделать синтетическое управление автоматическими объектами.
То есть объявлять автоматические объекты, в теле пользовательской функции.
Тем самым объект создается на стеке(в теории быстрее чем куча), за контроль автоматического удаления не беспокоимся, так как переменная объекта объявлена в пользовательской функции
и автоматический объект будет дополнительно проконтролирован на уничтожение, самой пользовательской функцией, по правилу динамических переменных в функциях.
Вот и хотелось бы выслушать адекватные мнения участников данной ветки, кто что думает по этому поводу.

 
TheXpert:

Угу, гениально.

Вот эти 17 строчек это собственно все, что вам надо знать про квалификацию Федосеева как программиста.

2019.07.05 15:19:56.309    invalid pointer access in 'test13.mq5' (11,5)

Удивительно. А у меня и компилируется без ошибок (прямо сейчас) и работает правильно.

Следующий раз рисуй в фотошопе.

 
Roman:

Благодарю за доходчивое пояснение.
Я почему то думал, что в mql вызов на стек происходит быстрее, чем на кучe, тем более мы не знаем реализацию сборщика мусора.
По этому и возникли такие вопросы, что лучше использовать для быстродействия создания объекта, авто или динамику.
Да я понимаю что всё зависит от конкретной задачи, но к примеру возьмем отправку торговых заявок.
И поставим себе задачу, максимально правильно создавать объекты для быстродействия выполнения обработки.
Имеем пользовательский класс описанных методов торговых заявок.
Количество экземпляров класса и его методов по сути нам известно.
И как вы предполагаете "стек не закончится"

Отсюда интересует вопрос, каким способом лучше создавать и удалять объекты? Автоматически или динамически?
Мне пришла мысль вообще сделать синтетическое управление автоматическими объектами.
То есть объявлять автоматические объекты, в теле пользовательской функции.
Тем самым объект создается на стеке(в теории быстрее чем куча), за контроль автоматического удаления не беспокоимся, так как переменная объекта объявлена в пользовательской функции
и автоматический объект будет дополнительно проконтролирован на уничтожение, самой пользовательской функцией, по правилу динамических переменных в функциях.
Вот и хотелось бы выслушать адекватные мнения участников данной ветки, кто что думает по этому поводу.

Вы правильно думали. Обращение к объектам созданным через new работает значительно медленнее. А сборщика мусора здесь нет.

 
Igor Makanu:

физическая реализация этих слов уже давно скрыта от пользователей

имхо примерно так:

- дескриптор - привязан к методу реализующему этот функционал в системе

- хэндл, все как у дескриптора, но его реализует ОС

- указатель и идентификатор подразумевают, что это работа с физической памятью

Да и нет нам никакой разницы, как там оно работает.

 

Подскажите еще по одному вопросу. Если создать дочерний класс CMyButton от CButton, то создать кнопку, а потом менять ее свойства вне класса можно. Ниже это сделано в OnInit().

Но если я хочу внутри дочернего класса сделать дополнительные поля, а также использовать в новых функциях встроенные свойства класса CButton, то как это правильно реализовать?

В классе CButton член класса m_button объявлен в private секции. 

#include <Controls\Button.mqh>

class CMyButton : public CButton
{ 
  private: 

  public: 
              CMyButton(void){}; 
             ~CMyButton(void){}; 
             
        bool    isPrevState;        // состояние кнопки на предыд.тике, true - была нажата     
        void    setButton();        // создаем кнопку
        void    setProp();          // задаем в ходе программы свойства
}; 

void CMyButton::setButton(void)
{
  // как в этой функции создать кнопку? Я не могу вызвать метод Create()
}

//+------------------------------------------------------------------------------------------------------------------+
//| 
//+------------------------------------------------------------------------------------------------------------------+

CButton Btn;
CMyButton MyBtn;

int OnInit()
  {
  
   Btn.Create(0, "Btn", 0, 50, 50, 120, 75);
   Btn.Text("Standart");
   MyBtn.Create(0, "MyBtn", 0, 50, 200, 150, 225);
   MyBtn.Text("MyBtn");
   
   return(INIT_SUCCEEDED);
  }
 
Dmitry Fedoseev:

Ага, удаляет и пишет сообщение об утечке памяти, только что бы программистам, пишущим советников, было не скучно жить.

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

И кстати о птичках.. дескрипторы это тоже указатели. И знаете ли, от самого слова, ничего не меняется, дескриптор ли, указатель, идентификатор.

Утечка идет из адрессного пространства процесса. Вот когда в цикле while(true) допустишь утечку, то в конечном итоге твоя программа ляжет при очередном выделении памяти из кучи, которая кончилась.
 
Dmitry Fedoseev:

А у меня и компилируется без ошибок (прямо сейчас) и работает правильно.

Ага, уже два несвязанных человека фотошопят креш твоего кода )

Твой код не может работать правильно, это очевидно по самому коду ))

 
TheXpert:

Ага, уже два несвязанных человека фотошопят креш твоего кода )

Твой код не может работать правильно, это очевидно по самому коду ))

Только что, то же самое хотел написать))))
1...456789101112131415161718...96
Новый комментарий
Причина обращения: