Использование .NET, это возможно, задумайтесь над этим. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Для реализации хоста в CLR по большому счету тоже надо использовать интерфейсы, того же MSCOREE.h но для всего
этого нет полноценной документации, а методом тыка много не добьешься, равносильно взлому, все методом тыка, чуть проще…
Всё не так грустно.
Есть
Customizing the Microsoft® .NET Framework Common Language Runtime
товарища Steven Pratschner
Да и MSDN пока не отменили
Скорость исполнения высокая что особенно важно при оптимизации стратегии. Соптимизирвовали стретегию написанную в DLL вне МТ4, подобрали хорошие параметры и прицепить стратегию к MT4 через советник-мостик на MQL4, который вызывает фунции в DLL в init, start, deinit со стратегией. Лично я так делать собираюсь и другим советую кто хочеть использовать свой оптимизатор и писать не на MQL4 код советника. Машинный код быстрее чем байткод для VM что актуально где много расчётов и итераций.
Пиши братуха, только с ума не сходи, а то твои посты пугают…
:))))))) Что тут сказать, изучайте прежде чем говорить:) Не сойду, так и быть:)) В остальном мне больше нечего добавьть на данный момент:) Непонимание это стадия, где один из двух точно не прав:)
Если хошь, Пратшера могу и выслать
Дело не в том, что я незнаю как это делать, как вы явно не догадались, дело в том как это правельно сделать, я непонимаю что именно вам не понятно?:) То что вы не можете обойтись без книг в этом я не сомневаюсь, я тоже немало их прочитал, но в основном достаточно одного MSDN, книжки пустая трата времени, когда суть и так ясна, не говоря о применении, которое давно протестировано и проверено:) Как вы собираетесь включать хост в терминал без либы? Нет, если у вас есть исходный код терминала, я бы не отказался, но без либы все равно не обойтись, нужно объявить Атрибуты как минимум и другую оснастку, если делать все по человечески. Такое ощущение складывается что я разговариваю с автоматом, у которого на все один ответ в одной строке, напишите что-то большее, аргументируйте:)
Вы не думайте, если бы все дело было только в хосте, то тут решение есть, нет ничего проще как запустить терминал другой программой, а в удаленном потоке подгрузить библиотеку вместе с CLR, при инджекте своего кода в виртуальную память, все это давно известно и прекрасно работает. Другая проблемма заключается в том как этого не делать, на худой конец можно сделать вставку в программу, тоже не так сложно при соотвествующих утилитах, обходя все заслоны... Вы готовы каждую версию терминала отслеживать, я лично нет и меня взлом в этой стадии меньше всего интересует.
Pачем нужна .NET если по скорости выполнения кода она не быстрее чем код MQL. Если уж разрабатывать внешние эксперты вне MQL среды то уж на C++ или Delphi.
Скорость исполнения высокая что особенно важно при оптимизации стретегии. Соптимизирвовали стретегию написанную в DLL мне МТ4, подобрали хорошие параметры и прицепить стратегию к MT4 через советник-мостик на MQL4, который вызывает фунции в DLL в init start deinit со стратегией. Лично я так делать собираюсь и другим советую кто хочеть использовать свой оптимизатор и писать на не на MQL4 код советника. Машинный код быстрее чем байткод для VM что собенно актуально где много расчётов и итераций.
А вы знаете CLR? Что кидаетесь такими выражениями как машинный код и байт код. Байт код в исполнении, надо взять что-то другое, здесь байт код прекрасным образом превращается в машинный на стадии загрузки, и все то что вы называете замедленением, связано с качеством сопоставления. Есть много самых разнообразных проявлений байт кода, в играх самый распространенный, взять к примеру Grand Theft Auto, весь игровой скриптинг на байт коде. За счет чего есть по крайней мере две команды, одна из них занимается модернизацией скриптов на байт коде с частичным рантаймом, другая обошла скриптинг целеком в рантайме. CLR это не скрипт, это полноценный рантайм. Во всяком случае пока вы не докажете обратного, хотябы попробуйте:))) Тьфу, к яве не принадлежу, поэтому сказал, что она байт код в рантайме, но мне совершенно ненравится то как она упакована, у явы нет той самой красоты, для этого возьмем хотябы рефлектор и оценим красоту мультиязыковой платформы в исходном коде: http://www.aisto.com/roeder/dotnet/ Конечно не все можно увидеть в исходном коде потому что,достигнуто взаимодействие с нативом, что позволяет совмещать разные способы.
Самый простой способ понять: https://en.wikipedia.org/wiki/Common_Language_Runtime
Есть еще один аргумент, сборку на .NET не обязательно хранить как отдельнай файл, он может быть зашифрован или загружен из памяти в любое время или передан по сети на время выполнения, при этом так же используя компоненты на диске, много разнообразных приэмуществ позволяют иметь первостепенное значение. За все время развития, было реализовано масса способов, защиты от декомпиляции, один из них обфускация самый действенный, простыми словами переименование для нечитабельности, а так же конвертация в натив, хотя этот способ позволяет защить от просмотра например Рефлектора или от .NET Decompiler, тем не менее не лучший способ, все читается:)
Я вижу логику в ваших словах, но она марально и физически устарела, машины давно все это на зубок хватают, все дело в выборе железа для этого, при условии что вы готовы пожертвовать секундами в разнице, и получить за это безошибочное выполнение или что называется полноценную отладку, с помощью которой ошибки исправляются за минуты потраченого времени, для меня лично это наиболее важный фактор. Так как ошибки совершает любой человек их надо как то вылавливать, в условиях MQL конечно практически и вылавливать нечего, но и нет того маштаба возможностей.
В остальном, я все сказал:) Ваше дело, хотите вы изучать или нет, хотите пишите, хотите не пишите, моей позиции это не изменит:)
Ну дот нет не будет интегрирован в MT4 или возможности легко подключать свои расшиения и стретегии написанные в среде .NET такого не будет это очевидно.
Я практически ничего не знаю про CLR но явовский код медленее нейтивного кода - тесты многие проделывали и памяти ява жрёт много да и сам вижу это на работе сравнивая программы написанные на яве и нейтивные написанные на C++.
Можно написать тестовую задачку, которая загружает много данных исторических и там что-нибудь арифметическое делает с барами и замерить скорость. Вот и будет реальное сравнение. У меня стоит VS2005 будет время на досуге попробую стравнить прогу на нейтив C++ и .NET. Может быть скажу Ё да дот нет быстрее работает, всё переделываю прогу с с++ на C# :)
Ну вот, это уже другой подход:) Хотя на самом деле .NET не помешал бы не по той причине, чтобы перевести в него всю работу, потому как я не вижу такого исхода. даже в самом лучшем случае. Я говорю о .NET в качестве поддержки для технологий, которые уже разработаны. Например обеспечивать вывод в специфические форматы файлов или базу данных, хотябы все это более чем возможно, давать возможность пользователю MQL создавать свои окна, обработчики собитий, более простым способом. Все то что наиболее уместно в данном раскладе. Например как можно сообщить о каком-то событии, по тому же вебсервису, не приводя к остановке синронный поток того же советника, открыть новый поток и вернуться назад, это гораздо быстрее, чем скажем ждать завершения запроса. А асинхронность не говоря уже о событиях, то бишь последовательных калбеках в наборе события в MQL только снится:) Да все это вполне можно реализовать на C++ но сколько кода на это требуется. Плюс к тому из-за лени или банального незнания спецификаций, пользователь не учитывает все возможные проблеммы вывода в тот или иной поток данных. Сколько утечек в памяти может образоваться из-за простого незнания при использовании своих библиотек. Дот нет всегда был быстрее той же явы, хотябы простом в приведении типов. Да первые версии не отличались стабильностью и безошибочностью не говоря о беглой поддержке системных библиотек, то бишь тяп ляп. И что говорить о эталонном великолепии .NET Framework 3.0 в реализцации XAML и LINQ, а так же переработанной поддержке окон. На все это убиты сотни лучших идей не говоря уже о количестве душ разработчиков.
Я считаю, что хотябы простейшую поддержку о которой я и говорю, обеспечить можно, нельзя закрывать все двери и окна и говорить, что вокруг никого нет... Пользуйтесь только тем, что мы разработали и радуйтесь тому что есть, иногда следует прислушиваться к мнению сообщества.
Ах как хорошо что в дот нет память чистит гарбидж коллекшен. Если и есть в проге ошибка и память выделяется и выделяется где-нибудь в цикле то вы просто этого не заметите а прога на си хоть падать начнёт через какое то время или будет заметно что пямять растёт но не чистится.
Вообщем в дот нет тоже есть грабидж коллекшен, а он тоже жрёт процессорные ресурсы и прога больше требудет памяти, которой у нас и так мало из-за больших исторических данных.