Ошибки, баги, вопросы - страница 706
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1.
Для создания массивов указателей на структуры (массивы). С последующей инициализацией for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. Чтоб сохранять сплошную (упакованную) форму массивов значимых данных.
Важно при работе с выводом данных в сырые буферы OpenCL (или отправку в DLL, запись в файлы и т.п.)
При этом сохраняется (появляется) возможность переупорядочивания доступа к данным (например при сортировке указателей) без переписывания данных.
Язык с безопасным исполнением не должен раскрывать/давать прямого доступа.
Классы имеют больше защит и именно поэтому у них есть хендл.
Хендлов для остальных объектов не будет принципиально, так как безопасность важнее.
Для передачи данных в OpenCL можно использовать любые типы данных, включая структуры. Там используется void*. Просто подготовьте единообразные данные в нужном формате и работайте. Предваряя вопрос "а я так не хочу, хочу по своему", отвечу, что не получится - безопасность важнее.
1. Для передачи данных в OpenCL можно использовать любые типы данных, включая структуры. Там используется void*. Просто подготовьте единообразные данные в нужном формате и работайте. Предваряя вопрос "а я так не хочу, хочу по своему", отвечу, что не получится - безопасность важнее.
2. Язык с безопасным исполнением не должен раскрывать/давать прямого доступа.
1. Дело совершенно не в том, что я хочу "по своему". А в том, что для всех классов, включая самые примитивные, компилятор mql5 создаёт VMT, с соответствующим скрытым полем в объектах (указатель на VMT). И мне этот указатель в сыром буфере (файле) - поперёк горла. Он не только является мусором, занимающим место, он ещё совершенно неуместно нарушает выравнивание данных в пакетах (в буферах OpenCL выравнивание 128 бит). Вот в этом всё и дело. Классы использовать заманчиво: с ними удобно работать в mql. Но... см. выше.
В Делфи есть хороший альтернативный пример реализации. VMT и, соответственно, указатель на VMT появляется в классах только после появления первого виртуального метода в иерархии классов. Если бы у вас в mql5 было так же, ситуация была бы намного более управляемой. Можно было бы использовать классы без виртуальных методов вместо структур и никаких портящих структуру "довесков" там бы не было.
Сейчас я столкнулся с ситуацией, когда реализация абстрактного (предназначанного для наследования) класса инкапсулирующего массив структур не поддаётся внедрению в неё наследуемых сервисов (типа сортировки). Замена массива структур на массив классов решает это проблему, но создаёт другую.... (см.выше).
2. И не прошу я никакой "прямой доступ". И никакая адресная арихметика меня не интересует. Чего Вы зазря детей-то пугаете? :) Хендл mql5 даже близко не является "сырым" указателем. А если (втихаря) является - так настоящая дыра в безопасности именно здесь, а не в реализации хендлов (псевдоуказателей) на любые пользовательские данные.
---
У вас сейчас структуры являются фактически классами без виртуальных функций (и VMT, соответственно). Ну так и хорошо. Только добавьте к ним ещё кое-какие возможности классов (хендлы). Для полноценной работы будет в самый раз. Тогда и указатели на массивы уже не так остро нужны (можно обернуть в структуры при необходимости).
1. Дело совершенно не в том, что я хочу "по своему". А в том, что для всех классов, включая самые примитивные, компилятор mql5 создаёт VMT, с соответствующим скрытым полем в объектах (указатель на VMT). И мне этот указатель в сыром буфере (файле) - поперёк горла. Он не только является мусором, занимающим место, он ещё совершенно неуместно нарушает выравнивание данных в пакетах (в буферах OpenCL выравнивание 128 бит). Вот в этом всё и дело. Классы использовать заманчиво: с ними удобно работать в mql. Но... см. выше.
В Делфи есть хороший альтернативный пример реализации. VMT и, соответственно, указатель на VMT появляется в классах только после появления первого виртуального метода в иерархии классов. Если бы у вас в mql5 было так же, ситуация была бы намного более управляемой. Можно было бы использовать классы без виртуальных методов вместо структур и никаких портящих структуру "довесков" там бы не было.
Сейчас я столкнулся с ситуацией, когда реализация абстрактного (предназначанного для наследования) класса инкапсулирующего массив структур не поддаётся внедрению в неё наследуемых сервисов (типа сортировки). Замена массива структур на массив классов решает это проблему, но создаёт другую.... (см.выше).
2. И не прошу я никакой "прямой доступ". И никакая адресная арихметика меня не интересует. Чего Вы зазря детей-то пугаете? :) Хендл mql5 даже близко не является "сырым" указателем. А если (втихаря) является - так настоящая дыра в безопасности именно здесь, а не в реализации хендлов (псевдоуказателей) на любые пользовательские данные.
Вы хотите построить сложную систему с абстрактными данными (что уже означает массу внутренних метаданных и связей), а потом передать ее в неконтролируемую OpenCL среду, где ее можно изменить хитрым образом. Вот именно поэтому мы разрешаем свободно оперировать только простыми объектами и массивами без возможности перезаписать виртуальные таблицы.
Вы на самом деле косвенно просите прямой доступ через "свободу абстрактных построений". Эта тема нами хорошо изучена и прикрыта архитектурно ради безопасности. Классы в MQL5 живут по своим правилам с упором на безопасность. Остальные типы не будут иметь хендлов. Вместо хендлов для простых типов и структур Вы можете использовать индексы в массивах.
Сами хендлы в MQL5 правильные (растущие от единицы), можете проверить.
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. Нет-нет. Прямых указателей не нужно. А вот хендлы не повредили бы, даже "для любой неограниченной сущности". Главное, чтоб обязанности их использования не было. Тогда и памяти на всех хватит. :)
Ой чёйт я не пойму обо что ты тут копья ломаешь. Хочешь хендлы объявляй свои структуры классами, делов то.
Хочешь иметь прямой доступ к памяти пиши dll.
Ой чёйт я не пойму обо что ты тут копья ломаешь.
1. Хочешь хендлы объявляй свои структуры классами, делов то.
2. Хочешь иметь прямой доступ к памяти пиши dll.
1. В том то и дело что проблематично. Массив классов мне в буфер писать не нужно (да и невозможно это). Мне туду структуры нужно писать. Причём быстро (без почленного переписывания из классов в структуры). А хендлы нужны для переупорядоченного доступа (для сортировки, притом по разным ключам).
Заменой могла бы быть собственная таблица индексов - но тогда я не могу сделать класс инкапсулирующий работу с массивом структур с возможностью его наследования вместе с один раз прописанными сервисами (сортировками и бинарным поиском).
2. Не хочу! !! !!! Хватит мне дело шить на ровном месте! :))
Нет, такие хендлы мы делать не будем. Это откровенное зло, за которое мы будем обязаны до конца отвечать.
Идеальным решением были бы параметризуемые классы
class MyClass<T> { T MyArray[]; .... };Но я об этом уже и не заикаюсь. Может зря?