Erros, bugs, perguntas - página 2415

Novo comentário
 

Esta restrição tem sido vivida durante muitos anos.

A questão levantou-se pela primeira vez

 
Stanislav Korotky:

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.

 
Alexey Navoykov:

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?

 
Slava:

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.

 
fxsaber:

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:

class A { };

class B
{
  A _a[];
 public:
        A * operator[](uint i)       { return &_a[i]; }
  const A * operator[](uint i) const { return &_a[i]; }  
};

void OnStart()
{
  B b1;
  const B b2;
  b1[0]; // []
  b2[0]; // [] const
}
 
Andrey Pogoreltsev:

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 é.

 
fxsaber:

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.

 
fxsaber:

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:

class B
{
  A _a[];
 public:
        A * operator[](int i)  {...}
        A * operator[](bool i) {...}  
};
B b;
b[0];    // ok
b[true]; // ok
b[0 u];   // ambiguous call to overloaded function

Voltando a C++, o mesmo vector tem um:

reference       operator[]( size_type pos );
const_reference operator[]( size_type pos ) const;

Portanto, esta é uma situação perfeitamente normal.

 
Stanislav Korotky:

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

1...240824092410241124122413241424152416241724182419242024212422...3184
Novo comentário