Feature request: copy constructor
Я пока в этих структурах. классах.... вообще не могу разобраться. Незнаю Андрей может это хоть как то поможет
//+-------------------------------------------------------------------------------+ //| Квадратичный алгоритм сортировки подсчётом | //| http://ru.wikipedia.org/wiki/Сортировка_подсчётом | //+-------------------------------------------------------------------------------+ //| a[] - входной массив данных; b[] - выход (номер по порядку) | //+-------------------------------------------------------------------------------+ void SquareCountingSort(double& a[], int& b[]) { int n=ArraySize(a); for(int i = 0; i < n; i++) { int c = 0; for(int j = 0; j < n; j++) { if(a[j] < a[i]) c++; } for(int j = 0; j < i ; j++) { if(a[i] == a[j]) c++; } b[i]=n-c-1; //если b[c] = a[i] то на выходе не номер, а отсортированный массив } }
Вобщем, я долго думал, как обойти три основные текущие проблемы языка, не позволяющие создавать действительно большие проекты:
- отсутствие множественного наследования
- невозможность копирования
- отсутствие нормальных конструкторов.
Первое решается (отчасти) тщательным проектированием и отсутствием промежуточных доступных для использования имплементаций.
Второе и третье можно довольно красиво решить, добавив один единственный конструктор, кроме по умолчанию -- копирующий.
Если я что-то пропустил (не слежу за развитием терминала уже месяц), скажите, я прикрою тему.
Скажем, невозможность отсортировать массив простейших объектов меня удручает. Примеров масса. А с копирующим конструктором все(м) станет намного лучше.
Мало надеюсь на реализацию, но по крайней мере высказался.
Да копирующего конструктора нет и это плохо,
как вариант можно создать сортирующий int массив и ему присваивать индексы-имена объектов,
а затем при поиске в отсортированом пространстве просто использовать его как декодер,
но это конечно не решает проблему в корне а лишь ставит заплатку.
Опять новая заплатка.
Ничего что базовый класс CObject предусматривает метод Compare? Сортировку-то написать дело минуты-двух.
Допустим у нас имеется массив указателей и мы отработали одну итерацию, те все обьекты умеют выходные данные(целевую функцию)
теперь следует отсортировать обьекты по целевой функции и уничтожить половину аутсайдеров чтоб на их место создать новых.
Так вот без возможности копирования обьектов у вас ничего не получится, возможно вы справитесь с сортировкой (я даже уверен в этом)
и уничтожите ненужные обьекты, и что в результате ?
а в результате вы получите дырявый массив указателей в котором есть пустые места,
для создания под этими именами новых обьектов, но они идут не подряд а как попало. Так что проблемка та ещё.
Допустим у нас имеется массив указателей и мы отработали одну итерацию, те все обьекты умеют выходные данные(целевую функцию)
теперь следует отсортировать обьекты по целевой функции и уничтожить половину аутсайдеров чтоб на их место создать новых.
Так вот без возможности копирования обьектов у вас ничего не получится, возможно вы справитесь с сортировкой (я даже уверен в этом)
и уничтожите ненужные обьекты, и что в результате ?
а в результате вы получите дырявый массив указателей в котором есть пустые места,
для создания под этими именами новых обьектов, но они идут не подряд а как попало. Так что проблемка та ещё.
Каждый такой массив указателей отсортированный определённым образом можно назвать индексом.
Вы можете один и тот же массив данных отсортировать несколькими способами, используя несколько индексов.
Самый простой пример - библиотека. Книги стоят на своих полках по алфавиту. В библиотеке решили разложить книги по рейтингу.
Так вот самый простой способ для библиотеки это завести каталог (ящик с карточками содержащими описание и местоположением книг на полках)
отсортированный по популярности, никакого физического перемещения книг нет. Вы же предлагаете постоянно перемещать книги.
Если библиотека хочет исключить некоторые книги (например из-за их утери), то достаточно изъять соответствующую карточку из картотеки.
И опять, никакого перемещения книг на полках - сдвигаются карточки, что сделать намного проще.
Зачем перемещать данные, если можно перемещать указатели на них?
Вы специально издеваетесь?
Даже без учета того, что сам указатель -- это чуть ли не основной костыль MQL5.
Покажите мне в нормальном ЯВУ работу с чистым указателем -- все работают с умными. А передача данных по указателю -- это потеря контроля за его содержимым.
Пусть даже у вас встроенный сборщик мусора, полностью от утечек это не поможет.
Неужели вы сами не видите, насколько корявыми получились ваши объекты?
Ничего что базовый класс CObject предусматривает метод Compare? Сортировку-то написать дело минуты-двух.
Зачем перемещать данные, если можно перемещать указатели на них?
Каждый такой массив указателей отсортированный определённым образом можно назвать индексом.
Вы можете один и тот же массив данных отсортировать несколькими способами, используя несколько индексов.
Самый простой пример - библиотека. Книги стоят на своих полках по алфавиту. В библиотеке решили разложить книги по рейтингу.
Так вот самый простой способ для библиотеки это завести каталог (ящик с карточками содержащими описание и местоположением книг на полках)
отсортированный по популярности, никакого физического перемещения книг нет. Вы же предлагаете постоянно перемещать книги.
Если библиотека хочет исключить некоторые книги (например из-за их утери), то достаточно изъять соответствующую карточку из картотеки.
И опять, никакого перемещения книг на полках - сдвигаются карточки, что сделать намного проще.
Как вы предлагаете на место изятых вставить новые ? чтоб не увеличивать размер массива при каждом исключении.
Тут как минимум требуется возможность переименовыват обьекты. А такого я тоже не наблюдаю.
ЗЫ хотя в принципе проблема решается через структуру копирования,
суть обьекта это состояние всех его данных прописав в деструкторе выгрузку данных ,
можно потом их загрузить при создании нового обьекта вот и будет копия обьекта под новым именем.
ЗЗЫ Только нужно внимательно смотреть что всё до последнего захудалого счётчика сохранилось.
Как вы предлагаете на место изятых вставить новые ? чтоб не увеличивать размер массива при каждом исключении.
//--- обработка объектов
DoSomething(index);
//---- сортируем по целевой функции
SomeSort(index);
//--- можно удалять аутсайдеров и на их место поселить новых
int n=ArraySize(index);
for(int i=n/2;i<n;i++)
{
delete index[i];
index[i]=CreateNewObject(<parameters for new object>);
}
Копирующий конструктор мало чем отличается от обычной функции void CSomeObject::Copy(CSomeObject &obj), разве что удобством прямого присвоения obj1=obj2 вместо obj1.Copy(obj2).
Так как шаблонов в MQL5 нет, то многие удобности C++ языка отсутствуют. И это не проблема для прикладного языка.
Копирующий конструктор мало чем отличается от обычной функции void CSomeObject::Copy(CSomeObject &obj), разве что удобством прямого присвоения obj1=obj2 вместо obj1.Copy(obj2).
Однако... Стоимость отсутствия этого "удобства", как изволите его называть -- миллионы нервных клеток.
Вот Вы мне скажите -- а нафига было делать конструктор по умолчанию?
Все равно потом приходится явно вызывать функцию инит, которая производит доинициализацию объекта.
А давайте вспомним про инкапсуляцию! Один из трех китов ООП.
Для того, чтобы закрыть протечку ООП в виде отсутствия копи-конструктора и сделать это в виде функции, необходимо разрешить (какой-никакой, но) доступ ко всем, в том числе и приватным членам. Альтернатива? Нет, страшный костыль.
Так как шаблонов в MQL5 нет, то многие удобности C++ языка отсутствуют. И это не проблема для прикладного языка.
Причем здесь шаблоны? В С++ это вообще отдельная парадигма, не связанная с другими. Я не прошу ничего невозможного -- всего лишь разрешить копирование объектов. И организовать его в виде поэлементного копирования. Всё!
И что получается в итоге? Все принципы хваленого и разрекламированного ООП на поверку текут так, что более менее сложная конструкция обречена потонуть в муках, так и не оказавшись на плаву.На самом деле мне очень горестно озвучивать все вышесказанное, так как я надеялся нет, не на подобие С++, но на нормальную реализацию языка без хотя бы явных костылей.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Вобщем, я долго думал, как обойти три основные текущие проблемы языка, не позволяющие создавать действительно большие проекты:
- отсутствие множественного наследования
- невозможность копирования
- отсутствие нормальных конструкторов.
Первое решается (отчасти) тщательным проектированием и отсутствием промежуточных доступных для использования имплементаций.
Второе и третье можно довольно красиво решить, добавив один единственный конструктор, кроме по умолчанию -- копирующий.
Если я что-то пропустил (не слежу за развитием терминала уже месяц), скажите, я прикрою тему.
Скажем, невозможность отсортировать массив простейших объектов меня удручает. Примеров масса. А с копирующим конструктором все(м) станет намного лучше.
Мало надеюсь на реализацию, но по крайней мере высказался.