Erros, bugs, perguntas - página 2415
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
Esta restrição tem sido vivida durante muitos anos.
A questão levantou-se pela primeira vez
Isto é algum tipo de restrição draconiana. Qual é a lógica nos tempos de hoje? E como é conveniente especificar agrupamentos de um monte de caracteres? Para multiplicar uma dúzia de parâmetros diferentes? Será isso conveniente?
A lógica está no protocolo de intercâmbio com o agente de ensaio.
Para definir um monte de caracteres, escreva esse monte num ficheiro de texto e passe-o usando o #property tester_file
Mas com um único teste, também é passado para o agente de teste e funciona sem restrições.
Porque é que também existe uma limitação para a entrada estática, esta não pode ser transmitida ao agente de forma alguma.
Se nem sequer é um insecto, tome-o como um pedido de melhoramento.
O erro de compilação gera ambiguidade, embora aqui tudo seja inequívoco.O primeiro método deve ser chamado como o mais adequado. Testado em C++.
Como é definido o método mais bem adaptado?
A lógica está no protocolo de intercâmbio com o agente de ensaio.
Para especificar um grupo de caracteres, escreva esse grupo num ficheiro de texto e passe-o usando o #property tester_file
Como é que isto se encaixa nos produtos do utilizador final? O limite pode ter sido justificado antes, mas duvido, com base noutras quantidades de dados a serem transmitidos. Aumentar o limite não comporta a ameaça de incompatibilidade.
Como é determinado como adequado?
Se estamos a falar da norma C++, então:
13.3 Resolução de sobrecarga. A resolução de sobrecarga é um mecanismo para seleccionar a melhor função a chamar dada uma lista de expressões que devem ser os argumentos da chamada e um conjunto de funções candidatas que podem ser chamadas com base no contexto da chamada. Os critérios de selecção para a melhor função são o número de argumentos, quão bem os argumentos correspondem à lista de parâmetros tipo da função candidata, quão bem (para funções de membros não estáticos) o objecto corresponde ao parâmetro do objecto implícito, e algumas outras propriedades da função candidata. [ Nota: A função seleccionada por resolução de sobrecarga não é garantidamente apropriada para o contexto. Outras restrições, tais como a acessibilidade da função, podem fazer com que a sua utilização no contexto da chamada seja mal formada.
Por outras palavras, deveria funcionar desta forma:
Se estamos a falar da norma C++, então:
13.3 Resolução de sobrecarga. A resolução de sobrecarga é um mecanismo para seleccionar a melhor função a chamar dada uma lista de expressões que devem ser os argumentos da chamada e um conjunto de funções candidatas que podem ser chamadas com base no contexto da chamada. Os critérios de selecção para a melhor função são o número de argumentos, quão bem os argumentos correspondem à lista de parâmetros tipo da função candidata, quão bem (para funções de membros não estáticos) o objecto corresponde ao parâmetro do objecto implícito, e algumas outras propriedades da função candidata. [ Nota: A função seleccionada por resolução de sobrecarga não é garantidamente apropriada para o contexto. Outras restrições, tais como a acessibilidade da função, podem fazer com que a sua utilização no contexto da chamada seja mal formada.
Por outras palavras, deveria funcionar desta forma:
Para b2, total clareza. b1 não é.
Como é determinado o apropriado?
Neste exemplo, é pedido um método de objecto não constante, pelo que, sendo todas as outras coisas iguais, deve ser chamado.
Se removermos a peça fundida e fizermos um argumento de tipo int para ambos os métodos, o código será compilado normalmente. Assim, a questão na MQL é sobre a peça fundida. Esta peça fundida não deve afectar o código porque é idêntica.
Para b2 há uma total clareza. b1 não é.
Não há aqui qualquer necessidade de ambiguidade. Deve ser simplesmente a ordem em que os métodos sobrecarregados são aplicados. Isto é, a tarefa de resolver a sobrecarga não é criar um dilema, mas escolher o melhor método adequado. Pondo de lado o modificador de acesso, é o primeiro método da tabela ou depende da implementação do compilador, mas não há ambiguidade.
Mas se houvesse 2 métodos, com parâmetros de entrada diferentes, por exemplo:
Voltando a C++, o mesmo vector tem um:
Portanto, esta é uma situação perfeitamente normal.
Como é que isto se encaixa nos produtos do utilizador final? O limite pode ter sido justificado antes, mas duvido, com base noutras quantidades de dados a serem transmitidos. Aumentar o limite não comporta a ameaça de incompatibilidade.
Para começar, na cache de optimização, tanto em MT5 como em MT4 os parâmetros das cordas foram sempre truncados para 63 caracteres.
Ao enviar eventos, a corda também não pode ter mais de 63 caracteres.
Ou seja, o que vem de fora é limitado
Quanto aos produtos do utilizador final. O vendedor tem de ter em conta as limitações. E se ele não os conhece, então não testou suficientemente o seu produto antes de o vender