Erros, bugs, perguntas - página 1335
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 código fonte do indicador Fractals.mq5, existem tais entradas para o cálculo dos fractais (linhas 74 e 79):
Nestes cálculos, estou confuso por sinais iguais em >= e <= (em vermelho).
Sempre pensei que se forma um fractal ascendente quando, numa combinação de pelo menos cinco barras, a barra média tem o máximo mais alto, ou seja, é sempre mais alta (não mais alta ou igual) do que as duas altas vizinhas do lado esquerdo e direito. Com o fractal para baixo, respectivamente. Na parte acima referida do código, pode ver-se que a igualdade é permitida. Verifique por favor se existe um erro no código Fractals.mq5.
Tenho um sinal, a monitorização mostra uma lixeira a 100%, a conta está bem, estou a bater ao telefone há três dias, tanto para o Service Desk como para o pessoal da empresa. Sem resposta...
Como resolver o problema....?
Tenho um sinal, a monitorização mostra uma lixeira a 100%, a conta está bem, estou a bater ao telefone há três dias, tanto para o Service Desk como para o pessoal da empresa. Sem resposta...
Como resolver o problema....?
Escrevi para "Inovações nos favoritos" e há silêncio. Vou escrever aqui:
Windows 10 x64, Mozilla Firefox 39.0. Não posso enviar imagens ou ficheiros anexos para a minha conta pessoal.
Não deve retirar mais do que o ganho, então a curva de equilíbrio não irá a zero.
O sinal está a funcionar há quase 4 meses, apenas adições de rebites, ninguém retirou nada lá, tudo estava normal, crescimento estável... No terminal, os dados são normais e noutra monitorização em linha ....
Captura de ecrã do mybook anexado, aí tudo é normal.
Resposta do corretor, o histórico é armazenado durante 1 mês, mas depois há dois ou três meses sobre sinais teria sido o mesmo...
Caros programadores!
O indicador de bandas e o indicador iBands têm leituras diferentes. No indicador Bands o desvio padrão é calculado utilizando a função StdDev_Func, enquanto nas iBands é calculado utilizando o método GetData. Ao comparar a forma como o gráfico é desenhado, podemos ver uma grande diferença no estado dos amortecedores responsáveis pelos níveis de desvio. Enfrentei este problema na MQL4, talvez seja o mesmo na MQL5.
Não tinha prestado muita atenção a isso antes, mas agora, ao trabalhar com grandes conjuntos de objectos de classe, notei um consumo de memória demasiado grande. Verifiquei-o por sizeof() e uma classe absolutamente vazia leva 16 bytes. E considerando que as classes aqui são geridas, adicionamos mais 8 bytes por ponteiro. O total é de 24 bytes. É demasiado caro.
Dei uma vista de olhos na documentação e vi o que lá encontrei:
объекты классов всегда имеют таблицу виртуальных функций, даже если в классе не объявлено ни одной виртуальной функции.
A questão é porque é que as classes simples (as que não participam na herança) precisam da tabela de funções virtuais, uma vez que tudo é conhecido sobre estas classes na fase de compilação.
Acontece que os métodos neles são chamados da mesma forma que os métodos virtuais, ou seja, há um redireccionamento adicional do acesso através da tabela. E onde está a elogiada optimização do compilador? Como podemos afirmar depois disto alguma comparação de desempenho com C++?
Está enganado.
Se um método não for descrito como virtual, é chamado directamente. Além disso, existem optimizações para remover a virtualidade. O destruidor é sempre virtual, o que leva a uma mesa virtual.
Cerca de 24 bytes é uma afirmação estranha - a referência ao objecto não se refere ao tamanho.
As aulas em línguas geridas/seguras contêm sempre metainformação, por isso tudo aqui é razoável. Se quiser tamanho puro, utilize estruturas.
O destruidor é sempre virtual, o que resulta numa mesa virtual.
Então, porque não deveria o destruidor ser optimizado? É apenas por causa do destruidor que temos de armazenar 8 bytes extra...
Os 24 bytes é uma afirmação estranha - a referência ao objecto não tem nada a ver com o tamanho.
Bem, só não sei como tudo é aí implementado. Suponha que tem um conjunto de objectos:
O sistema armazena referências (apontadores) para cada elemento?
Se quiser tamanho puro, utilize estruturas.