Ошибки, баги, вопросы - страница 706

 
MetaDriver:

1. 

Для создания массивов указателей на структуры (массивы).  С последующей инициализацией   for(i){ S[i] = GetPointer(StaticStruct[i]); }

2.  Чтоб сохранять сплошную (упакованную) форму массивов значимых данных.

Важно при работе с выводом данных в сырые буферы OpenCL (или отправку в DLL, запись в файлы и т.п.)

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

Язык с безопасным исполнением не должен раскрывать/давать прямого доступа.

Классы имеют больше защит и именно поэтому у них есть хендл.

Только объекты классов имеют указатели. Экземпляры структур и переменные простых типов указателей не имеют. Объект класса, который не создан при помощи оператора new(), а например, автоматически созданный в массиве объектов, все равно имеет указатель. Только этот указатель будет иметь автоматический тип POINTER_AUTOMATIC, и к нему нельзя применить оператор delete(). В остальном указатель типа ничем не отличается от динамических указателей типа POINTER_AUTOMATIC.

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

Хендлов для остальных объектов не будет принципиально, так как безопасность важнее.

Для передачи данных в OpenCL можно использовать любые типы данных, включая структуры. Там используется void*. Просто подготовьте единообразные данные в нужном формате и работайте. Предваряя вопрос "а я так не хочу, хочу по своему", отвечу, что не получится - безопасность важнее.

 
Renat:

1.  Для передачи данных в OpenCL можно использовать любые типы данных, включая структуры. Там используется void*. Просто подготовьте единообразные данные в нужном формате и работайте. Предваряя вопрос "а я так не хочу, хочу по своему", отвечу, что не получится - безопасность важнее.

2.  Язык с безопасным исполнением не должен раскрывать/давать прямого доступа.

1.  Дело совершенно не в том, что я хочу "по своему".  А в том, что для всех классов, включая самые примитивные, компилятор mql5 создаёт VMT, с соответствующим скрытым полем в объектах (указатель на VMT).  И мне этот указатель в сыром буфере (файле) - поперёк горла. Он не только является мусором, занимающим место, он ещё совершенно неуместно нарушает выравнивание данных в пакетах (в буферах OpenCL выравнивание 128 бит).  Вот в этом всё и дело.  Классы использовать заманчиво: с ними удобно работать в mql.   Но... см. выше.

В Делфи есть хороший альтернативный пример реализации.  VMT и, соответственно, указатель на VMT появляется в классах только после появления первого виртуального метода в иерархии классов.  Если бы у вас в mql5 было так же, ситуация была бы намного более управляемой.  Можно было бы использовать классы без виртуальных методов вместо структур и никаких портящих структуру "довесков" там бы не было.

Сейчас я столкнулся с ситуацией, когда реализация абстрактного (предназначанного для наследования) класса инкапсулирующего массив структур не поддаётся внедрению в неё наследуемых сервисов (типа сортировки). Замена массива структур на массив классов решает это проблему, но создаёт другую.... (см.выше).

2. И не прошу я никакой "прямой доступ".  И никакая адресная арихметика меня не интересует. Чего Вы зазря детей-то пугаете? :)  Хендл mql5 даже близко не является "сырым" указателем. А если (втихаря) является - так настоящая дыра в безопасности именно здесь, а не в реализации хендлов (псевдоуказателей) на любые пользовательские данные.

---

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

 
MetaDriver:

1.  Дело совершенно не в том, что я хочу "по своему".  А в том, что для всех классов, включая самые примитивные, компилятор mql5 создаёт VMT, с соответствующим скрытым полем в объектах (указатель на VMT).  И мне этот указатель в сыром буфере (файле) - поперёк горла. Он не только является мусором, занимающим место, он ещё совершенно неуместно нарушает выравнивание данных в пакетах (в буферах OpenCL выравнивание 128 бит).  Вот в этом всё и дело.  Классы использовать заманчиво: с ними удобно работать в mql.   Но... см. выше.

В Делфи есть хороший альтернативный пример реализации.  VMT и, соответственно, указатель на VMT появляется в классах только после появления первого виртуального метода в иерархии классов.  Если бы у вас в mql5 было так же, ситуация была бы намного более управляемой.  Можно было бы использовать классы без виртуальных методов вместо структур и никаких портящих структуру "довесков" там бы не было.

Сейчас я столкнулся с ситуацией, когда реализация абстрактного (предназначанного для наследования) класса инкапсулирующего массив структур не поддаётся внедрению в неё наследуемых сервисов (типа сортировки). Замена массива структур на массив классов решает это проблему, но создаёт другую.... (см.выше).

2. И не прошу я никакой "прямой доступ".  И никакая адресная арихметика меня не интересует. Чего Вы зазря детей-то пугаете? :)  Хендл mql5 даже близко не является "сырым" указателем. А если (втихаря) является - так настоящая дыра в безопасности именно здесь, а не в реализации хендлов (псевдоуказателей) на любые пользовательские данные.

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

Вы на самом деле косвенно просите прямой доступ через "свободу абстрактных построений". Эта тема нами хорошо изучена и прикрыта архитектурно ради безопасности. Классы в MQL5 живут по своим правилам с упором на безопасность. Остальные типы не будут иметь хендлов. Вместо хендлов для простых типов и структур Вы можете использовать индексы в массивах.

