Вопросы от "чайника" - страница 125

[Renat Fatkhullin]

MetaDriver:

О, теперь понятно.

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

Т.е возможность объявить например: typedef Int8 = int[8];. 

Это легко делается через структуры. На ровном месте усложнять не будем.

struct Int8 { int arr[8]; };

[Vladimir Gomonov]

Renat:

Это легко делается через структуры. На ровном месте усложнять не будем.

Ну зашибись.  Легко.  Так и делаем!  Только мне оно надо?? На ровном месте??

А Вам не кажется, что ваша бритва Оккама  и наша  (юзерская) бритва Оккама - это две совсем разных бритвы.  Вы своим минимализмом, склонны создавать такие излишества у юзеров, что Оккаму впору вешаться на ближайшем заборе.

Если такие заботливые о  простоте - сделайте тогда возможной передачу обычных подмассивов в функции!  Всем хорошо будет, и минималисты щасливы.

// в четвёрке, кстати, это преспокойно работает.  В том числе для динамических. :)

[Yedelkin]

Renat:
Конечно статическим. 

Ну, вот. Опоздал на проверку :/

[Renat Fatkhullin]

MetaDriver:

Ну зашибись.  Легко.  Так и делаем!  Только мне оно надо?? На ровном месте??

Предложенные мной вариант структур является штатной возможность создания новых сущностей.

Не нужно возбуждаться на ровном месте.

[Renat Fatkhullin]

MetaDriver:

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

Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.

В MQL5 каждый объект/тип должен быть контролируемым - это прямое требование безопасности языка.

Если нужно передать часть массива, то используйте передачу ссылки на сам массив и позицию в массиве. Тем самым будет работать полный контроль над самим массивом.

[Vladimir Gomonov]

Renat:

1.  Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.

В MQL5 каждый объект/тип должен быть контролируемым - это прямое требование безопасности языка.

2.  Если нужно передать часть массива, то используйте передачу ссылки на сам массив и позицию в массиве. Тем самым будет работать полный контроль над самим массивом.

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

2. Тоже делаю. Всё равно: во первых криво, во вторых неуниверсально ни разу. Вот предложите способ (1) копирования двумерного mql-массива в буфер ОпенЦЛ без лишнего переписывания и заворачивания в структуры.  Или (2) использования (в целях скорострельности) вашей же функции ArrayCopy(..) для неодномерных массивов.

// Извините зе резкость предыдущего поста. Действительно излишне. Возбудился на "не будем усложнять". Поскольку как раз ведёт к сложностям.

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

Много проблем бы отпало. // Но не все, конечно.

[Renat Fatkhullin]

MetaDriver:

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

Боюсь, что Вы не захотели заметить совпадение описания:

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

Второй вариант гораздо чище, мощнее и с более контролируем. Придумывать при существующем способе другую более слабую сущность нет никакого резона.

2. Тоже делаю. Всё равно: во первых криво, во вторых неуниверсально ни разу. Вот предложите способ (1) копирования двумерного mql-массива в буфер ОпенЦЛ без лишнего переписывания и заворачивания в структуры.  Или (2) использования (в целях скорострельности) вашей же функции ArrayCopy(..) для неодномерных массивов.

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

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

Для удобства передачи данных посмотрите на простейший класс с многотиповой обвязкой функций CLBufferWrite.

[Vladimir Gomonov]

Renat:

Вы ведете речь об указателях на неконтролируемые куски памяти, что полностью запрещено в MQL5.

И, кстати, Вы сгущаете. Компилятору в точке передачи параметра, прекрасно известна размерность передаваемого массива.

Он даже ошибку выдаёт при попытке. :) Другое дело, что нужно будет при каждом вызове функции вводить дополнительную неявную параметризацию (примерно как вы мне советуете делать в явном виде). Но решение на Вашей стороне было бы гораздо универсальнее - например при использовании вашей же стандартной библитотеки функций и объектов. Тот же ArrayCopy() и FileWriteArray() работали бы без проблем.

[Renat Fatkhullin]

papaklass:
Можно свои высказывания сопровождать простыми примерами, для таких как я. MetaDriver Вас понимает, а такие как я, без примеров не понимаем о чем речь? А хочется быть в курсе происходящего.

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

Безопасный доступ к некоторым членам массива:

void MyFunc(double& array[],uint pos,uint size)
  {
   while(size>0)
     {
      Print("[",pos,"] = ",array[pos]);
      pos++;
      size--;
     }
  }

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

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

Это означает, что расходы на передачу параметров и индексирование снижены.

[Renat Fatkhullin]

MetaDriver:

И, кстати, Вы сгущаете. Компилятору в точке передачи параметра, прекрасно известна размерность передаваемого массива.

А с каких это пор все массивы стали статическими и все индексы и размеры - тоже?

Так как практически всегда массивы динамические, индексы - переменные, то никаких серьезных статических проверок в момент вызова сделать нельзя. Остается делать только проверки на основе метаинформации/rtti и именно поэтому так важно иметь доступ ко всему объекту/описанию, а не работать на авось с куском памяти.

Тот же ArrayCopy() и FileWriteArray() работали бы без проблем.

Не беспокойтесь, все давно продумано.

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