Perguntas sobre OOP em MQL5 - página 66
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
Aqui está a resposta por quê:
No retângulo vermelho - adicionado uma chamada paraGetMicrosecondCount(), no azul - mais uma. É por isso que é quase igual.
Por que você se atreve a me mostrar o código? Sem o código, você pode enfiar suas fotos do tempo onde o sol não brilha.
Oops. Com ações idênticas, havia apenas uma diferença de 30%.
Talvez sejam as classes que criam as despesas gerais? É claro que o compilador deve, de qualquer forma, alinhar tudo e cortar coisas desnecessárias. Faz sentido apontar isto para os desenvolvedores.
Funcionou. A estrutura funcionava na mesma velocidade que a função e a macro. Mas a classe... muito atrás.
Funcionou. A estrutura funcionava na mesma velocidade que a função e a macro. Mas a classe... muito atrás.
Eu mesmo dei conselhos sobre como acessar métodos/campos privados no SB e peguei este gancho no fórum, não me lembro quem o sugeriu.
fiquei surpreso ao descobrir que estava dando conselhos como sempre sem me ater à terminologia, não era um gancho, mas um anti-padrão Morozov Públicohttp://blog.kislenko.net/show.php?id=1775
)))
Eu mesmo dei conselhos sobre como acessar métodos/campos privados no SB e peguei este gancho no fórum, não me lembro quem o sugeriu.
fiquei surpreso ao descobrir que estava dando conselhos como de costume sem me ater à terminologia, não era um gancho, mas um anti-padrão Morozov Públicohttp://blog.kislenko.net/show.php?id=1775
)))
lá você deu um barril de mel a negadores de padrões e amantes de OO :-) Um padrão para obter o que está escondido por considerações de projeto :-)
Alguém (alguém dos atuais monstros OO/C++), disse razoavelmente que o ponto forte do OO é que a classe base deve fornecer interfaces suficientes para todas as variações de descendentes (praticamente ter setters-getters disponíveis para todos os campos, ou all-in-one),
e descendentes não podem criar funções virtuais fora do protocolo dos pais, somente então virá a felicidade universal. Então o STL+boost generalizado realmente economiza, os testes são úteis e reutilizáveis. Mas isso se torna muitas classes, porque ao invés de novas funções virtuais, todos os tipos de procurações atuam.
aqui você deu um barril de mel a negadores de padrões e amantes de OO :-) Padrão para obter o que é escondido por considerações de projeto :-)
Alguém (alguém dos atuais monstros OO/C++), disse razoavelmente que o ponto forte do OO é que a classe base deve fornecer interfaces suficientes para todas as variações de descendentes (praticamente ter setters-getters disponíveis para todos os campos, ou all-in-one),
e os descendentes não devem criar funções virtuais fora do protocolo dos pais, somente então virá a felicidade universal. Então o STL+boost generalizado realmente economiza, os testes são úteis e reutilizáveis. Mas isso se torna muitas classes, porque todos os tipos de procurações atuam em vez de novas funções virtuais.
O que os padrões e os amantes do OO têm a ver com isso?
Alguém (alguém dos atuais monstros OO/C++), muito sensatamente disse que o ponto forte do OO é que a classe base deve fornecer interfaces suficientes para todas as variações de descendência (praticamente têm setter-getters disponíveis para todos os campos, ou tudo-em-um-blank)