Сами хендлы в MQL5 правильные (растущие от единицы), можете проверить.

 
Renat:

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

2.   Вы на самом деле косвенно просите прямой доступ через "свободу абстрактных построений". Эта тема нами хорошо изучена и прикрыта архитектурно ради безопасности. Классы в MQL5 живут по своим правилам с упором на безопасность.

3.   Хендлы в MQL5 правильные (растущие от единицы), можете сами проверить.

1.  Всё строго наоборот.  Я хочу передавать в буфер строго чистые данные, без каких либо метаданных (хендлов). Хендлы нужны именно для удобной работы внутри mql5-процессинга.  В буфере мне эти метаданные данные не нужны.  Они мне там мешаются.  Да и не смогу я их туду засунуть - CLBufferWrite() не пустит. И это правильно.

2.  Я на самом деле не прошу никакого прямого доступа.  Для прямого доступа (если вдруг приспичит) я могу использовать DLL.  Обычный memcpy() 

aPointer = memcpy(a,a);

решит проблему получения сырого указателя.   Ренат, попробуйте вникнуть в реальную проблему. Не выдумывайте никакого не существующего "на самом деле". Всё что на самом деле - я прямо и без подводностей описал в просьбе. Максимально конструктивно и с полным пониманием проблем безопасности.

3.  Это замечательно.

--

Динамическое создание и удаление структур (new, delete) совершенно не нужно делать. Даже ни в коем случае.  Тогда и вопросы безопасности не встанут.  Я понимаю в чём проблема "на самом деле" (выражаясь вашим языком).  Существует проблема определения реального типа для динамических объектов.  Для классов решается скорее всего через анализ указателя на VMT. Однако : нет динамических структур - нет и этой проблемы.

 

Подумайте, что такое "хендл" по отношению к сущности любого масштаба?

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

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

 

Renat:

1.  Можно снабдить хендлами объекты, которые разумны по количеству (классы, файлы и тд). Но если перейти в область массивов любого размера, то любой хендл имеет шанс быть только прямой ссылкой на кусок памяти. Иначе таблица сопоставления "хендл -> память" будет съедать памяти даже больше чем сущность, на которую идет ссылка.

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

1. Конструктив - это хорошо. Я подумал. Проблема встала именно в связи с массивными структурами.  Для мелких структур время копирования и так мало.  Тут, мне кажется, проблемы могут возникнуть только из-за неразумности юзера.  Но ведь "по глупости" и так можно забить память чем угодно (хоть индикаторными буферами, к примеру).  Я не предполагаю, что кто-то будет предпочитать работу с хендлами на статические структуры, без особой на то необходимости.  Ну а переполнит память - сам виноват. Не беспокойтесь столько о глупостях народных, всё равно все предотвратить (и даже предсказать) нет никакой возможности. :)

2.  Нет-нет.  Прямых указателей не нужно.  А вот хендлы не повредили бы, даже "для любой неограниченной сущности". Главное, чтоб обязанности их использования не было.  Тогда и памяти на всех хватит. :)

Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
  • 2010.10.25
  • Nikolay Kositsin
  • www.mql5.com
Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
 
MetaDriver:

Ой чёйт я не пойму обо что ты тут копья ломаешь. Хочешь хендлы объявляй свои структуры классами, делов то.

Хочешь иметь прямой доступ к памяти пиши dll.

Взгляни на рынок через готовые классы
Взгляни на рынок через готовые классы
  • 2010.10.26
  • Dmitriy Skub
  • www.mql5.com
Не секрет, что большую часть информации об окружающем мире человек получает при помощи зрения. Справедливо это и в такой области как трейдинг. Новая платформа MetaTrader 5 и язык MQL5 открывают новые возможности для представления визуальной информации трейдеру. В данной статье предлагается универсальная и расширяемая система классов, которая берет на себя всю черновую работу по организации вывода произвольной текстовой информации.
 
Urain:

Ой чёйт я не пойму обо что ты тут копья ломаешь.

1.  Хочешь хендлы объявляй свои структуры классами, делов то.

2.  Хочешь иметь прямой доступ к памяти пиши dll.

1.  В том то и дело что проблематично. Массив классов мне в буфер писать не нужно (да и невозможно это). Мне туду структуры нужно писать. Причём быстро (без почленного  переписывания из классов в структуры). А хендлы нужны для переупорядоченного доступа (для сортировки, притом по разным ключам).

Заменой могла бы быть собственная таблица индексов - но тогда я не могу сделать класс инкапсулирующий работу с массивом структур с возможностью его наследования вместе с один раз прописанными сервисами (сортировками и бинарным поиском).

2. Не хочу! !! !!!  Хватит мне дело шить на ровном месте! :))

 

Нет, такие хендлы мы делать не будем. Это откровенное зло, за которое мы будем обязаны до конца отвечать.

 

Идеальным решением были бы параметризуемые классы 

class MyClass<T>
{
  T MyArray[];
....
};
Но я об этом уже и не заикаюсь.  Может зря?