Preguntas sobre POO en MQL5 - página 80

 
Vladimir Simakov:

Estoy de acuerdo))) Así soy yo en el lado positivo)).

He visto cómo se desenvuelve todo mientras escribo.

Es decir, no en el lado positivo, pero en la boca del cañón de la versión anterior funcionará correctamente?

JSONObject * CActor::getJSONObject(const string json)const
{
   JSONParser parser;
   JSONValue  *jv = parser.parse(json);
   if (jv != NULL && jv.isObject() && (EACTOR_TYPE)(((JSONObject *)jv).getInt("ActorType")) == ActorType) return(jv);
   Print(__FUNCTION__ + "parser error, json = ",json);
   delete jv;
   return(NULL);
}
 
Igor Makanu:

mientras escribía esto, todo se ha dado la vuelta.

Es decir, no en el lado de la ventaja, pero en el lado de la boca del cañón de la opción anterior va a funcionar, ¿verdad?

Esta opción - sí))

Sólo tiene dos dynamic_casts implícitos
 
Vladimir Simakov:

1) Destacado. Compruebe sólo en la línea siguiente)) En el ejemplo del creador de la lib, justo lo contrario, primero comprueba, luego lanza)
2) si JSONObject tiene un heredero, ¿por qué debería caer?

1) De hecho se está discutiendo un mismo código desde hace varios días dentro de este hilo:aquí, aquí y aquí.
El hecho de que hayas encontrado un problema en uno de los ejemplos de uso de la biblioteca por parte de los usuarios, bien hecho, gracias.
Sin embargo, has manifestado un problema en la lógica de uso de la biblioteca en su conjunto, pero en realidad resulta que el problema se refiere a un ejemplo concreto.

2) ¿Dónde has visto la afirmación de que hay que bajar algo?
No, podría ser mucho peor: el código funcionará bien, pero producirá resultados incorrectos.

 
Sergey Dzyublik:

2) ¿Dónde has visto la afirmación de que hay que bajar algo?
No, podría ser mucho peor: el código funcionará bien, pero producirá resultados incorrectos.

IMHO por supuesto, pero si yo en la lib, al referirme a un objeto por un puntero a una clase base, obtengo un comportamiento indefinido, debería reflejarse en el manual de la librería (¿está ahí?), pero no debería ser así)

 
Sergey Dzyublik:

No, podría ser mucho peor: el código funcionará bien, pero producirá resultados incorrectos.

Es poco probable, mi ejemplo es un método de una clase base, JSONObject * es el resultado de la ejecución, es un puntero al parser, y el propio parsing de json en el método descendiente ocurre con el puntero recibido, que debía ser "clavado" en mis preguntas anteriormente mencionadas

hay bastantes comprobaciones, en el ejemplo propuesto hay 3 pcs y en la clase derivada cada llamada a los métodos getInt(), getDouble() se produce con comprobaciones

 
Vladimir Simakov:

IMHO por supuesto, pero si yo en la lib, al referirme a un objeto por un puntero a una clase base, obtengo un comportamiento indefinido, debería reflejarse en el manual de la librería (¿está ahí?), pero no debería ser así)

De nuevo, ¿qué tienen que ver los punteros y no punteros, los manuales, etc.? ?
En su ejemplo, se eliminará parte de la LÓGICA de la función, concretamente la comprobaciónjv.isObject()
. Esta LÓGICA ha sido sustituida por una comprobación mediante dynamic_cast.
Para la versión actual de la librería todo está bien, pero, teóricamente, si en la próxima versión habrá una nueva clase que utiliceJSONObject como base, no por ello tu ejemplo puede funcionar con ella correctamente.

 
Sergey Dzyublik:

De nuevo, ¿qué tienen que ver los punteros y no punteros, los manuales, etc.? ?
En su ejemplo, se eliminará parte de la LÓGICA de la función, a saber, la comprobación dejv.isObject()
. Esta LÓGICA ha sido sustituida por la comprobación mediante dynamic_cast.
Para la versión actual de la librería todo está bien, pero, teóricamente, si en la próxima versión habrá una nueva clase que utiliceJSONObject como base, no por ello tu ejemplo funcionará con ella correctamente.

Por lo tanto, otra versión tampoco podrá funcionar correctamente)

 
Andrei Trukhanovich:
No hay UB, mql cast incluye también dynamic_cast. simplemente todo caerá en caso de puntero equivocado.

¿Lo es? En el caso de dynamic_cast no caerá nada si se comprueba que el resultado es NULL. Con el reparto normal, caerá inmediatamente. ¿O me he equivocado?

 
Vladimir Simakov:

IMHO por supuesto, pero si en la lib, al referirme a un objeto por puntero a una clase base, obtengo un comportamiento indefinido, debería reflejarse en el manual de la librería (¿está ahí?), pero no debería ser así)

Debería haber una excepción en los profesionales. Y una carta a los autores, porque una excepción no es algo bueno, sólo un tapón. En mql no existe tal cosa, por lo que las clases se confeccionan pensando en el futuro, con un protocolo completo.

Sobre el json discutido - sólo tienes 2 opciones, o seguir el estilo y las soluciones del autor o hacer tu propio fork. El resto es malo. 😉

 
Vladimir Simakov:

Y merece la pena))) NUNCA lances directamente de base a descendiente - esto es UB (UNDEFINED BEHAVIOR).

En los pluses, es peligroso lanzar referencias (ya sean ascendentes o descendentes) a través del operador estándar gimme, que nos resulta familiar y cómodo.

Razón de la queja: