ООП. Вопросы применения - страница 9

[Aleksandr Chugunov]

Но на самом деле так делать не нужно....

Нужно пользоваться виртуализацией функций

P.S. Да и не получится с помощью неявного приведения типов построить нормальную прогу. Это просто вариант... как оператор GoTo....

[[Удален]]

AlexSTAL:
2) Главное удалить до завершения программы... но если у Вас этот указатель создаётся в функции, то нужно позаботиться о его сохранении в глобальном месте...

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

[TheXpert]

Я с вас реально офигеваю )))

[Aleksandr Chugunov]

Interesting:

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

Ну у Вас где-то в другом месте какая-то утечка может быть...

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

Вы на простом примере попробуйте....

[Aleksandr Chugunov]

TheXpert:
Я с вас реально офигеваю )))

Иногда это полезно... нервная встряска организма....

[[Удален]]

AlexSTAL:

Ну у Вас где-то в другом месте какая-то утечка может быть...

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

Вы на простом примере попробуйте....

Вроде избавился, поставив в блок деинсталяции эксперта вот этот код (пока проблем нет)

  for (int i=0; i<ArraySize(ArrShapes);i++)  
  {
  ArrShapes[i].Free(ArrShapes[i]);
  }

[[Удален]]

По итогу вот такое, очень даже непонятное вышло.

Чудо-юдо одним словом... :)

[Yedelkin]

В общем, по итогам обсуждения проблемы https://www.mql5.com/ru/forum/3566/page6#comment_58280 отправил заявку в СД. 

[[Удален]]

Yedelkin:

В общем, по итогам обсуждения проблемы https://www.mql5.com/ru/forum/3566/page6#comment_58280 отправил заявку в СД. 

1. Не знаю, не знаю.

Думается мне, что разработчики на определенные шаги не пойдут, пожертвовав функционалом в угоду безопасности (с одной стороны это и правильно).

Способ предложенные Александром (AlexSTAL) возможно и решил бы проблему (его определенную проблематичность учитывать не будем).

Но поступая таким образом мы в лучшем случае получим доступ к событиям и методам потомков (при этом свойства, переменные и подобные вещи не заявленные в предке вряд ли смогут быть использованы).

Хотя тут скорей всего придется экспериментировать.

2. Исходя из ого что мы имеем сейчас можно поступить по другому, я вижу 2-ва варианта:

а. Использовать специализированные массивы, в которые помещать объекты только одного класса (потомки определенного типа);

В этом случаем можно будет получить доступ по возможности к любым свойствам, методам и событиям объектов находящихся в массиве (поскольку они однородны);

б. При необходимости работы с массивом разношёрстных объектов, являющимися потомками одного базового класса придется создавать дополнительные массивы для хранения каждого вида потомков.

Таким образом в основном массиве мы получим доступ только к общему для всех объектов функионалу (если без АВТОГЕНА и КУВАЛДЫ), а на уровне специализированных массивов доступ к полным возможностям каждого из типов потомков.

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

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

PS

кстати, идея с хендлами на мой взгляд достаточно хороша (даже если за основу всей работы с объектами брать указатели). Хендлы по идеи должны позволить выделить уникальный объект из числа себе подобных или из всего списка объектов.

[[Удален]]

TheXpert:
Я с вас реально офигеваю )))

Порой я сам от себя фигею, хорошо что порой. :)