Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
О, теперь понятно.
Ренат, у меня давно предложение зреет, как раз в тему. Сделайте пожалуйста именованную типизацию для массивов, хотя бы статических (для всех остальных типов она уже есть).
Т.е возможность объявить например: typedef Int8 = int[8];.
Это легко делается через структуры. На ровном месте усложнять не будем.
Это легко делается через структуры. На ровном месте усложнять не будем.
Ну зашибись. Легко. Так и делаем! Только мне оно надо?? На ровном месте??
А Вам не кажется, что ваша бритва Оккама и наша (юзерская) бритва Оккама - это две совсем разных бритвы. Вы своим минимализмом, склонны создавать такие излишества у юзеров, что Оккаму впору вешаться на ближайшем заборе.
Если такие заботливые о простоте - сделайте тогда возможной передачу обычных подмассивов в функции! Всем хорошо будет, и минималисты щасливы.
// в четвёрке, кстати, это преспокойно работает. В том числе для динамических. :)
Конечно статическим.
Ну зашибись. Легко. Так и делаем! Только мне оно надо?? На ровном месте??
Предложенные мной вариант структур является штатной возможность создания новых сущностей.
Не нужно возбуждаться на ровном месте.
Сейчас в mql5 приходится множество лишних движений совершать и писать кривой код из-за невозможности передавать в функции подмассивы.
Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.
В MQL5 каждый объект/тип должен быть контролируемым - это прямое требование безопасности языка.
Если нужно передать часть массива, то используйте передачу ссылки на сам массив и позицию в массиве. Тем самым будет работать полный контроль над самим массивом.
1. Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.
В MQL5 каждый объект/тип должен быть контролируемым - это прямое требование безопасности языка.
2. Если нужно передать часть массива, то используйте передачу ссылки на сам массив и позицию в массиве. Тем самым будет работать полный контроль над самим массивом.
1. Так я и предложил ввести поименование и следовательно жёсткую типизацию. Тем более, что это единственное место не охваченное именной типизацией, следовательно хорошо вписывается в идеологию универсализации сущностей языка.
2. Тоже делаю. Всё равно: во первых криво, во вторых неуниверсально ни разу. Вот предложите способ (1) копирования двумерного mql-массива в буфер ОпенЦЛ без лишнего переписывания и заворачивания в структуры. Или (2) использования (в целях скорострельности) вашей же функции ArrayCopy(..) для неодномерных массивов.
// Извините зе резкость предыдущего поста. Действительно излишне. Возбудился на "не будем усложнять". Поскольку как раз ведёт к сложностям.
2а. Я думаю, что во многих случаях ваше "ограничение на одномерность" для функций подобных ArrayCopy() можно безболезненно ослабить при помощи одной элементарной оговорки в комментах: "Функция работает и с многомерными массивами, при условии, что многомерный массив копируется целиком."
Много проблем бы отпало. // Но не все, конечно.
1. Так я и предложил ввести поименование и следовательно жёсткую типизацию. Тем более, что это единственное место не охваченное именной типизацией, следовательно хорошо вписывается в идеологию универсализации сущностей языка.
Боюсь, что Вы не захотели заметить совпадение описания:
Второй вариант гораздо чище, мощнее и с более контролируем. Придумывать при существующем способе другую более слабую сущность нет никакого резона.
2. Тоже делаю. Всё равно: во первых криво, во вторых неуниверсально ни разу. Вот предложите способ (1) копирования двумерного mql-массива в буфер ОпенЦЛ без лишнего переписывания и заворачивания в структуры. Или (2) использования (в целях скорострельности) вашей же функции ArrayCopy(..) для неодномерных массивов.
Во первых, не криво. Во вторых - безопасность выше любых методов оптимизации в стиле прямого неконтролируемого доступа к памяти. То есть, вопрос "а как мне прямо залить бинарный блок в контролируемую сущность" является общим и принципиальным (слабо решаемым) для managed языков.
Если нужно заниматься передачей массивов между разными системами (в OpenCL), то важно продумать простую и прямо совместимую структуру данных.
Для удобства передачи данных посмотрите на простейший класс с многотиповой обвязкой функций CLBufferWrite.
Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.
И, кстати, Вы сгущаете. Компилятору в точке передачи параметра, прекрасно известна размерность передаваемого массива.
Он даже ошибку выдаёт при попытке. :) Другое дело, что нужно будет при каждом вызове функции вводить дополнительную неявную параметризацию (примерно как вы мне советуете делать в явном виде). Но решение на Вашей стороне было бы гораздо универсальнее - например при использовании вашей же стандартной библитотеки функций и объектов. Тот же ArrayCopy() и FileWriteArray() работали бы без проблем.
Можно свои высказывания сопровождать простыми примерами, для таких как я. MetaDriver Вас понимает, а такие как я, без примеров не понимаем о чем речь? А хочется быть в курсе происходящего.
Боюсь, что это будет заменой документации. Посмотрите в поиске - там просто тонна информации.
Безопасный доступ к некоторым членам массива:
С учетом серьезной заточенности компилятора под инлайн функции, по факту может оказаться, что функция полностью встроится в место вызова и все накладные расходы будут сведены к нулю.
То есть, в MQL5 можно не бояться писать мелкие "правильные" функции - у них стандартная судьба полного инлайна с сопутствующей оптимизацией.
Это означает, что расходы на передачу параметров и индексирование снижены.
И, кстати, Вы сгущаете. Компилятору в точке передачи параметра, прекрасно известна размерность передаваемого массива.
А с каких это пор все массивы стали статическими и все индексы и размеры - тоже?
Так как практически всегда массивы динамические, индексы - переменные, то никаких серьезных статических проверок в момент вызова сделать нельзя. Остается делать только проверки на основе метаинформации/rtti и именно поэтому так важно иметь доступ ко всему объекту/описанию, а не работать на авось с куском памяти.
Тот же ArrayCopy() и FileWriteArray() работали бы без проблем.
Не беспокойтесь, все давно продумано.
Последствия нарушения принципов защиты мы отлично знаем - это путь "в апреле исправили еще 12 критических ошибок, позволяющих вырваться за пределы виртуалки и получить контроль над системой".