Erros, bugs, perguntas - página 2709
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
Porque não posso chamar um construtor protegido do meu método de fábrica em MQL?
O problema é o valor por defeito, se o remover, tudo funciona como deveria:
Porque é que na MQL não se pode chamar um construtor protegido do seu método de fábrica?
Ainda não adivinhei onde é que isso poderia ser útil.
Ainda não adivinhei onde isto poderia ser útil.
Implementação clássica do padrão Singleton.
Uma implementação clássica do padrão Singleton.
Então não pode criar mais do que um determinado número de objectos de uma determinada classe?
Para que não possa ser criado mais do que um certo número de objectos de uma determinada classe?
Sim, para que haja um único ponto de acesso de todas as partes do programa a uma instância da classe com estado variável.
Aqui está um site fixe que encontrei hoje sobre padrões em imagens e pseudo-código:https://refactoring.guru/ru/design-patterns/singleton
Sim, para ter um único ponto de acesso de todas as partes do programa a uma instância de classe em mudança de estado.
Aqui está um site fixe que encontrei hoje sobre padrões em imagens e pseudo-código:https://refactoring.guru/ru/design-patterns/singleton
Já está, obrigado. Já usei uma construção destas antes.
O problema é com o valor por defeito, se o remover, tudo funciona como deveria:
Mas em C++, também funciona com o valor por defeito. Como é que o afecta?
Alguém ligou o CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) da MQL com compressão deflacionada a partir do websocket? O echo-server público (echo.websocket.org) não parece suportar esta extensão, não encontrei nenhum outro echo-server, e o node.js local dá o erro "zlib invalid distance too far back" ao tentar decifrar dados comprimidos. Eu defino server_max_window_bits=15; client_max_window_bits=15 no cabeçalho, mas não parece ser o caso, pois o servidor confirma estas definições. No lado do MQL não posso definir nada excepto a tecla {1,0,0,0} ;-(.
Alguém ligou o CryptEncode(CRYPT_ARCH_ZIP, data[], key[] = {1,0,0,0}, result[]) da MQL com compressão deflacionada a partir do websocket? O echo-server público (echo.websocket.org) não parece suportar esta extensão, não encontrei nenhum outro echo-server, e o node.js local dá o erro "zlib invalid distance too far back" ao tentar decifrar dados comprimidos. Defino server_max_window_bits=15; client_max_window_bits=15 no cabeçalho, mas não parece ser o caso, uma vez que o servidor confirma estas definições. No lado do MQL não posso definir nada excepto a tecla {1,0,0,0} ;-(.
Se entendi correctamente a sua pergunta, a compressão GZIP é principalmente utilizada em websockets para embalagem de dados.
A constante CRYPT_ARCH_ZIP é a constante mais provável para o ZIP regular.
Se souber como embalar/desembalar GZIP usando mql5, também estou interessado.
Se bem entendi a pergunta, os websockets utilizam principalmente a compressão GZIP para embalar dados.
A constante CRYPT_ARCH_ZIP é a constante mais provável para o ZIP regular.
Se souber como embalar/desembalar GZIP, utilizando ferramentas mql5, também estou interessado.
Tanto quanto sei, o interruptor {1,0,0,0} remove todo o invólucro e deixa apenas o pacote comprimido. Pelo menos a palavra "Olá" aparece na forma comprimida da mesma forma na saída do CryptEncode e na saída deflacionada. Por conseguinte, deve funcionar também ao contrário. Contudo, a MQL não dá mais configurações e não mostra as configurações "por defeito" de deflação utilizadas por ela. Obviamente são diferentes, mas apenas max_window_bits e no_context_takeover podem ser controlados no websocket - em primeiro lugar são claramente menos do que no algoritmo deflate (que é configurado no servidor), em segundo lugar nem sequer podem ser configurados no CryptEncode/Decode.