OOP, plantillas y macros en mql5, sutilezas y usos - página 13

 

Justo ayer estábamos discutiendo sobre este error con los métodos abstractos, pero hoy me encontré con el mismo error en mi código ) Yo solía tener un método virtual no abstracto en la clase base, por lo que me refiero a él desde las clases heredadas, entonces decidí hacer el método abstracto, pero el compilador no me informó de que ya no es referbable. Como resultado, el error de recursión fue el más desagradable y difícil de detectar, y perdí mucho tiempo. Ahora creo que esa función con cuerpo de método abstracto por defecto será muy útil aquí, al menos hasta que se solucione este error.

 
Alexey Navoykov:

Sí, para que sea lo más cómodo posible asignar las moscas a las chuletas, y nadie ni siquiera pestañeó )

Si el proceso de asignación lleva las moscas a las chuletas (o produce un error si no es posible), entonces no hay nada malo en ello.

Alexey Navoykov:

1.Bueno, entonces es sólo la clase A. ¿Por qué declarar un patrón si su parámetro no tiene ningún significado que ver con el comportamiento de la clase?

2) Es un problema demasiado grande. Transferir el control del tipo a la etapa de ejecución... Sus códigos tardarán años en ser depurados

1. "Sólo la clase A" no puede contener un campo de un tipo arbitrario sin su parametrización (de clase). Y sin esos bailes, que he descrito, es imposible hacer un manejo uniforme de un parámetro de clase por referencia y por valor.

2. Ya lo tienes como un mantra - en este caso registro absolutamente inequívoco que garantiza que F es T, es decir como si no hubiera registro de la segunda plantilla. pero no. De nuevo "me pasaré años depurando" ))))))

 
Ilya Malev:

1. "Sólo clase A" no puede contener un campo de tipo arbitrario sin su parametrización (de clase). Y sin esos retoques que describí, es imposible hacer un manejo uniforme de un parámetro de clase por referencia y por valor.

2. Ya lo tienes como un mantra - en este caso registro absolutamente inequívoco que garantiza que F es T, es decir como si no hubiera registro de la segunda plantilla. pero no. De nuevo "ya me pasaré años depurando" ))))))

¿Y por qué respondes en este hilo? El código en un lugar, la discusión en otro... )

1. Sí, todo se puede hacer humanamente, y casi sin bailar:

struct __A
{
  template<typename T>
  void f(T&) { }  // Сюда структуры и классы
};

struct A : __A
{
  template<typename T>  
  void f(T) { }  // Сюда простые типы и указатели
};

2. No me refería a eso, pero no importa.

 
Alexey Navoykov:

¿Por qué responden en este hilo? El código en un lugar, la discusión en otro... )

1. Sí, todo se puede hacer de forma humana, y casi sin bailar:

2. Había algo más allí, pero no es la cuestión.

No es que seas un moderador todavía, para determinar en qué hilo lo que es más apropiado. Y los moderadores ya han dejado claro que las discusiones sobre las características no deben realizarse en la propia rama de características, sino en una rama aparte, es decir, aquí.

En su descripción, no queda nada claro cómo referirse uniformemente a un método de la clase por referencia y por un valor de tipo T. No sé qué quieres decir con eso, pero es exactamente lo que quería decir allí.

 
Ilya Malev:

No es que seas un moderador todavía, para determinar qué hilos son más apropiados. Y los moderadores ya han dejado claro que la discusión de las características no debe realizarse en la rama de características, y en un hilo aparte, es decir, aquí.

Así que si un moderador quiere moverlo, es una cosa, pero ¿por qué crear la confusión usted mismo? Yo, por ejemplo, no tengo ningún deseo de correr a través de los hilos.

 
Alexey Navoykov:

Así que si un moderador quiere moverlo, es una cosa, pero ¿por qué crear la confusión usted mismo? Yo, por ejemplo, no tengo ningún deseo de correr a través de los hilos.

Si sabes que un moderador haría algo así, siempre es mejor hacerlo tú mismo en lugar de esperar a que un moderador lo haga. Sin embargo, discutir las acciones de los moderadores tampoco es uno de los menús favoritos de los moderadores, así que sería mejor que lo dejáramos.

 
Alexey Navoykov:
Сюда простые типы и указатели

Para los punteros, por cierto, es lógico hacer un método separado con el argumento T*, porque definitivamente no hay confusión, y la ventaja es que la mayoría de las veces el manejo de los punteros es diferente al de los tipos regulares (comprobación de validez, borrado, etc.)

 
Alexey Navoykov:

El código en un lugar, la discusión en otro

Aquí está el código:

template<typename T>
class A
 {
public:
  A* operator<<(T&p){ Print("<< &",typename(T)); return &this; }
  template<typename F>
  A* operator<<(F p){ Print("<< ",typename(F)); return &this; }
 };

En realidad hay otra solución además de esta entrada: listar por nombre todos los tipos simples pasados por valor y luego escribir un método de plantilla con &, entonces tampoco habrá error. Esta opción es adecuada para clases sin parametrización intrínseca

 
Ilya Malev:

Si te das cuenta de que un moderador probablemente haría exactamente eso, siempre es mejor hacerlo tú mismo, en lugar de esperar a que lo haga un moderador. Sin embargo, discutir las acciones de los moderadores tampoco es un menú favorito de los moderadores, así que sería mejor que lo dejáramos.

Un moderador ciertamente no rompería la discusión en diferentes hilos. Seguramente estás tan ansioso de incluso prohibirte a ti mismo,"sin esperar a que un moderador lo haga" ))
 
Ilya Malev:

Si te das cuenta de que un moderador probablemente haría exactamente eso, siempre es mejor hacerlo tú mismo, en lugar de esperar a que lo haga un moderador. Sin embargo, discutir las acciones de los moderadores tampoco es un menú favorito de los moderadores, así que sería mejor que lo dejáramos.

1. Sería mejor empezar a hablar de algo de inmediato, donde se encuentra este "algo", en lugar de pensar en cómo lo haría el moderador. De lo contrario, todo se desdibujó en dos hilos y ahora, aunque un moderador decida que la discusión debe estar ahí o allá, es una tarea bastante laboriosa mover la discusión de forma normal, conservando el orden y el sentido de los mensajes.

2 Discutir las acciones de un moderador no es cualquier estornudo... No se trata de cada estornudo, sino de cuando se cuestionan públicamente sus acciones, ya sea para restablecer el orden o pacificar a los alborotadores. Y si tienes una opinión, ¿quién te prohíbe expresarla? ¿Quizás tu opinión es una sugerencia muy racional, pero tienes miedo de decirla, para no caer en el menú no querido del moderador? Así que eso es una mierda :)