Cuestión de mecanografía - página 3

Nuevo comentario
 
Ilya Malev:

El error de desajuste de plantilla debería producirse probablemente en tiempo de compilación.


Pero en la situación en la que hay un objeto array

Dicho error no debería producirse porque en el primer caso se utiliza la llamada de Array[int] como parámetro izquierdo de la operación = y no es variable de tipo double, mientras que en el segundo caso es el derecho, y el parámetro izquierdo es variable de tipo double.

No oyes, no debería hacer nada - la sobrecarga de tipos está prohibida y está explícitamente escrita en el estándar C++ (y µl como C++ similar - probablemente también):

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

La razón probable se explica más arriba. Así que tu operador[] no es válido.

 
pavlick_:

No oyes, no debería hacer nada - la sobrecarga por tipo está prohibida y está explícitamente escrita en el estándar C++:

La razón probable que di arriba. Así que sus operadores[] no son válidos.

No te estaba respondiendo sobre la norma, sino sobre la lógica basada en el sentido común. Su definición de causa "probable" no invalida mis argumentos. La posibilidad de sobrecargar una operación de tipificación (incluso implícitamente) no contradice la norma que has citado, porque lo que se sobrecarga es la operación de casting a un tipo concreto definido explícitamente desde el contexto.

Quizás no fui demasiado claro, pero esta aclaración espero que lo aclare.


P.D. Por supuesto, mi código ficticio contradice la norma. Pero si tienes que descifrarlo (porque yo estaba averiguando por mí mismo cómo formular la pregunta con más precisión), debería ser así:

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
Si defiende el operador type(), bien. Si abogas por la sangría de los pluses, entonces estoy en contra (permitiendo la sobrecarga por tipo de retorno) para resolver algún problema particular (que probablemente podría resolverse de forma diferente y más bonita - de alguna manera nunca llegué a hacerlo como en el primer post).
 
pavlick_:
Si defiende el operador type(), bien. Si abogas por la indentación de los pluses, entonces estoy en contra (permitiendo la sobrecarga por tipo de retorno) para resolver algún problema particular (que seguramente se puede resolver de otra manera y más bonita - de alguna manera nunca se me torció como en el primer post).

Sí. Al final, estoy a favor de la introducción del operador tipográfico. Porque resuelve exactamente el problema, que expuse en el post inicial, sólo que de una manera más "convencional" (ajustada a las normas, y probablemente más correcta en general).

 
Ilya Malev:

P.D. Por supuesto, mi código inventado va en contra de la norma.

Por qué contradice la norma, es perfectamente válido en los pluses. Y no hay muelles en absoluto en Mcl.
 
pavlick_:
Por qué es contradictorio, en los pluses es bastante válido. Y en mql no hay ningún muelle.

Porque originalmente había dos funciones operator[] idénticas con diferente tipo de retorno (lo arreglé en la segunda versión). Esto está prohibido por la norma. Pero citar tipos (incluso de forma implícita) no está prohibido, simplemente no han tenido tiempo de implementarlo todavía. Teniendo en cuenta el impresionante ritmo de desarrollo de mql5, estoy seguro de que se implementará tarde o temprano. Especialmente si alguien además de mí le presta atención en el foro...

 
Ilya Malev:

Porque había dos funciones operator[] idénticas con distinto tipo de retorno. Esto está prohibido por la norma. No está prohibido teclear (ni siquiera implícitamente), simplemente no han tenido tiempo de implementarlo todavía. Teniendo en cuenta la gran velocidad de desarrollo de mql5 estoy seguro de que se implementará tarde o temprano. Sobre todo si alguien, además de mí, le presta atención en el foro...

Me refiero al último código - está bien.

 
pavlick_:

Me refiero al último código - está bien.

Está bien, pero aún no funciona en mql5. Sigamos y esperemos innovaciones en mql5. Es esta incapacidad de implementar adecuadamente un objeto array, debido a la incapacidad de manejar un tipo de usuario de la misma manera que con un array ordinario, lo que me ha estado molestando personalmente durante mucho tiempo. Cuando creas tu propia matriz, resulta ser defectuosa desde el principio, no posee las mismas propiedades de usabilidad que las incorporadas.

 
Ilya Malev:

Está bien, pero aún no funciona en mql5. Sigamos y esperemos innovaciones en mql5. Es esta incapacidad de implementar adecuadamente un objeto array, debido a la incapacidad de manejar un tipo de usuario de la misma manera que con un array ordinario, lo que me ha estado molestando personalmente durante mucho tiempo. Cuando haces tu propia matriz, al principio resulta ser defectuosa, no tiene la misma utilidad que una incorporada.

Bueno, no espero grandes milagros, el lenguaje ya no está siendo desarrollado, dudo que añadan un operador fantasma. En este caso, me estresa específicamente la imposibilidad de hacerlo así:

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

pero es inútil decirlo, creo.

 
pavlick_:

Bueno, no espero grandes milagros, el lenguaje ya no está realmente desarrollado, dudo que añadan un operador fantasma. Lo que me molesta en particular es la incapacidad de hacerlo así:

Pero es inútil hablar de ello, creo.

No está muy claro cuál es el problema. ¿No podría implementarse la inicialización del objeto en un método separado como Init(), tal vez incluso en uno virtual?

12345678910
Nuevo comentario