Pedido inválido - apenas começou e não se consegue perceber... - página 7
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
O meu posto é uma resposta à pergunta porque não utilizo a biblioteca padrão
Na verdade, eu também. Mas eu pela razão - que criei as minhas aulas muito mais cedo do que MK.
e uma tentativa de chamar a atenção dos criadores para a redundância de metades numa classe.
Não creio que seja redundante. é assim que o OOP é essencialmente. apenas se tem uma visão diferente dos invólucros, um desenho de classe diferente e uma lógica de estrutura comercial. provavelmente é uma questão de gosto.
------------------------
Mas com erros comerciais - vamos dar exemplos. Tem uma forma universal de tratamento, por exemplo 10008 -> 10012 ?
Digamos, independentemente das acções anteriores e subsequentes do Conselheiro Especialista.
Qual deve ser o resultado do processamento desta encomenda que não tenha aberto ...
as funções não utilizadas são de certa forma excluídas do ficheiro final.
Outra coisa é que quase sempre, o código "não universal" é mais rápido do que o código universal (as EAs, por exemplo, são optimizadas mais rapidamente, e as claudes são pagas um pouco menos).
Apenas e só são tomadas as funções que são chamadas no código, e tudo o resto é ignorado durante a optimização. Ou seja, se apenas 3 da classe com 61 métodos forem utilizados, é o código de três métodos que será incluído.
As funções em linha, tendo em conta o pequeno tamanho das próprias funções e a optimização do código em geral, tornam o código simples e plano.
Por conseguinte, o caso (10008 -> 10012) não me interessa, porque se a posição não for aberta num determinado tick, será aberta no tick seguinte.
Tento construir o meu código de tal forma que, se a lógica do Expert Advisor exigir a abertura de uma posição, a posição é aberta a maior parte do tempo. Quer seja aberto no próximo tick ou 10 ticks mais tarde,
essa é exactamente a abordagem correcta.
E depois voltando à questão do tratamento de erros - o que falta na biblioteca padrão? Que melhorias na direcção do tratamento/análise de erros pretendem introduzir?
abrir uma posição com muito mais fundos do que os disponíveis, ou ao colocar uma ordem pendente, o passo mínimo permitido do preço actual não é mantido, ou é colocada uma paragem sem ter em conta a direcção da posição.
E o que significa o processamento destas situações, correcção de falhas na ordem do programador pela própria biblioteca?
ou seja, a própria biblioteca inverte as paragens, ou muda o lote à sua própria discrição?
ou apenas enviar o código apropriado em resposta e informar o proger sobre a sua ordem errada?
e o que se pretende com o tratamento destas situações, a própria biblioteca corrigindo as deficiências da ordem do programador?
ou seja, para que a própria biblioteca inverta as paragens, ou mude o lote à sua própria discrição?
É que os programadores têm percepções diferentes de "necessidade e suficiência", e é por isso que se levantam questões sobre o alargamento da funcionalidade.
É melhor para eles serem completamente claros do que continuarem a adivinhar.
Mais uma vez, não estou a convencer ninguém de nada. Se pensa que o biblio está bem, deixe-o ficar como está. Mesmo após a discussão, não utilizarei esta biblioteca. Eu sozinho, posso?
Alexander, não é o único. Mas não é esse o objectivo da pergunta. Ser ou não ser.
A questão é puramente prática - com benefícios para o desenvolvimento (possivelmente também para o seu).
O que se entende por processamento destas situações, correcção de falhas na ordem do programador pela própria biblioteca?
Ou simplesmente enviar o código apropriado em resposta e informar o proger sobre a sua ordem errada?Ou seja, a própria biblioteca inverte as paragens, ou muda o lote à sua discrição?
... Porque não dizer ao programador que a sua encomenda é inválida e emitir um código de erro antes de enviar?
A resposta está na superfície - porquê enviar uma ordem ao servidor que está incorrecta e esperar por uma resposta? Porque não dizer imediatamente ao programador que a sua encomenda está errada e emitir um código de erro antes de a enviar?