Использование .NET, это возможно, задумайтесь над этим. - страница 3

 

Уж и не так уж поток сборщика жрет ресурсы, дело в том что при распределении больших объемов памяти, она иногда не выгружается сразу, когда процесс чем то сильно занят, однако если память потребуется другому процессу и ее недостаточно, только тогда начнет суетится. Поэтому лучше не забывать своевренно вызвать метод GC.Collect() по крайней мере тогда когда завершен большой объем операций. Однако в этом так же есть и хорошие стороны при варочании большими объеммами информации, память не перераспределятся постоянно в куче, а лишь в коллекции, тем самым сохраняя эмунитет. Таким образом первый раз загрузить в память гигабайт достаточно долго, зато второй и последующий разы гораздо быстрее, за счет единого распределения, таким образом экономится время. Плюс к тому зачастую в расход идет виртуалка, но это уже прираготива оси, когда оперы мало. Мне двух гигов хватает для основных нужд на x86, не для всех правда.

 

У вас смотрю есть много времени рассужать теоретически. Напишите небольшую прогу, котороя загружает историю из базы мт4 например и расчитывает RSI по этим данным несколько раз и замерте скорость исполнения. Точно такую же програмку напишите на си с плюсами или делфи и замерте скорость исполнения усреднённую по количеству пробегов - посмотрите так же сколько элоцировано памяти для программы для .net и для нейтивной. Было бы интеренсо услышать о таких иследованиях от вас чем просто рассуждения про коллекции и иммунитет :) - звучит расиво и умно но не убедительно

 
xnsnet:

Ну вот, это уже другой подход:) Хотя на самом деле .NET не помешал бы не по той причине, чтобы перевести в него всю работу


Не совсем понял, так Вам удалось запустить .Net модуль в терминале? Или он не поддерживает .Net хостинг?
 
Как я понял из витееватого поста, у коллеги проблемы с передачей указателей на функции в дотнет, для организации доступа к данным терминала. Можно конечно и через дде, но не будет доступа к истории.
А .NET хоста в терминале, ясное дело нет.
 

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

Действительно Сергей, были бы указатели, то бишь адреса в памяти необходимых функций терминала, все было бы, но это пока меня еще меньше волнует, как говорится дело времени, но опять же, если все это делать в таком ракурсе, для этого нужна поддержка, вы об этом не забываете?:) Это можно сделать правельно, например, создав класс в библиотеке с точной копией функций в терминале и в массиве передав адреса функций из самого терминала инициализировать статически эклепляр класса с адресованными функциями, таким образом все функции доступны в .NET вопрос в том, что если это не будет делаться официально, это все лишено смысла и будет много ошибок с появлением каждой версии. Делегаты и адреса и все что надо есть в управляемой среде.

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

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

Я бьюсь над универсальной библиотекой для всех таких програм, похожих на терминал, нелюблю повторятся, раз уж встал такой вопрос, а заодно над конкретной проблеммой. Почему я начал бится, потому что это уже второй раз когда я встречяюсь с аналогичной проблеммой использования и второй раз проходить гиморой такого хитрого способа не хочется, но хочется использовать все то, что и раньше использовал. А значит единственный способ упростить себе жизнь, это решить проблемму, которую никто не решил. Кто-то например пишет на C# или на VB, или на другом языке .NET, но не будет же при этом изучать MC++ чтобы воспользовать всем тем чем хочет, из такой программы как терминал.

 
xnsnet:

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


Может, пойти более простым путём? Не запускать из терминала . NET модули, а просто выгружать из MQL кода экспертов нужную выходную (out) информацию в некие файлы (xml, txt и т.д.), и во внешней системе на .Net или любой другой платформе делать учёт данных сверх терминала. Т.е. точкой интеграции будут выгружаемые файлы, и запуск терминала с нужными параметрами, он это допускает.
Это будет проще, не надо "сопрягать осла с ежом". Я, во всяком случае, пошёл по этому пути создания внешней управляющей терминалами системы.
 

Все пути хорошо иметь под рукой:) Ведь по сути все началось с того, что меня не вдохновили глобальные переменные:) Кого-то не вдохновит что-то другое и т.д. Кстати микрософт не стесняется сопрягать не только ослов с ежами, поэтому и имеет такой успех, они смотрят на нужды их пользователей и пытаются подстроится, есть у кого учится, иначе и небыло бы мультиязыковой-мультиплатформенной технологии, не было бы так же и много самых разных вещей, и всегда находятся основатели и реализаторы идей. Посмотрите на радость тех людей, которые добиваются своего и приносят что-то новое в жизнь и вы поймете ради чего все это.

 
xnsnet,
сколько же в Вас энергии!:)
Может быть, Вам проявиться на Форексе? Знаний по программированию достаточно.
А задача составить действительно зарабатывающего советника - посто аховая!
Будет и 10К в месяц и больше. Нет?
Если я правильно понял. Но может быть и неправильно. Возможно, Вы ищете другое.
 
SK. писал (а):

xnsnet,
1. Знаний по программированию достаточно.
2. А задача составить действительно зарабатывающего советника

Сергей, мы же все понимаем, первое не означает гарантию второго :-) здесь это не главное, хотя в общем здорово помогает ;)
 

Да, знания не есть гарантия успеха:) Я ведь не похож на человека, который обладает всем чем захочет, что значит, это подтвеждение этой истины... Но я работаю над этим, пытаюсь смотреть неудачам в лицо, да и энергия, энергии намного меньше, чем те же десять лет назад... Мы все пытаемся придти к какой-то стратегии, но как я уже говорил нужно проявить значимость, любой стратегии, я так же изучаю рынок и пытаюсь к чему-то придти, найти точку соприкосновения, как и все читаю мнения, статьи, одним словом изучаю... Здесь как в программировании, нужно остерегаться болтать о том, чего незнаешь, больше слушать и запоминать... И даже в этом случае все равно выходят косяки, сложно небоятся что-то утверждать, когда твое утверждение может быть наверняка ошибочным, хоть на ошибках учатся, с каждым разом все тяжелее признавать себя неправым. Пока я не вижу путей к реализации такого советника, который бы наверняка приносил бы прибыль, исключая пользование уязвимостей брокера. Я тоже чего только не рисовал на графиках и даже приходил к какому-то успеху в расчетах, но я пока незнаю при всех своих знаниях, как такие расчеты в динамике можно реализовать, уверен что все находятся примерно в таком же положении, кто-то находит, кто-то нет и все так же рабобатают над граалем или хотябы над его подобием. Это мой ответ, хоть и не по теме:)

P.S.: Если ты что-то доказываешь или над чем-то работаешь, то нужно хотябы на половину осознавать и верить в успех предприятия.

Причина обращения: