Асинхронное и многопоточное программирование в MQL - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Главная проблема вовсе не в "...еще необходимо изучить".
Главная проблема в том, что чем больше всех этих наворотов - тем больше опасность получения хитрых ошибок, которые очень непросто вычисляются.
А для разработчиков - все это дополнительный головняк.
Плюс - хорошо бы оценить - многим ли реально нужна эта самая многопоточность ?
Главная проблема вовсе не в "...еще необходимо изучить".
Главная проблема в том, что чем больше всех этих наворотов - тем больше опасность получения хитрых ошибок, которые очень непросто вычисляются.
А для разработчиков - все это дополнительный головняк.
Плюс - хорошо бы оценить - многим ли реально нужна эта самая многопоточность ?
Ну тогда соху и лошадь, и вперед... навстречу утренней заре...
Очень жаль что в mql нет такой возможности,
по этому вношу предложение для администрации, разработать стандартные mql функции для асинхронного программирования,
раз с потоками есть проблемы и прежде всего безопасность.
Для асинхронного режима думаю нет препятствий в безопасности.
был вчера у тещи, у них в подъезде ремонт - красят стены, у Вас тоже? - открывайте окна, проветривайте помещения!
Не чего не мешает! Была задача использовать чистый WinAPI. Без самописных dll !
Тема создана для обсуждения проблемы многопоточного программирования в mql, у вас какой то негативный настрой сегодня, какой флуд в созданной мною же теме?
почему именно WinAPI? открою тайну, CLR это тоже "чистый Виндовс", нативную поддержку .NET библиотек с "умным" импортом функций добавили скоро будет год как , Вы знаете WinAPI, но не можете на .NET создать поток? )))))
Попрошу воздержаться от подобных комментариев.
Ну тогда соху и лошадь, и вперед... навстречу утренней заре...
Дмитрий, а ты пробовал сохой и лошадью вырастить и собрать урожай ?
Там ведь ничуть не меньше тонкостей, и возможностей для ошибок. Но только стоит ошибка куда больше, если урожай погибнет, и ты будешь голодать...
Везде есть свои проблемы, и надо соразмерять получаемую выгоду и затрачиваемые усилия. В частности, вот с этой многопоточностью. Я не вижу, где она так уж прям необходима.
я не просто так предложил топикстартеру написать на чистом WinAPI свою первую программу https://www.mql5.com/ru/forum/318593/page2#comment_12565043
информации в сети на эту тему очень много - пишем сначала используя готовые заголовочные файлы (windows.h и пр.), затем убираем эти заголовочные файлы и приближаемся к заветному чистому WinAPI = своя большая портянка кода, которая умеет зарегистрировать процесс и окно, которая умеет получать события и обрабатывать их.... и это будет всего лишь банальное окно, которое ничего не умеет делать полезного, но будет понимание сколько нужно выполнить для этого работы используя WinAPI
я это попробовал лет 15 назад (точно не помню, помню, что был еще dial-up) и этот путь должен пройти любой "я у мамы инженер программист" , чтобы отпали вопросы и желание давать советы системным программистам - разработчикам компиляторов
"пройдя этот путь", сразу будет понятна колоссальная работа сотен системных программистов которые пишут компиляторы и библиотеки к ним, будет понятно почему в удел быстродействию был предоставлен удобный пользовательский функционал, чтобы любой прикладной программист смог прочитать справку и "в 2 клика" получить желаемый результат
ЗЫ: в общем недостаток опыта, знаний и квалификации вызвал очередное когнитивное искажение ))))
Главная проблема вовсе не в "...еще необходимо изучить".
Главная проблема в том, что чем больше всех этих наворотов - тем больше опасность получения хитрых ошибок, которые очень непросто вычисляются.
А для разработчиков - все это дополнительный головняк.
Плюс - хорошо бы оценить - многим ли реально нужна эта самая многопоточность ?
Дмитрий, а ты пробовал сохой и лошадью вырастить и собрать урожай ?
Там ведь ничуть не меньше тонкостей, и возможностей для ошибок. Но только стоит ошибка куда больше, если урожай погибнет, и ты будешь голодать...
Везде есть свои проблемы, и надо соразмерять получаемую выгоду и затрачиваемые усилия. В частности, вот с этой многопоточностью. Я не вижу, где она так уж прям необходима.
Какая соха и лошадь? Обычная лопата в ходу.
Если серьезно, по-взрослому, подходить к делу, то первая задача, которую бы не помешало вынести в отдельный поток, для асинхронной работы - WebRequest, но в общем-то сойдет и так, и так жить можно.
Вторая задача - обучение нейронных сетей, встроенная в эксперта автооптимизация. Если бы была возможность легко создавать потоки из эксперта, в эту тему вдохнулся бы неслабый заряд жизни.
Если серьезно, по-взрослому, подходить к делу, то первая задача, которую бы не помешало вынести в отдельный поток, для асинхронной работы - WebRequest, но в общем-то сойдет и так, и так жить можно.
Вторая задача - обучение нейронных сетей, встроенная в эксперта автооптимизация. Если бы была возможность легко создавать потоки из эксперта, в эту тему вдохнулся бы неслабый заряд жизни.
В рамках только MQL обе задачи решаются через автоматический запуск советника-считалки.
я не просто так предложил топикстартеру написать на чистом WinAPI свою первую программу https://www.mql5.com/ru/forum/318593/page2#comment_12565043
информации в сети на эту тему очень много - пишем сначала используя готовые заголовочные файлы (windows.h и пр.), затем убираем эти заголовочные файлы и приближаемся к заветному чистому WinAPI = своя большая портянка кода, которая умеет зарегистрировать процесс и окно, которая умеет получать события и обрабатывать их.... и это будет всего лишь банальное окно, которое ничего не умеет делать полезного, но будет понимание сколько нужно выполнить для этого работы используя WinAPI
я это попробовал лет 15 назад (точно не помню, помню, что был еще dial-up) и этот путь должен пройти любой "я у мамы инженер программист" , чтобы отпали вопросы и желание давать советы системным программистам - разработчикам компиляторов
"пройдя этот путь", сразу будет понятна колоссальная работа сотен системных программистов которые пишут компиляторы и библиотеки к ним, будет понятно почему в удел быстродействию был предоставлен удобный пользовательский функционал, чтобы любой прикладной программист смог прочитать справку и "в 2 клика" получить желаемый результат
ЗЫ: в общем недостаток опыта, знаний и квалификации вызвал очередное когнитивное искажение ))))
Игорь, не все как вы, имеют профильное высшее образование в программировании. Где вас учили преподаватели! По этому о квалификации речи и не может быть.
По этому о чистом WinAPI представление размытое, предполагал что будет проще, чем вы описали.
Я раньше вообще был далёк от программирования, и только благодаря mql я стал изучать C/C++ без учителей и подсказок!
Но как видите, самостоятельно дорос до асинхронных потребностей. Да пусть чего то не знаю, но изучаю всё по необходимости то что нужно мне.
Да с .NET технологией не знаком и не хочу, меня выворачивает от C#, у каждого своя переносимость языков.
Где вы увидели что я даю советы разработчикам? Было внесено предложение, добавить в mql набор стандартных функций по работе с асинхронным кодом.
И по моему это здравое предложение, не пойму почему вы так негативно на это реагируете... Или у вас манера общения всегда такая?
Если вам такой функционал не нужен, он нужен другим пользователям. Это как с ООП, не все его используют, но он есть. Асинхронность по моему сейчас во многих языках есть, в mql нет.
Чем mql хуже других языков, что его обделяют асинхронными методами? Про потоки вопрос закрыт, а асинхронность реализуема то из коробки.
Игорь, не все как вы, имеют профильное высшее образование в программировании. Где вас учили преподаватели! По этому о квалификации речи и не может быть.
По этому о чистом WinAPI представление размытое, предполагал что будет проще, чем вы описали.
Я раньше вообще был далёк от программирования, и только благодаря mql я стал изучать C/C++ без учителей и подсказок!
Но как видите, самостоятельно дорос до асинхронных потребностей. Да пусть чего то не знаю, но изучаю всё по необходимости то что нужно мне.
Да с .NET технологией не знаком и не хочу, меня выворачивает от C#, у каждого своя переносимость языков.
Где вы увидели что я даю советы разработчикам? Было внесено предложение, добавить в mql набор стандартных функций по работе с асинхронным кодом.
И по моему это здравое предложение, не пойму почему вы так негативно на это реагируете... Или у вас манера общения всегда такая?
Если вам такой функционал не нужен, он нужен другим пользователям. Асинхронность по моему сейчас во всех языках есть, в mql нет.
Чем mql хуже других языков, что его обделяют асинхронными методами? Про потоки вопрос закрыт, а асинхронность реализуема то.
В MQL5 есть ассинхронность, например OrderSendAsync.
Что касается взаимодействия с сетью или файловой системой - используйте WinAPI, я писал выше решение. По-моему, все есть для этого. Как использовать эти методы можете почитать на сайте Microsoft. Что еще остается нераскрытым?)