Erros, bugs, perguntas - página 2564
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
?
é uma situação estranha, tudo fora da classe tem estado a trabalhar há muito tempo com os staichiqs. e estou apenas a fazer um grande alarido sobre isso.... Só por diversão, reproduza você mesmo o código:
Vê uma instância de objecto? e existe em MQL ;)
SZZ: E existe a nível de ajuda ... qual é a sua carne comigo?
https://www.mql5.com/ru/docs/basis/oop/staticmembers
Todas as mesmas regras se aplicam à estática (privada, protegida, pública), apenas não requerem a criação de objectos.
Não em geral: por exemplo, um statik público não pode ser restringido numa classe derivada
hmmm... Como explicar o absurdo da situação... Sugeri-lhe que lesse os posts dos administradores (desenvolvedores), mostrei-lhe a ajuda que eles escreveram, o que quer de mim com as suas fotografias?
Não creio que seja por isso, leio o fórum e ajudo, e faço como recomendado pelos programadores. Se achar necessário, escreva ao "comité de protecção das normas C++", à ONU... Bem, pelo menos o administrador no PM, se não puder, mas depois tranque a mensagem dos programadores e siga o seu caminho!
ZS: Eu de alguma forma consigo inserir o código fonte e não imagens, porque não o fez?
2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:imprimir
2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:imprimir
2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:imprimir
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4
O único erro no código está no acesso ao método privado. Este insecto apareceu recentemente.
A função ChartOpen retorna sempre 0 no serviço. Embora o próprio gráfico se abra.
O único erro no código está no acesso ao método privado. Este insecto apareceu recentemente.
Pensei que me tinha esquecido de algo, por isso reli novamente como se comporta a estática em C#https://metanit.com/sharp/tutorial/3.6.php
Os membros da classe estática são comuns a todos os objectos da classe, pelo que se deve referir a eles pelo nome da sua classe:
Note-se que os métodos estáticos só podem referir-se a membros de classe estáticos. Não podemos abordar métodos não estáticos, campos, propriedades dentro de um método estático.
Em MQL, a estática é inicializada antes de correr OnInit() , agora vamos discutir a visibilidade global de métodos privados de estática.... este comportamento da estática em MQL - se usar estática, significa que não usamos características de protecção de dados de uma classe, imho
qual é o tamanho de um insecto? - a forma como os programadores o farão, eu disse que o comportamento nas operações de contexto é determinado pelo programador (o operador de resolução de contexto é o operador com a maior prioridade na língua! ), e o compilador irá ajudar correctamente - bem, como acontece))))
funciona assim?
no seu conjunto, faz o trabalho
PS: actualizado para 2145 - o código com estática comporta-se da mesma forma, se ficar assim durante meio ano, verificar-se-á que este é o comportamento planeado da estática ;)
UPD: lembre-se, como gíria para tudo isto é chamado - truques sujos! ))) - Procure muitos exemplos na web, onde este comportamento é aceite como um padrão linguístico, e onde está ligado a um compilador específico do fabricante. Em Python, eval() não será a execução de código linear efectivamente quebrada? - bem, alguns fazem e outros não, porque o comportamento é imprevisível.
UPD: verificar no 2145 a minha pergunta de há um mês atráshttps://www.mql5.com/ru/forum/320733#comment_12989063
https://www.mql5.com/ru/forum/320733#comment_12958594
nada mudou, em bool ao verificar os tipos o compilador não aprendeu a escrever avisos - isto é muito desagradável, estava à procura de um erro no meu código, embora estivesse certo de que o compilador MQL verifica sempre a correspondência de tipo
Quanto é que é um bug? - Seja o que for que os criadores lhe dêem a volta, é assim que vai ser.
É óbvio que o bug será corrigido.
Nada mudou, o compilador não aprendeu a escrever avisos em bool quando verifica os tipos
A fundição automática de apontadores e tipos numéricos para bool é muito conveniente.
nada mudou, em bool ao verificar os tipos o compilador não aprendeu a escrever avisos - isto é muito desagradável, já estava à procura de um erro no meu código, embora tivesse a certeza de que o compilador MQL monitoriza sempre rigorosamente a correspondência de tipos
Não há perda de dados durante esta fundição. Ou 0 ou não 0.
Outro caso é quando duplo -> qualquer tipo inteiro (até int32, inclusive)
Com esta fundição, não há perda de dados. Ou 0 ou não 0.
Outra coisa é quando se funde duplo -> qualquer tipo inteiro (até int32, inclusive)
mas ao contrário?
Estava à procura de um bug no meu código
No início escrevi um teste, mas usei primeiro int , depois desisti de usar bool, mas não consertei o código inteiro, não me lembro, mas foi assim:
Estou pronto para tal comportamento agora, mas porque estou a escrever sobre isso...bem, na verificação das condições do MQL em if() - será que os tipos de controlo são rigorosamente controlados? qualquer uso de operações não-booleanas emitirá um aviso? - E da mesma forma que escrevi em C# na VS2017 - o meu código de exemplo não se compila e a MQL não lança um aviso. Na minha opinião, para aqueles que são novos na programação em MQL, tal comportamento implica algumas surpresas.
É óbvio que o bug será corrigido.
Não vou argumentar, mas a minha opinião é que não se deve confiar no controlo do compilador quando se sai da classe através da estática, bem como utilizar o operador de resolução de contexto,
ou seja, se escrever um método/campo estático ou utilizar :::: - não confie no compilador