Projeto do assessor - página 6
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
No mundo civilizado, as listas são implementadas através...
Por que você não escreve uma biblioteca civilizada em MQL, e então conversaremos. Há anos ouvimos estes gritos, e quando se chega ao fim, começa-se a fazer um verdadeiro bodloclocoding.
A MQ realmente cometeu um erro com referências em CObject. Eles não deveriam estar lá. E estas referências são utilizadas em recipientes muito específicos como CList. Mas onde não há erros? Idiomas civilizados, você diz? Leia a crítica de Richter sobre o que ele pensa do Objeto C# e que métodos ele não deve conter. Então, porque Richter está certo, devemos nos recusar a usar o C#? Bobagem. Portanto, pare de empilhar aqui e vá finalmente para sua selva de procedimentos.
Bem, sim, não se pode colocar objetos constantes em uma lista.
Entretanto, eu uso constantemente a funcionalidade CObject, e nenhum dos críticos não ofereceu nada semelhante às matrizes e listas de objetos da Biblioteca Padrão.
"A maneira como as coisas devem ser feitas" é a gritaria de todos. Mas para sugerir algo, de repente, não há nada.
Mesmo aqueles participantes que realmente oferecem diferentes soluções de software - não oferecem um substituto para o CObject - na maioria das vezes não o utilizam de forma alguma, menos frequentemente usam sua funcionalidade, não prestando atenção à "implementação através de um só lugar". E isto significa que a implementação é bastante boa.
Se fosse ruim, uma substituição teria sido sugerida há muito tempo.
Normalmente o CObject nativo é usado quando tudo mais é também baseado na biblioteca padrão. Em particular aqueles que compartilham ativamente suas fontes, tendem a unificar, reduzir o código autoescrito e reduzir o número de suas próprias bibliotecas para facilitar a vida dos usuários externos. Mas cada um decide por si mesmo, se ele está codificando para si mesmo ou para a conveniência dos outros.
Entretanto, suponho que muitas pessoas usam suas próprias soluções (como eu), elas simplesmente não vêem a necessidade de oferecê-las a outros. Mas em geral acho que seria melhor se houvesse algum padrão baseado em algumas bibliotecas bem conhecidas, como a MFC. É por isso que eu realmente não entendo MQ, por que eles tiveram que reinventar sua própria roda (além de muito controvertida) em vez de portar uma solução pronta. Entretanto, o mesmo pode ser dito sobre a própria linguagem MQL ))))
Mas, em princípio, não sou obrigado a recusar do CObject, apenas fiz minha observação crítica em resposta à frase, que alguém deveria usar CMyCobject quando há um CObject muito legal da MQ :)
Escreva uma biblioteca civilizada em MQL, e então conversaremos. Você vem gritando há anos, mas quando você começa a gritar, você começa a fazer bodloclocoding.
Bem, eu tenho minhas próprias bibliotecas. Então, sobre o que você queria falar?
Eu realmente estraguei com referências no CObject MQ. Eles não devem estar presentes. E estas referências são utilizadas em recipientes muito específicos como CList. Mas onde não há erros? Idiomas civilizados, você diz? Leia a crítica de Richter sobre o que ele pensa do Objeto C# e que métodos ele não deve conter. Então, porque Richter está certo, devemos nos recusar a usar o C#? Bobagem. Portanto, pare de empilhar aqui e vá finalmente para sua selva de procedimentos.
Não seja arrogante e mal-educado, não estou falando com você pessoalmente.
Sobre "mexer com os links" - bem, sim, engraçado, depois de já ter pintado tudo sobre isso. Embora antes você já tenha literalmente pingado em CObject, que é tão grande, e que mesmo as indicações não são inicializadas lá por padrão (pelo menos você deveria ter estudado o código fonte de seu idioma primeiro). De qualquer forma, não vejo mais nenhum sentido para lançar aspersões sobre você aqui.
Mas, concordo, nem sempre é necessário utilizar o OOP.
Digamos, eu tenho CDataProvider:pulic CDataProviderI class - provedor de dados, que fornece Expert Advisor com dados de tempo, indicadores, terminal e ambiente. Em um Expert Advisor, pode haver muitos TSs - cada um deles receberia indicações de timeseries e indicadores do provedor de dados (cada TS não precisaria criar timeseries - o provedor de dados forneceria indicações para as timeseries necessárias se elas já existissem, e só criaria timeseries, que ainda não foram criadas).
Quando você precisar receber um indicador do provedor de dados - preencha a estrutura de descrição do indicador, e então solicite um indicador do provedor, apontando para esta estrutura.
Assim, cada indicador dentro do provedor de dados deve ser capaz de identificar sua estrutura (o provedor de dados "conhece" apenas a classe base abstrata da estrutura) e de acordo com ela criar o objeto indicador pronto, que será criado pelo provedor de dados.
Mas é claro que não é razoável iniciar este projeto apenas com o objetivo de verificar uma nova idéia de um indicador. Como resultado, para esses novos indicadores tudo é "à mão", sem nenhum OOP. Entretanto, se eu vejo que um indicador é útil para Consultores Especialistas - ele é escrito "adequadamente" - com total apoio do OOP, e criação dentro de um fornecedor de dados.
Quando testei todos os indicadores no MT4 há cerca de 15 anos atrás para a adequação para negociar em modo de ordem inversa, encontrei apenas 1 que permite fazer lucro no dia-a-dia. a maioria dos indicadores é baseada em indicadores incorporados, por isso os resultados de negociação são baixos quase para todos eles. acho que a primeira tarefa de qualquer negociador é estudar o mercado para a precisão da previsão ou lucratividade de um padrão.
com respeito.
O principal é que eles não podem confundi-lo com a direção na qual você vai e vê a realização de suas idéias. O objetivo de todo este circo, de confundir e dirigir na direção errada, longe do lucro.
Bem, você mesmo respondeu à pergunta por que você deve usar CObject, em vez de bicicleta autoescrita. Isto é necessário para facilitar a vida não apenas para os outros, mas principalmente para você mesmo, porque as palavras "unificação", "reduzir o código autoescrito", "reduzir o número de suas próprias bibliotecas" - isto é o que todo desenvolvedor deve se esforçar para conseguir. Este é o Santo Graal do programador.
Naturalmente, a biblioteca padrão é obsoleta. A linguagem agora permite que você faça genéricos, e as interfaces estão chegando. Mas a velha biblioteca funciona e é uma boa unificação, e como dizem, o melhor é inimigo do bom. Uma vez que não existe o perfeito e o melhor que você tem para usar o bom.
Sobre "mexer nos links" - bem, sim, é engraçado, depois que eu já escrevi tudo sobre isso. Embora antes você tenha literalmente "cagado" no CObject declarando que é tão grande, e que mesmo as indicações não são inicializadas lá por padrão (você deve pelo menos estudar a linguagem de origem para começar). Em geral, não vejo a utilidade de jogar contas diante de você.
Ninguém vai rastejar diante de você aqui. Acredite, o conhecimento "escondido" que você "revelou" para todos nós aqui há muito tempo é conhecido por muitos. Não vou nem mesmo discutir sobre a inicialização do link. Você sabe que está formalmente certo, então tenta esfregar meu nariz na mesma coisa: ler a matemática, aprender o que NULL, etc., etc. Mas você não precisa me ensinar. Você é legal. Você tem tudo isso. Então por que você está jogando contas em nós? Vá para sua biblioteca. Veja se ele fica 0,5% mais rápido.
Os indicadores de fractal e pinbars também são freqüentemente utilizados. É uma solução maravilhosa para muitos sistemas de negociação que utilizam os mesmos indicadores em suas negociações. mas não são adequados para testes, por isso o fazem por necessidade.
15 anos atrás eu estava testando todos os indicadores no MT4 para a adequação para negociar em modo de posição reversa e encontrei apenas um que era lucrativo diariamente.
Não, você só tem que obter a essência do indicador corretamente. Um indicador não é um Graal pronto, mas apenas uma expressão conveniente de algumas peculiaridades do movimento de preços. Portanto, não devemos tratá-los como "a fonte de sinal final", mas apenas como um "recurso de sinal" e usá-los como um complexo. E, neste caso - muitos indicadores começam a ser necessários na maioria dos testes. Em particular, a ATR, por exemplo, já estou pensando em padronizá-la no modelo de um Expert Advisor porque a utilizo praticamente em todos os lugares. Os MA MAs também são freqüentemente indicadores necessários. Fractais, indicadores de pinbar...
...
Mas, concordo, está longe de ser sempre necessário usar o OOP.
Digamos, eu tenho uma classe CDataProvider:pulic CDataProviderI - um fornecedor de dados, que fornece a especialistas séries de tempos, indicadores, dados de terminal e de ambiente. Em um Expert Advisor, pode haver muitos TSs - cada um deles receberia indicações de timeseries e indicadores do provedor de dados (cada TS não precisaria criar timeseries - o provedor de dados forneceria indicações para as timeseries necessárias se elas já existissem, e só criaria timeseries, que ainda não foram criadas).
Quando você precisar receber um indicador do provedor de dados - preencha a estrutura de descrição do indicador, e então solicite um indicador do provedor, apontando para esta estrutura.
Assim, cada indicador dentro do provedor de dados deve ser capaz de identificar sua estrutura (o provedor de dados "conhece" apenas a classe base abstrata da estrutura) e de acordo com ela criar o objeto indicador pronto, que será criado pelo provedor de dados.
Mas é claro que não é razoável iniciar este projeto apenas com o objetivo de verificar uma nova idéia de um indicador. Como resultado, para esses novos indicadores tudo é "à mão", sem nenhum OOP. Entretanto, se eu vejo que um indicador é útil para Consultores Especialistas, ele é escrito "adequadamente" - com total apoio do OOP e criação dentro de um provedor de dados.
P.S.
A propósito, no caso de indicadores e provedores de dados vemos a vantagem da herança de virtualização. Temos a interface básica dos parâmetros indicadores CIndicatorParametersI; o descendente desta interface é o parâmetro real do indicador necessário. Ao solicitar o indicador, declaramos estes parâmetros e passamos ao fornecedor de dados um ponteiro para a interface abstrata. Assim, o próprio fornecedor de dados nem sabe qual indicador é solicitado - ele é definido em uma função, na qual o indicador é criado de acordo com o novo tipo. E somente este indicador sabe quais parâmetros foram passados, ele extrai os parâmetros necessários do objeto passado.
O truque é que em quase todo lugar dentro do provedor de dados há uma classe básica simples de parâmetros (ou indicadores) - apenas as funções mais simples e mais comuns das interfaces básicas estão disponíveis para o provedor de dados. Isto simplifica a modificação do código (quando necessário), e não cria a tentação de "adulterar" o código de indicadores do fornecedor de dados. Se você quiser mudar um indicador, isso é feito apenas dentro do indicador, o fornecedor de dados é apenas um armazenamento de indicadores, o máximo que ele pode fazer é criar um novo indicador.
Acho que você está tornando tudo muito complicado. O provedor de datas é o próprio MetaTrader. Isto é, o provedor de datas não é realmente necessário, ele precisa apenas de uma interface conveniente para trabalhar com dados. Por exemplo, na minha Libera, basta escrever o preço de abertura do último bar:
O objeto WS está sempre lá e está sempre à mão e funcionando. Como ele faz é escondido nos bastidores. Isso é tudo acesso aos dados:)
s.o.p. O OOP deve reduzir a complexidade do uso do sistema, não aumentá-lo. Se você admitir que tem que construir um jardim para um simples cheque, isso significa que você tem algo errado com sua arquitetura com fornecedor. Ou seja, você programou algo que nem sempre quer usar.Não, você só tem que obter a essência do indicador corretamente. Um indicador não é um Graal pronto, mas apenas uma expressão conveniente de algumas peculiaridades de movimentos de preços. Portanto, não devemos tratá-los como "a fonte de sinal final", mas apenas como um "recurso de sinal" e usá-los como um complexo. E, neste caso - muitos indicadores começam a ser necessários na maioria dos testes. Em particular, a ATR, por exemplo, já estou pensando em padronizá-la no modelo de um Expert Advisor porque a utilizo praticamente em todos os lugares. Os MA MAs também são freqüentemente indicadores necessários. Fractais, indicadores de pinbar...
Eu quis dizer trabalhar no modo "sempre no mercado" com base no sinal do indicador de inversão, e novamente, há 15 anos atrás, agora minha visão do mercado mudou ligeiramente.
com respeito.
Acho que você está tornando tudo mais complicado do que precisa ser. O fornecedor de dados é o próprio MetaTrader. Ou seja, você não precisa realmente de um provedor de datas, você só precisa de uma interface amigável para trabalhar com dados. Por exemplo, na minha Libera, basta escrever o preço de abertura do último bar:
O objeto WS está sempre lá e está sempre à mão e funcionando. Como ele faz é escondido nos bastidores. Isso é tudo acesso aos dados:)
s.w. OOP deve reduzir a complexidade do uso do sistema, não aumentá-lo. E se você mesmo admitir que tem que construir uma horta para um simples cheque, isso significa que há algo errado com sua arquitetura ISP. Ou seja, você programou algo que nem sempre quer usar.Sua (vamos ser "você") entrada "WS.Open[0];" difere muito pouco da minha entrada "m_tcMainContainer.Open(0)".
Suspeito que deve haver alguma ação preliminar na inicialização para o objeto WS.
No meu caso devemos chamar a função bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer).
Em cada parte de um Expert Advisor (no gerador de entradas, nos controladores de rastreamento e saída, ou seja, em objetos que podem realizar ações comerciais) tenho o objeto "Timeseries Container" - na verdade, é um ponteiro para OHLCSTVtVr timeseries com opções adicionais de serviço.
Pode haver muitos recipientes diferentes de símbolos diferentes e prazos diferentes em um consultor especializado. A ideologia do fornecedor de dados permite não duplicá-los. Uma vez que na realidade - todas as séries de tempo são armazenadas nele, e os recipientes - apenas apontam para as necessárias.
Não vejo muita diferença - como eu entendo, a WS (WareStore, provavelmente ?) ainda é o mesmo meu fornecedor de dados. É que meu provedor de dados também concentra o resto dos dados - indicadores, símbolos (objetos CSymbolInfo), terminal (objeto CTerminalInfo), que também tem uma coleção de gráficos. Em cada atualização, as séries cronológicas são atualizadas (conforme necessário) - aqui a ideologia está próxima à da Biblioteca Padrão.
Se considerarmos o próprio MT4-5 como fornecedor de dados, e nossa classe for usada apenas para fornecer acesso - então acontece que, de acordo com sua referência ao preço Aberto, devemos chamar a função CopyOpen() por um valor - isto não me parece razoável.
Ao dar pleno acesso global a todas as variáveis em qualquer lugar do programa, também acho que é extremamente irracional, ao contrário, tento ter acesso apenas àquelas estruturas e dados que são necessários para esta ação em cada lugar do programa. Todo o resto deve ser inacessível. A ideologia do fornecedor de dados me permite controlar este acesso.
não o considero como um indicador, ele mostra a volatilidade média do mercado durante um determinado período de tempo, não é adequado como um sinal de entrada (pode ser aplicado como um filtro, nada mais).
Eu quis dizer trabalhar no modo "sempre no mercado" com base no sinal do indicador de inversão, e novamente, há 15 anos atrás, agora minha visão do mercado mudou ligeiramente.
Respeitosamente.
O que você quer dizer com "ATR não conta como um indicador" ???
E como "não é adequado como um sinal de entrada?? E eu sou um tolo, eu uso a entrada "quebra de volatilidade" usando apenas este indicador...?
Suspeito tanto que você tem sua própria e particular compreensão da essência dos indicadores... Para mim, um indicador é um objeto que pode produzir algum valor variável, dependendo do tempo. Na verdade, até mesmo uma tabela de preço comum de velas é também um indicador. Mas para você é algo mais... Conseqüentemente, nosso entendimento é diferente.