Perguntas sobre OOP em MQL5 - página 80

[Igor Makanu]

Vladimir Simakov:

Eu concordo)))) Esse sou eu no lado positivo)).

Eu vi como tudo se desdobra enquanto escrevia.

Isto é, não no lado positivo, mas no açaime da versão anterior funcionará bem?

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);
}

[Vladimir Simakov]

Igor Makanu:

enquanto eu escrevia isto, tudo mudou.

Isto é, não no lado positivo, mas no lado do açaime a opção anterior funcionará bem?

Esta opção - sim))

Somente tem dois processos_dinâmicos implícitos

[Sergey Dzyublik]

Vladimir Simakov:

1) Em destaque. Verifique apenas na linha seguinte)))) No exemplo do criador da libra, exatamente o contrário, primeiro verificar, depois lançar)
2) se o JSONObject tem um herdeiro, por que ele deveria cair?

1) Basicamente um e o mesmo código é discutido por vários dias dentro desta linha:aqui, aqui e aqui.
O fato de você ter encontrado um problema em um dos exemplos de utilização da biblioteca pelos usuários - muito bem, obrigado.
No entanto, você declarou um problema na lógica de utilização da biblioteca como um todo, mas na verdade, verificou-se que o problema dizia respeito a um exemplo específico.

2) Onde você viu a afirmação de que algo deveria acontecer?
Não, poderia ser muito pior - o código funcionará bem, mas produzirá resultados incorretos.

[Vladimir Simakov]

Sergey Dzyublik:

2) Onde você viu a afirmação de que algo deveria acontecer?
Não, poderia ser muito pior - o código funcionará bem, mas produzirá resultados incorretos.

IMHO é claro, mas se eu em lib, ao me referir a um objeto por um ponteiro a uma classe base, tiver um comportamento indefinido, ele deve ser refletido no manual da biblioteca (ele está lá?), mas não deve estar lá)

[Igor Makanu]

Sergey Dzyublik:

Não, poderia ser muito pior - o código funcionará bem, mas produzirá resultados incorretos.

improvável, meu exemplo é um método de uma classe base, JSONObject * é o resultado da execução, é um ponteiro para o analisador, e o próprio analisador do pastor no método descendente acontece com o ponteiro recebido, que deveria ser "pregado" em minhas perguntas mencionadas anteriormente

existem muitas verificações, no exemplo proposto existem 3 pcs e na classe derivada cada chamada de getInt(), getDouble() os métodos getDouble() ocorrem com verificações

[Sergey Dzyublik]

Vladimir Simakov:

IMHO é claro, mas se eu em lib, ao me referir a um objeto por um ponteiro a uma classe base, tiver um comportamento indefinido, ele deve ser refletido no manual da biblioteca (ele está lá?), mas não deve ser assim)

Mais uma vez, o que os ponteiros e não ponteiros, manuais, etc. têm a ver com isso? ?
Em seu exemplo, parte do LOGIC será removida da função, a saber, a verificaçãojv.isObject()
Este LOGIC foi substituído por uma verificação via dynamic_cast.
Para a versão atual da biblioteca tudo está bem, mas, teoricamente, se na próxima versão houver uma nova classe que useo JSONObject como base, não o fato de que seu exemplo pode funcionar corretamente com ele.

[Vladimir Simakov]

Sergey Dzyublik:

Mais uma vez, o que os ponteiros e não ponteiros, manuais, etc. têm a ver com isso? ?
Em seu exemplo, parte do LOGIC será removida da função, ou seja, verificarjv.isObject()
Este LOGIC foi substituído por uma verificação via dynamic_cast.
Para a versão atual da biblioteca tudo está bem, mas, teoricamente, se na próxima versão houver uma nova classe que useo JSONObject como base, não o fato de que seu exemplo funcionará corretamente.

Portanto, outra versão também não poderá funcionar corretamente)

[Aleksey Mavrin]

Andrei Trukhanovich:
Não há UB, o elenco mql inclui também Dynamic_cast. apenas tudo cairá em caso de ponteiro errado.

Será? Em caso de dynamic_cast, nada cairá se você verificar o resultado para NULL. Com elenco normal, ele cairá imediatamente. Ou será que eu me enganei?

[Maxim Kuznetsov]

Vladimir Simakov:

IMHO é claro, mas se em lib, quando me refiro a um objeto por ponteiro a uma classe base, tenho um comportamento indefinido, ele deve ser refletido no manual da biblioteca (ele está lá?), mas não deve ser assim)

Deve haver uma exceção nos profissionais. E uma carta aos autores, porque uma exceção não é uma coisa boa, é apenas uma tomada. Não existe tal coisa em mql, portanto, as aulas são feitas com o futuro em mente, com protocolo completo.

Sobre o json discutido - você tem apenas 2 opções, ou segue o estilo e as soluções do autor ou faz seu próprio garfo. O resto é maligno. 😉

[Alexey Navoykov]

Vladimir Simakov:

E vale bem a pena)))) NUNCA é fundido diretamente da base para o descendente - isto é UB (UNDEFINED BEHAVIOR).

Em pluses, é perigoso lançar referências (seja para cima ou para baixo) através do operador de fundição padrão, o que é familiar e conveniente para nós.