Programação assíncrona e multi-tarefa em MQL - página 5

 
Andrey Pogoreltsev:

Sem mencionar o fato de que você ainda tem que aprender sobre os objetos de sincronização. Você precisa disso? Se você fizer isso, é muito fácil para você escrever uma dll.

O principal problema não está no "...ainda tem que aprender".

O principal problema é que, quanto mais todos esses avisos, maior o perigo de se cometerem erros complicados, que não são fáceis de calcular.

E tudo isso é uma dor de cabeça adicional para os desenvolvedores.

Além disso - é bom avaliar se muitas pessoas realmente precisam desta multi-tarefa?

 
Georgiy Merts:

O principal problema não é "...ainda a ser aprendido".

O principal problema é que, quanto mais artifícios, maior o perigo de se cometerem erros complicados, que são muito difíceis de calcular.

Tudo isso é uma dor de cabeça adicional para os desenvolvedores.

Além disso - é bom avaliar se muitas pessoas realmente precisam desta multi-tarefa?

Bem, uma porca e um cavalo, então, e lá vai você... em direção ao amanhecer da manhã...

 
Roman:

É uma pena que o mql não tenha tal característica,
Aadministração sugerirá desenvolver uma função mql padrão para programação assíncrona,
já que existem problemas com os fios e, acima de tudo, de segurança.
Para o modo assíncrono, acho que não há obstáculos de segurança.

Eu estava na casa da minha sogra ontem, eles estão renovando as paredes, você está fazendo o mesmo? - Abra as janelas, ventile as salas!

Romano:

Nada está no caminho! A tarefa era usar o WinAPI puro. Sem nenhuma dll feita em casa!

O tópico foi criado para discutir questões de programação mql multithreaded. Você tem algum tipo de espírito negativo hoje, que tipo de inundação no tópico, que eu mesmo criei?

Por que WinAPI? Deixe-me contar-lhe um segredo, CLR também é "puro Windows", suporte nativo para bibliotecas .NET com função de importação "inteligente" foi adicionado há um ano, você conhece WinAPI, mas você não pode criar um tópico em .NET? )))))


Romano:

Por favor, abstenha-se de tais comentários.

OK
 
Dmitry Fedoseev:

Bem, então, um arado e um cavalo, e em frente... em direção ao amanhecer da manhã...

Dimitri, você já tentou cultivar e colher com um arado e um cavalo?

Há tantas sutilezas e oportunidades para erros. Mas custa muito mais se a safra morrer e você passar fome.

Há problemas em toda parte, e é preciso medir o benefício contra o esforço envolvido. Em particular, com esta multi-tarefa, não vejo onde é tão diretamente necessário.

 

Eu não sugeri apenas que o autor escrevesse seu primeiro programa em WinAPI purohttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.

há muitas informações sobre este tópico na rede - primeiro escreva usando arquivos de cabeçalho prontos (windows.h e assim por diante), depois remova estes arquivos de cabeçalho e fique mais perto do puro WinAPI = um grande pedaço de código que pode registrar processo e janela, que pode receber eventos e manuseá-los.... e será apenas uma janela trivial que não pode fazer nada de útil, mas entenderá quanto trabalho você precisa fazer usando WinAPI


Eu tentei há cerca de 15 anos (não me lembro exatamente, lembro que havia uma conexão discada) e desta forma qualquer "Sou engenheiro de software na casa da minha mãe" deve passar por para se livrar de perguntas e desejo de dar conselhos aos programadores de sistemas - desenvolvedores de compiladores

"tendo seguido este caminho", ficará claro ao mesmo tempo um trabalho colossal de centenas de programadores de sistemas que escrevem compiladores e bibliotecas para eles, ficará claro porque foi dada uma funcionalidade conveniente ao usuário, para que qualquer programador de aplicações possa ler a ajuda e "em 2 cliques" obter o resultado desejado


SZZ: em geral, a falta de experiência, conhecimento e habilidades causou outra distorção cognitiva ))))

 
Georgiy Merts:

O principal problema não é "...ainda a ser aprendido".

O principal problema é que, quanto mais artifícios, maior o perigo de se cometerem erros complicados, que são muito difíceis de calcular.

Tudo isso é uma dor de cabeça adicional para os desenvolvedores.

Além disso - é bom avaliar - quantos realmente precisam desta multi-tarefa?

Como descobrimos acima, precisamos de assíncronia para solicitações de rede personalizadas no nível do soquete, por exemplo.

Mas tudo pode ser resolvido por meio do WinAPI. Se o desempenho de seu bot depende do desempenho da máquina na qual ele está rodando, é lamentável, especialmente para servidores dedicados:)
 
Georgiy Merts:

Dimitri, você já tentou cultivar e colher com um arado e um cavalo?

Há tantas sutilezas e oportunidades para erros. Mas custa muito mais se a safra morrer e você passar fome.

Há problemas em toda parte, e é preciso equilibrar o benefício obtido e o esforço despendido. Em particular, com esta multi-tarefa, não vejo onde é tão diretamente necessário.

O que é um arado e um cavalo? A pá de sempre.

Se quisermos ser sérios e maduros, a primeira tarefa, que seria útil para passar a separar os fios para o trabalho assíncrono, é o WebRequest, mas geralmente está tudo bem, você também pode viver com isso.

A segunda tarefa é o treinamento de redes neurais, auto-optimização incorporada ao Expert Advisor. Se fosse possível criar facilmente os fios do Expert Advisor, este tópico ganharia um grande impulso de vida.

 
Dmitry Fedoseev:

Se formos sérios e maduros, a primeira tarefa que seria útil colocar em uma linha separada para o trabalho assíncrono é o WebRequest, mas em geral serve, e podemos viver com isso.

A segunda tarefa é o treinamento de redes neurais, auto-optimização incorporada ao Expert Advisor. Se fosse possível criar facilmente fios de um consultor especializado, este assunto ganharia uma boa dose de vida.

Dentro da MQL apenas, ambas as tarefas são resolvidas com o lançamento automático do Expert Advisor.

 
Igor Makanu:

Eu não sugeri apenas que o autor escrevesse seu primeiro programa em WinAPI purohttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.

há muitas informações sobre este tópico na rede - primeiro escreva usando arquivos de cabeçalho prontos (windows.h e assim por diante), depois remova estes arquivos de cabeçalho e se aproxime do estimado puro WinAPI = seu próprio grande pacote de código, que pode registrar processo e janela, que pode receber eventos e manuseá-los.... e será apenas uma janela trivial que não pode fazer nada de útil, mas entenderá quanto trabalho você precisa fazer usando WinAPI


Eu tentei há cerca de 15 anos (não me lembro exatamente, lembro que havia uma conexão discada) e desta forma qualquer "Sou engenheiro de software na casa da minha mãe" deve passar por para se livrar de perguntas e desejo de dar conselhos aos programadores de sistemas - desenvolvedores de compiladores

"tendo seguido este caminho", ficará claro ao mesmo tempo um trabalho colossal de centenas de programadores de sistemas que escrevem compiladores e bibliotecas para eles, ficará claro porque foi dada uma funcionalidade conveniente ao usuário, para que qualquer programador de aplicações possa ler a ajuda e "em 2 cliques" obter o resultado desejado


ZS: em geral, a falta de experiência, conhecimento e habilidades causou outra distorção cognitiva ))))

Igor, nem todos como você têm uma licenciatura em programação. Onde seus professores lhe ensinaram! É por isso que as qualificações estão fora de questão.
Por esta razão, a idéia de WinAPI puro é difusa, assumi que será mais simples, do que você descreveu.
Eu costumava ser um completo estranho para a programação, e foi somente graças ao mql que comecei a aprender C/C++ sem professores e dicas!
Mas, como você pode ver, eu alcancei as necessidades assíncronas por conta própria. Sim, posso não saber algo, mas estou aprendendo tudo o que preciso.
Sim, não estou familiarizado com a tecnologia .NET e não quero, estou farto do C#, cada um tem sua própria portabilidade de idiomas.
Onde você me viu dando conselhos aos desenvolvedores? Foi feita uma sugestão para acrescentar ao mql um conjunto de funções padrão para trabalhar com código assíncrono.
Esta é uma proposta sensata, não sei porque reagiu tão negativamente a ela... Ou talvez sua maneira de falar seja sempre assim?
Se você não precisa de tal funcionalidade, outros usuários precisam. É como com o OOP, nem todos o usam, mas ele está lá. Asynchrony parece estar presente em muitos idiomas agora, mas não em mql.
Como o mql é pior do que outros idiomas, que ele é privado de métodos assíncronos? A questão das roscas é fechada, e a assincronia é implementada fora da caixa.

 
Roman:

Igor, nem todos como você têm uma licenciatura em programação. Onde seus professores lhe ensinaram! É por isso que a qualificação está fora de questão.
Por esta razão, a idéia de WinAPI puro é difusa, assumi que será mais simples, do que você descreveu.
Eu não estava nada familiarizado com programação antes, e somente graças ao mql comecei a aprender C/C++ sem nenhum tutor e dicas!
Mas, como você pode ver, eu alcancei as necessidades assíncronas por conta própria. Sim, posso não saber algo, mas estou aprendendo tudo o que preciso.
Sim, não estou familiarizado com a tecnologia .NET, e não quero, estou farto do C#, cada um tem sua própria portabilidade de idiomas.
Onde você me viu dando conselhos aos desenvolvedores? Foi feita uma proposta para acrescentar ao mql um conjunto de funções padrão para trabalhar com código assíncrono.
Esta é uma proposta sensata, não sei porque reagiu tão negativamente a ela... Ou talvez sua maneira de falar seja sempre assim?
Se você não precisa desta funcionalidade, outros usuários precisam. Acho que todos os idiomas agora têm assíncrono, mas o mql não tem.
Como o mql é pior do que outros idiomas, que ele é privado de métodos assíncronos? Bem, a questão dos fios está fechada, mas a assíncronia é viável.

Na MQL5 há assíncronia, por exemplo,OrderSendAsync.

Quanto à interação com a rede ou sistema de arquivos - use o WinAPI, escrevi a solução acima. Acho que tudo está aí para isso. Você pode ler sobre como usar esses métodos no site da Microsoft. O que mais permanece não revelado?)