Error del compilador con el parámetro de la plantilla = void* - página 18

 
Igor Makanu:

Actualmente, me gustaría adjuntar la forma VS a .dll a MT5 de una manera simple )))) - Quiero envolver los manejadores de clic de los botones en una clase y llamarlos recorriendo un array de punteros de funciones manejadoras, y quiero tener en el código principal del EA la posibilidad de escribir los mismos nombres de función que en VS, es decir, button2_Click() ....button2_Click()

SZY: Este es un problemade EOP))))

No te ofendas, pero me recuerda mucho:


1
 
Ilya Malev:

- Crear estructuras automáticas dentro de una POO dinámica es un sinsentido

¿Así que apilar objetos: myclass obj; no tiene sentido? Entonces, soy un discapacitado :)

 
pavlick_:

Entonces, apilar objetos: myclass obj; no tiene sentido? Así que soy un artesano :)

Hay todo tipo de tareas. Se puede practicar la retórica durante mucho tiempo, si no se describen las tareas específicas, se puede llegar a cualquier cosa...

Sí, los objetos "apilables" (¿automáticos?) son básicamente un sinsentido. En mi humilde opinión, que no es en absoluto la verdad y desde luego no en el último caso...
 
Un comodín necesita un objeto que no realice la función principal de la POO: la propiedad del polimorfismo? No podrás asignar a una variable de este tipo ningún objeto con propiedades diferentes en función del contenido. No podrás asignar otro objeto a esta "variable" de la lista en absoluto. ¿Por qué necesitas objetos? ¿No es mejor utilizar estructuras en su lugar? Quizás porque las estructuras µl no pueden devolver referencias a sí mismas... Y con ellos comienza una cosa oscura con la creación-destrucción-autocopia constante, etc.
 
Ilya Malev:
¿Quiere un objeto que no cumpla la función principal de la programación orientada a objetos, la propiedad del polimorfismo? No podrás asignar a una variable de este tipo ningún objeto con propiedades diferentes en función del contenido. No podrás asignar otro objeto a esta "variable" de la lista en absoluto. ¿Por qué necesitas objetos? ¿No es mejor utilizar estructuras en su lugar? Quizás porque las estructuras µl no pueden devolver referencias a sí mismas... Y con ellos comienza una cosa oscura con la creación-destrucción-autocopia constante, etc.

Cómo vivir sin polimorfismo ... ¿Y si digo que podemos prescindir del polimorfismo en >90% de los casos? Tomemos el "principio de inversión de dependencia SOLID", si somos progers decentes, deberíamos crear abstracciones, métodos virtuales en todas partes (lo que conlleva grandes gastos generales, por supuesto). Los adeptos a C# escribirían algo como esto https://pro-prof.com/forums/topic/dependency-inversion-principle. O podríamos tomar plantillas y escribir algo así:

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


Button también es independiente de los detalles, sin todo el polimorfismo y las interfaces. El polimorfismo tiene su propio nicho, pero es mucho más estrecho de lo que dicen.

ZS: bueno, nadie lo prohíbe:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Por supuesto, podemos prescindir del polimorfismo, pero para este caso es mucho más honesto y lógico utilizar estructuras simples en lugar de objetos, de lo contrario estamos clavando un microscopio. Para ser más precisos, en el caso de µl5, más bien obviamos las "características de implementación" que no permiten utilizar plenamente las estructuras no objetuales (imposibilidad de pasarles punteros, a diferencia de los objetos). Este es un problema totalmente diferente, ya no es OOP, sino simplemente OO
 
pavlick_:

ZS: bueno, nadie lo prohíbe:

Nadie prohíbe todo tipo de muletas y esquematosis, pero ¿por qué? Por ejemplo: será divertido que tu autoobjeto se autodestruya de repente cuando menos te lo esperes, ¿no?

 
El sentido de la POO no es utilizar el método que elijas para pulsar el botón, que puedes implementar igualmente a través de plantillas o punteros de función, sino simplemente aplicar a cualquier objeto del sistema métodos como list, que permiten autoorganizarse en estructuras de lista y crear selecciones arbitrarias en el momento adecuado sin necesidad de muletas como CArrayObj, etc. y el engorro asociado, sobrecargando métodos como Select, Query, Compare, Sort, etc. (e incluso Clonar/Copiar, cuando cada objeto puede decidir sin tu participación si debe ser copiado en una lista/matriz o no, y si es copiado, cómo debe ser copiado).
 
Ilya Malev:

Nadie prohíbe inventarse muletas y esquematosis, pero ¿por qué? Por ejemplo: será divertido que tu auto-objeto se destruya de repente cuando menos lo esperes, ¿no?

Porque un objeto de la pila es mucho más rápido que un objeto del montón(asignación de memoria). ¿Autodestrucción? - Eso es algo nuevo :). Pero a veces es necesario, por supuesto: el número de objetos sólo se conoce en tiempo de ejecución, por ejemplo.

ZS: puedes estar más cómodo de otra manera, es una cuestión personal.

 
Ilya Malev:
El sentido de la POO no es utilizar el método que elijas para pulsar el botón, que puedes implementar igualmente a través de plantillas o punteros de función, sino simplemente aplicar a cualquier objeto del sistema métodos como list, que permiten autoorganizarse en estructuras de lista y crear selecciones arbitrarias en el momento adecuado sin necesidad de muletas como CArrayObj, etc. y el engorro asociado, sobrecargando métodos como Select, Query, Compare, Sort, etc. (e incluso Clonar/Copiar, cuando cada objeto puede decidir sin tu participación si se copia en una lista/matriz o no, y si se copia, cómo).

Escribí - el polimorfismo tiene su propio nicho, no estoy discutiendo. Pero la práctica demuestra (la mía, al menos) que no es tan significativa. Es mucho más probable que resuelva los problemas con las plantillas.