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

Novo comentário
 
Roman:

Eu não estudei para ser um programador, estou aprendendo tudo eu mesmo, então não me chute para o meio-fio ))

Eu também não. Eu tenho uma profissão diferente. A programação é apenas uma ferramenta, como um martelo).

Criação de DLL para MKL - há DLL absolutamente padrão, sem características especiais. O resto é C++ puro, ou C# puro, se você quiser.

Ensinar C++ ou Sharp está logo além de mim, mas há vagões de literatura, em qualquer nível.

Há um artigo na MKL sobre a criação de uma DLL simples, não pode dizer nada sobre o fato de ser informativa. Sim, e Google para ajudar com a consulta - criação de DLL C++.

A propósito, falando do ponto de entrada e assim por diante. No Visual Studio você cria um projeto DLL e tudo o que você precisa é criado por você mesmo, só não toque nele com as mãos). E as funções de interação, fios, etc., são com você. - dependem de você. Isto é C++, sem tais características associadas especificamente com a DLL.

SZY A melhor maneira de aprender qualquer coisa é você resolver uma tarefa específica. Nem sequer foi inventado por mim).

 
Yuriy Asaulenko:

Nem eu. Eu tenho uma profissão diferente. A programação é apenas uma ferramenta, como um martelo).

Criação de dlls para MKL - dlls absolutamente padrão lá, sem características especiais. O resto é C++ puro, ou C# puro, se você quiser.

Ensinar C++ ou Sharp está logo além de mim, mas há vagões de literatura, em qualquer nível.

Há um artigo na MKL sobre a criação de uma DLL simples, não pode dizer nada sobre o fato de ser informativa. Sim, e Google para ajudar com a consulta - criação de DLL C++.

A propósito, falando do ponto de entrada e assim por diante. No Visual Studio é criado um projeto DLL e tudo o que você precisa é criado por si mesmo, só não toque nele com as mãos). E as funções de interação, fios, etc., são com você. - dependem de você. Isto é C++; não há tais características associadas especificamente com a DLL.

Sim, eu mesmo posso escrever a dll, com um ponto de entrada vazio))
Mas as informações sobre o ponto de entrada não estão em lugar algum, apenas latas, nenhum google dá, nenhuma literatura similar ((.
Eu tenho exatamente um problema com o ponto de entrada, pois você escreve funções de interação, inicialização, alocação de memória, tópicos, desinicialização, etc.
Eu sei que tudo isso é implementado em um interruptor no ponto de entrada e é isso, um impasse)).
Eu nem sei o que procurar para estudar.

 
Roman:

Sim, posso escrever a dll em si, com um ponto de entrada vazio ))
Mas as informações sobre o ponto de entrada não estão em lugar algum, apenas no inferno, nem no google nem em literatura similar ((
Eu tenho exatamente um problema com o ponto de entrada, pois você escreve funções de interação, inicialização, alocação de memória, tópicos, desinicialização, etc.
Eu sei que tudo isso é implementado em um interruptor no ponto de entrada e é isso, um impasse)).
Eu nem sei o que procurar para estudar.

Você acha que eu sei alguma coisa sobre o ponto de entrada? Não é assunto do rei). Há apenas uma função única na DLL que a define

// dllmain.cpp: определяет точку входа для приложения DLL.
#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                                         )
{
        switch (ul_reason_for_call)
        {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
                break;
        }
        return TRUE;
}

Não há necessidade de entendê-lo). No futuro, na maioria dos casos, não há necessidade de usar isto ao escrever e operar a DLL. O principal é não tocá-lo com as mãos).

 
Yuriy Asaulenko:

Você acha que eu sei alguma coisa sobre o ponto de entrada? Não é assunto do rei). Há apenas uma função única na DLL que a define

Não há necessidade de entendê-lo). No futuro, na maioria dos casos, não há necessidade de usar isto ao escrever e operar a DLL. O principal é não tocá-lo com as mãos).

Não, você precisa entendê-lo, você escreveu sua própria seqüência de ações, então eu achei que você conhecia bem.
Neste ponto de entrada são realizadas todas as ações,inicialização de funções,alocação de memória, criação de threads, desinicialização, etc.
Ao menos o que ler sobre este tópico?

Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais

Programação assíncrona e multi-tarefa em MQL

Yuriy Asaulenko, 2019.07.27 21:25

Você cria uma thread na DLL e passa os dados para ela, desconecta a thread e a esquece - ela terminará por si só após terminar sua tarefa.
Quando você desconecta o fio na DLL, o fio terminal é liberado. Todo o processo leva, creio eu, menos de um milissegundo.
A julgar pelo fato de que mesmo sem desconectar o fio, o processo de escrita no banco de dados é de 4-5 ms. Bem, 60 ticks/s é suficiente para não ficar triste com a chamada assíncrona do terminal.


 
Roman:

