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

Новый комментарий
 
Igor Makanu:

речь о каких тоннах идет? все что проглядели, обо всем сообщит терминал, место где удалять тоже известно - OnDeint() .... беседа свелась к обсуждению  сферического коня в вакууме? )))

Нет. Конь пусть скачет где положено.

А мы говорим о создании заранее неизвестных объектов. Причём не только о свойствах не известно, но и о количестве самих, разом созданных объектов.

Для одного мы конечно можем создать указатель, и по этому указателю работать с этим объектом. Но если мы заранее не знаем сколько необходимо будет указателей, то тут какой конь? какой вакуум? Тут только из самого простого и сразу доступного - хранить указатели в списках. Из списка их и брать. Ну и каждый объект может иметь свой идентификатор (метод Type()), по которому можно определить что за объект, на который указатель тычет. Можно при создании организовать точную идентификацию объекта (помимо его типа объект может быть наделён иными свойствами, отличающими его от таких же объектов с тем же типом).

В общем - ощущение, что я говорю о более сложных структурах, где требуются классификация объектов, списки для их хранения и методы работы с объектами, которые могут не только хранить и отдавать по запросу информацию, но и "жить и развиваться" взаимодействуя с программой, время от времени сами меняясь и сообщая про сиё своё действо.

Наверное я в дебри полез, и обсуждать нужно просто объект, в котором нужно менять при инициализации два поля и они не должны никак меняться в течении жизни? А зачем тогда объект, если есть input-переменные?

 
Никто не обязан удалять объект, кроме того, кто его сам создал. Даже если в каких-то случаях это и случается, не стоит доверять. Сам создал - сам удали.
 
Dmitry Fedoseev:
Никто не обязан удалять объект, кроме того, кто его сам создал. Даже если в каких-то случаях это и случается, не стоит доверять. Сам создал - сам удали.

Это верно. Но речь сейчас чуть об ином. Разве нет?

Речь о методах, при помощи которых однозначно не теряются объекты, и однозначно можно их найти.

Создал объект - будь добр знать о нём и не терять, чтобы потом правильно удалить, и не было утечки памяти в связи с потерей указателя на объект (начали-то с утечки памяти в примере, где переназначался указатель на переданный в функцию объект на вновь созданный в теле функции).

И у каждого свои предпочтения - кому-то нравится одно, кому-то - другое. Но знать о каждом своём объекте - хоть их два, хоть их две тыщи два, мы обязаны - ну.., чтобы их потом удалить. А вот будем ли мы сами их удалять по delete, либо предоставим списку удалить их по Clear() или в цикле по списку и delete, либо как-то ещё - не о том же речь.

 
Artyom Trishkin:

В общем - ощущение, что я говорю о более сложных структурах, где требуются классификация объектов, списки для их хранения и методы работы с объектами, которые могут не только хранить и отдавать по запросу информацию, но и "жить и развиваться" взаимодействуя с программой, время от времени сами меняясь и сообщая про сиё своё действо.

Наверное я в дебри полез, и обсуждать нужно просто объект, в котором нужно менять при инициализации два поля и они не должны никак меняться в течении жизни? А зачем тогда объект, если есть input-переменные?

странное представление об ООП, ООП это прежде всего удобно - один раз написал, потом создавай новые экземпляры обьекта

вернемся к началу обсуждения вот мой пример, я его часто использую https://www.mql5.com/ru/forum/160683/page861#comment_11840254

мне сейчас нужно ограничить торговлю одним интервалом времени, а в следующий раз 2-мя.. 4-мя...

мой пример в 2 клика модифицируется для этой задачи:

int OnInit()
{
   Work1=new CWorkTime(StartHour1,StartMinute1,StopHour1,StopMinute1);
   Work2=new CWorkTime(StartHour2,StartMinute2,StopHour2,StopMinute2);
   Work3=new CWorkTime(StartHour3,StartMinute3,StopHour3,StopMinute3);
   Work4=new CWorkTime(StartHour4,StartMinute4,StopHour4,StopMinute4);
}


не знаю, но мыслить категориями, что ООП это только для того, чтобы обернуть все в класс и вот оно чудо - мой суперкласс, а он умеет и то и се... а если класс в 10 строк, то тут не нужно ООП - зачем себя ограничивать и вводить всех в заблуждение?

где мне удобно, там я и использую ООП, однозначно обсуждение ушло в религию - запрещать или использовать ООП ))))

 
Igor Makanu:

странное представление об ООП, ООП это прежде всего удобно - один раз написал, потом создавай новые экземпляры обьекта

вернемся к началу обсуждения вот мой пример, я его часто использую https://www.mql5.com/ru/forum/160683/page861#comment_11840254

мне сейчас нужно ограничить торговлю одним интервалом времени, а в следующий раз 2-мя.. 4-мя...

мой пример в 2 клика модифицируется для этой задачи:


не знаю, но мыслить категориями, что ООП это только для того, чтобы обернуть все в класс и вот оно чудо - мой суперкласс, а он умеет и то и се... а если класс в 10 строк, то тут не нужно ООП - зачем себя ограничивать и вводить всех в заблуждение?

где мне удобно, там я и использую ООП, однозначно обсуждение ушло в религию - запрещать или использовать ООП ))))

Однозначно - не я увожу в сию религию, поскольку сам активно использую ООП.

По примеру: а если потребуется ещё сколько-нибудь интервалов? Новые WorkNNN создавать? А зачем? Если можно обойтись одним списком без вмешательства в код программы.

Похоже, что мы о разных вещах говорим. Я об удобстве использования, а ты ... об удобстве вроде как тоже, но код показываешь не удобный. Может просто утрированный конечно, и я об этом не понял...

 
Artyom Trishkin:

По примеру: а если потребуется ещё сколько-нибудь интервалов? Новые WorkNNN создавать? А зачем? Если можно обойтись одним списком без вмешательства в код программы... 

нужно будет списки или массивы экземпляров класса  использовать - не принципиально, но для такого примера проще массив использовать, и всего один цикл сделать:

bool DisableTrade=false;
   for(int i=0;i<ArraySize(Work);i++)
     {
      if(Work[i].Disable()) {DisableTrade=true; break}
     }
   if(DisableTrade)
     {
      Comment("Не торговое время!!! Сопровождение открытых ордеров");
     }
   else...

Artyom Trishkin:

Похоже, что мы о разных вещах говорим. Я об удобстве использования, а ты ... об удобстве вроде как тоже, но код показываешь не удобный. Может просто утрированный конечно, и я об этом не понял... 

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

 
Artyom Trishkin:

///

По примеру: а если потребуется ещё сколько-нибудь интервалов? Новые WorkNNN создавать? А зачем? Если можно обойтись одним списком без вмешательства в код программы.

///      

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

С созданием нового объекта для каждого интервала тоже не самый лучший вариант. Все-таки это увеличивает тормоза. Если уж делать класс, то такой, что бы в нем параметры интервалов добавлялись в массив. Будет быстрее.

 
Dmitry Fedoseev:рмоза. Если уж делать класс, то такой, что бы в нем параметры интервалов добавлялись в массив. Будет быстрее.

абсолютно никакой разницы, что Вы сделаете один класс или ф-цию в которую add() несколько параметров, что создадите несколько классов с индивидуальными параметрами

ЗЫ: не нужно забывать, что если будете писать одну большую функции в виде длинной "портянки кода" - кеш процессора не всегда будет эффективно использоваться, хотя возможно будет выигрыш в такой "портянке" при предсказании переходов.... это только тестирование может показать, но на конкретном ПК и на конкретном компиляторе...

 
Dmitry Fedoseev:

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

С созданием нового объекта для каждого интервала тоже не самый лучший вариант. Все-таки это увеличивает тормоза. Если уж делать класс, то такой, что бы в нем параметры интервалов добавлялись в массив. Будет быстрее.

Согласен. И опять всё сводится к методам установки полей касса. А уж как их передать из input-параметров в объект, хранящий все интервалы - дело техники. Хотя можно и пересоздать все объекты списка интервалов и при изменении только одного из них - тут дело в практичности и "заморачивания/незаморачивания" проблемой изменения данных при написании кода.

 
Roman:

Растолкуйте пожалуйста смысл создания динамического объекта через оператор new.

При автоматическом создании объекта, объект класса создается в стеке, по  времени исполнения он быстрее нежели динамический.
При динамическом создании объекта, объект класса создается в памяти(в куче), при этом задействует  менеджер памяти ОС, процесс происходит медленнее.

Вот вопросы:
Если автоматическое создание быстрее, то почему тогда лучше использовать динамические объекты?
Явно контролировать выделение памяти?
Исключить возможное переполнение стека?
И неожиданно не потерять объект?
Так как при переполнении стека, объект автоматом будет удален?

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

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

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