Errores, fallos, preguntas - página 2415

Nuevo comentario
 

Se ha vivido con esta restricción durante muchos años.

La cuestión ha surgido por primera vez

 
Stanislav Korotky:

Esto es una especie de restricción draconiana. ¿Cuál es la razón de ser en los tiempos que corren? ¿Y cómo es conveniente especificar grupos de un montón de caracteres? ¿Para multiplicar una docena de parámetros diferentes? ¿Es conveniente?

La razón está en el protocolo de intercambio con el agente de la prueba.

Para establecer un grupo de caracteres, escriba ese grupo en un archivo de texto y páselo con la propiedad #archivo_de_prueba

 

Pero con una sola prueba, también se pasa al agente de pruebas y funciona sin restricciones.

¿Por qué hay una restricción para la entrada estática también, puede no ser pasado al agente en absoluto.

Si ni siquiera es un error, tómalo como una petición de mejora.

 
Alexey Navoykov:

Error del compilador. Genera un error de ambigüedad, aunque todo es inequívoco aquí.Se debe llamar al primer método como el más adecuado. Probado en C++.

¿Cómo se define el método de mejor ajuste?

 
Slava:

La razón está en el protocolo de intercambio con el agente de la prueba.

Para especificar un grupo de caracteres, escriba ese grupo en un archivo de texto y páselo utilizando la propiedad #archivo_de_prueba

¿Cómo encaja esto con los productos para el usuario final? Puede que el límite estuviera justificado antes, pero lo dudo, basándome en otras cantidades de datos que se transmiten. El aumento del límite no conlleva la amenaza de incompatibilidad.

 
fxsaber:

¿Cómo se determina que es adecuado?

Si hablamos de la norma C++, entonces:

13.3 Resolución de sobrecarga. La resolución de sobrecargas es un mecanismo para seleccionar la mejor función a la que llamar dada una lista de expresiones que van a ser los argumentos de la llamada y un conjunto de funciones candidatas a las que se puede llamar en función del contexto de la llamada. Los criterios de selección de la mejor función son el número de argumentos, la adecuación de los argumentos a la lista de tipos de parámetros de la función candidata, la adecuación del objeto (en el caso de las funciones miembro no estáticas) al parámetro implícito del objeto y algunas otras propiedades de la función candidata. [Nota: No se garantiza que la función seleccionada por la resolución de la sobrecarga sea apropiada para el contexto. Otras restricciones, como la accesibilidad de la función, pueden hacer que su uso en el contexto de llamada esté mal formado.

En otras palabras, debería funcionar así:

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:

Si hablamos de la norma C++, entonces:

13.3 Resolución de sobrecarga. La resolución de sobrecargas es un mecanismo para seleccionar la mejor función a la que llamar dada una lista de expresiones que van a ser los argumentos de la llamada y un conjunto de funciones candidatas a las que se puede llamar en función del contexto de la llamada. Los criterios de selección de la mejor función son el número de argumentos, la adecuación de los argumentos a la lista de tipos de parámetros de la función candidata, la adecuación del objeto (en el caso de las funciones miembro no estáticas) al parámetro implícito del objeto y algunas otras propiedades de la función candidata. [Nota: No se garantiza que la función seleccionada por la resolución de la sobrecarga sea apropiada para el contexto. Otras restricciones, como la accesibilidad de la función, pueden hacer que su uso en el contexto de llamada esté mal formado.

En otras palabras, debería funcionar así:

Para b2, la falta de ambigüedad es total. b1 no lo es.

 
fxsaber:

¿Cómo se determina el adecuado?

En este ejemplo, se solicita un método de objeto no constante, por lo que, en igualdad de condiciones, debería llamarse.

Si eliminamos el casting y hacemos un argumento de tipo int para ambos métodos, el código compilará normalmente. Por lo tanto, el problema en MQL es sobre el casting. Este casting no debe afectar al código porque es idéntico.

 
fxsaber:

Para b2 no hay ninguna ambigüedad. b1 no lo es.

En este caso no es necesario que no haya ambigüedad. Debería ser simplemente el orden en que se aplican los métodos sobrecargados. Es decir, la tarea de resolver la sobrecarga no consiste en crear un dilema, sino en elegir el método más adecuado. Dejando de lado el modificador de acceso, es el primer método de la tabla o depende de la implementación del compilador, pero no hay ambigüedad.

Pero si hubiera 2 métodos, con diferentes parámetros de entrada, por ejemplo:

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

Volviendo a C++, el mismo vector tiene uno:

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

Así que esta es una situación perfectamente normal.

 
Stanislav Korotky:

¿Cómo encaja esto con los productos para el usuario final? Puede que el límite estuviera justificado antes, pero lo dudo, basándome en otras cantidades de datos que se transmiten. El aumento del límite no conlleva la amenaza de incompatibilidad.

Para empezar, en la caché de optimización, tanto en MT5 como en MT4 los parámetros de cadena siempre se han truncado a 63 caracteres.

Cuando se envían eventos, la cadena tampoco puede tener más de 63 caracteres.

Es decir, lo que viene de fuera es limitado

En cuanto a los productos para el usuario final. El vendedor tiene que tener en cuenta las limitaciones. Y si no los conoce, es que no ha probado suficientemente su producto antes de venderlo

1...240824092410241124122413241424152416241724182419242024212422...3187
Nuevo comentario