Não, você precisa entendê-lo, você mesmo escreveu a seqüência, então pensei que a conheceria bem.
Ao menos o que ler sobre o assunto?

Não há necessidade de entendê-lo, modificá-lo, etc. Você cria um projeto DLL em VS, DllMain() é criado por si só. Todas as aplicações Windows o suportam automaticamente.

Sua tarefa é escrever as funções de exportação e, além delas, qualquer código C++ que você precisar. Sua DLL está pronta e vai funcionar.

O OOP é projetado principalmente para aplicar objetos sem ter nenhuma idéia sobre seu funcionamento interno, para que você possa se concentrar em resolver exatamente sua tarefa, em vez de aprender tudo e qualquer coisa. Nós dirigimos um carro, e talvez não tenhamos idéia de sua eletrônica e construção de motores. É o mesmo no caso da DLL.

E a função DllMain() que citei anteriormente é retirada de um projeto real de uma DLL bastante complexa, que executa suas tarefas.

 
Yuriy Asaulenko:

Não há necessidade de entendê-lo, modificá-lo, etc. Você cria um projeto DLL em VS, DllMain() é criado por si só. Todas as aplicações Windows o suportam automaticamente.

Sua tarefa é escrever as funções de exportação e, além delas, qualquer código C++ que você precisar. Sua DLL está pronta e vai funcionar.

O OOP é projetado principalmente para aplicar objetos sem ter qualquer idéia de seu funcionamento interno. Nós dirigimos um carro e podemos não ter idéia sobre sua eletrônica e construção de motores. No caso da DLL, é a mesma coisa.

Isto é compreensível, as funções em si não são um problema, com todas as convenções, pois nos artigos 1 e 2 não há nenhum problema com isto.
Mas, como presumo, para criar um fio paraa função chamada,
no caso da DLL_THREAD_ATTACH, precisamos fazer um pouco de mexer em C++
alocar memória, criar um fio para a função,
e depois limpar tudo em DLL_THREAD_DETACH, para que não seja tão fácil quanto parece.

Por que eu digo isto, porque tentei uma biblioteca assíncrona, na qual as tarefas são executadas de forma assíncrona,
Eu queria fazer uma dll desta biblioteca, mas por alguma razão ela sempre trava no final do programa, ou seja, apagar o Expert Advisor do gráfico.
Por este motivo, é necessário mexer nos pontos de entrada e saída.

 
Roman:

É por isso que você tem que mexer com o ponto de entrada e saída.

...ou seja, remover o EA do gráfico, meu terminal trava.

Não é necessário. Não é o ponto de entrada que tem a culpa. Você está fazendo algo errado.

Classes, fios, etc., etc. - tudo isso é perfeitamente criado e funciona bem na DLL sem nenhum xamanismo. Mas, quando você sair, todos os SEUS processos na DLL devem ser encerrados e os objetos devem ser destruídos. Quando se depura a DLL isso acontece). Em C/C++ todo controle é tarefa do programador, não do programa.

ZS Eu o faço assim. Eu chamo uma função DLL de um aplicativo, digamos

bool job =true;

void Close() 
{
	 job = false;
	 delete Obj1;
	 delete Obj2;
	......
}
Por job=false todos os processos são encerrados, por meio da exclusão de todos os objetos para os quais a memória foi alocada são excluídos, etc.
 
Yuriy Asaulenko:

Mas, na hora de sair, todos os SEUS processos na DLL devem estar concluídos.

Esse é provavelmente o problema, eu não sabia disso, eu pensava que a dll completava seus próprios processos quando ela desacoplava.
Vou pensar sobre como encerrar todos os processos antes da saída, obrigado pela dica.
Mas apenas aDLL_PROCESS_DETACH é responsável por isso, e neste caso, precisamos matar à força todos os processos.

 
Roman:

Masé exatamente por isso que a DLL_PROCESS_DETACH é responsável, e todos os processos devem ser mortos à força neste caso.

Ela é responsável pela desconexão das DLLs com o aplicativo. DllMain() é responsável por manter o protocolo de comunicação padrão.DLL_PROCESS_DETACH é sobre outras coisas.) Seus processos não estão interessados nele, é somente seu negócio.

Em MT há uma função de desligamento. Eu acho que é OnClose(). Aqui, a partir dele, todos os processos e terminam chamando a função apropriada DLL.

 
Yuriy Asaulenko:

Ela é responsável por desconectar a DLL do aplicativo. Não está interessado em seus processos, depende inteiramente de você.

OK, eu vou experimentar. Obrigado por ter tido tempo para explicar os pontos mais delicados, obrigado.

1...171819202122232425262728293031...40
Novo comentário
Razão: