Domande su OOP in MQL5 - pagina 80

 
Vladimir Simakov:

Sono d'accordo))) Questo è il mio lato positivo)).

Ho visto come tutto si svolge mentre scrivo.

Cioè non sul lato positivo, ma sul muso della versione precedente funzionerà bene?

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:

Mentre scrivevo questo, tutto si è ribaltato.

Cioè non sul lato positivo, ma sul lato del muso l'opzione precedente funzionerà giusto?

Questa opzione - sì))

Solo che ha due dynamic_cast impliciti
 
Vladimir Simakov:

1) Evidenziato. Controlla solo sulla linea successiva))) Nell'esempio del creatore della lib, proprio il contrario, prima controllare, poi lanciare)
2) se JSONObject ha un erede, perché dovrebbe cadere?

1) Fondamentalmente uno stesso codice è discusso per diversi giorni in questo thread:qui, qui e qui.
Il fatto che tu abbia trovato un problema in uno degli esempi di utilizzo della libreria da parte degli utenti - ben fatto, grazie.
Tuttavia, hai indicato un problema nella logica di utilizzo della libreria nel suo insieme, ma in realtà si è scoperto che il problema riguardava un esempio specifico.

2) Dove hai visto l'affermazione che qualcosa dovrebbe scendere?
No, potrebbe essere molto peggio - il codice funzionerà bene, ma produrrà risultati errati.

 
Sergey Dzyublik:

2) Dove hai visto l'affermazione che qualcosa dovrebbe scendere?
No, potrebbe essere molto peggio - il codice funzionerà bene, ma produrrà risultati errati.

IMHO naturalmente, ma se io in lib, quando mi riferisco a un oggetto tramite un puntatore a una classe base, ottengo un comportamento non definito, dovrebbe riflettersi nel manuale della libreria (c'è?), ma non dovrebbe essere)

 
Sergey Dzyublik:

No, potrebbe essere molto peggio - il codice funzionerà bene, ma produrrà risultati errati.

improbabile, il mio esempio è un metodo di una classe base, JSONObject * è il risultato dell'esecuzione, è un puntatore al parser, e l'analisi json stessa nel metodo discendente avviene con il puntatore ricevuto, che doveva essere "inchiodato" nelle mie domande precedentemente menzionate

ci sono un bel po' di controlli, nell'esempio proposto ci sono 3 pc e nella classe derivata ogni chiamata dei metodi getInt(), getDouble() avviene con controlli

 
Vladimir Simakov:

IMHO naturalmente, ma se io in lib, quando mi riferisco a un oggetto tramite un puntatore a una classe base, ottengo un comportamento non definito, dovrebbe riflettersi nel manuale della libreria (c'è?), ma non dovrebbe essere così)

Di nuovo, cosa c'entrano i puntatori e i non puntatori, i manuali, ecc. ?
Nel vostro esempio, una parte della LOGICA sarà rimossa dalla funzione, cioè il controllo dijv.isObject()
Questa LOGICA è stata sostituita dal controllo tramite dynamic_cast.
Per la versione attuale della libreria tutto è ok, ma, teoricamente, se nella prossima versione ci sarà una nuova classe che usaJSONObject come base, non è detto che il tuo esempio possa funzionare correttamente con essa.

 
Sergey Dzyublik:

Di nuovo, cosa c'entrano i puntatori e i non puntatori, i manuali, ecc. ?
Nel vostro esempio, una parte della LOGICA sarà rimossa dalla funzione, cioè il controllo dijv.isObject()
Questa LOGICA è stata sostituita dal controllo tramite dynamic_cast.
Per la versione attuale della libreria tutto è ok, ma, teoricamente, se nella prossima versione ci sarà una nuova classe che usaJSONObject come base, non è detto che il tuo esempio funzioni correttamente con essa.

Quindi, anche un'altra versione non sarà in grado di lavorare correttamente con esso)

 
Andrei Trukhanovich:
Non c'è UB, mql cast include anche dynamic_cast. semplicemente tutto cadrà in caso di puntatore sbagliato.

Lo è? In caso di dynamic_cast non cade nulla se si controlla il risultato per NULL. Con il getto normale, cadrà immediatamente. O ho sbagliato?

 
Vladimir Simakov:

IMHO naturalmente, ma se in lib, quando si fa riferimento a un oggetto tramite puntatore a una classe base, ottengo un comportamento non definito, allora dovrebbe essere riflesso nel manuale della libreria (c'è?), ma non dovrebbe essere così)

Ci dovrebbe essere un'eccezione nei professionisti. E una lettera agli autori, perché un'eccezione non è una buona cosa, è solo una spina. Non c'è una cosa del genere in mql, quindi le classi sono fatte con il futuro in mente, con un protocollo completo.

Riguardo al discusso json - hai solo 2 opzioni, o segui lo stile e le soluzioni dell'autore o fai il tuo fork. Il resto è male. 😉

 
Vladimir Simakov:

E ne vale la pena))) MAI lanciare direttamente dalla base al discendente - questo è UB (UNDEFINED BEHAVIOR).

In plus, è pericoloso lanciare i riferimenti (sia verso l'alto che verso il basso) attraverso l'operatore cast standard, che è familiare e conveniente per noi.