Вопросы по ООП в MQL5 - страница 80

Новый комментарий
 
Vladimir Simakov:

Согласен)) Это я по плюсовому)))

пока писал тут вон оно как все развернулось

т.е. не по плюсовому, а по мюклу предыдущий вариант будет работать правильно?

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:

пока писал тут вон оно как все развернулось

т.е. не по плюсовому, а по мюклу предыдущий вариант будет работать правильно?

Этот вариант - да))

Только в нем два неявных dynamic_cast
 
Vladimir Simakov:

1) Выделил. Проверка только на следующей строке))) В примере у создателя либы, как раз наоборот, сначала проверка, потом каст)
2) если появится наследник у JSONObject, то с чего это упасть должно?

1) По сути один и тот же код в рамках данной темы обсуждается несколько дней: тут, и тут, и тут.
То что в одном из примеров пользовательского использования библиотеки нашли проблему - вы молодец, спасибо.
Однако вы заявляли о проблеме в логике использования библиотеке в целом, а на деле оказалось, что проблема касается конкретного примера.

2) Где вы увидели заявление, что что-то должно упасть?
Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.

 
Sergey Dzyublik:

2) Где вы увидели заявление, что что-то должно упасть?
Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.

ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)

 
Sergey Dzyublik:

Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.

маловероятно, мой пример это метод из базового класса, JSONObject * это  результат выполнения, это указатель на парсер, а сам json-парсинг в методе наследника происходит с полученным указателем, который и нужно было "прибить" в упомянутых ранее моих вопросах

проверок довольно много, в предложенном примере 3 шт и в производном классе каждый вызов методов getInt(), getDouble() происходят с проверками

 
Vladimir Simakov:

ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)

Опять двадцать пять, при чем тут указатели и не указатели, мануалы и т.д. ?
В вашем примере из функции будет выкинута часть ЛОГИКИ, а именно проверка jv.isObject()
Данная ЛОГИКА была заменена на проверку через dynamic_cast.
Для текущей версии библиотеке - все ок, но, теоретически, если в следующей версии появится новый класс, который использует JSONObject как базовый, то не факт, что ваш пример сможет с ним корректно отработать.

 
Sergey Dzyublik:

Опять двадцать пять, при чем тут указатели и не указатели, мануалы и т.д. ?
В вашем примере из функции будет выкинута часть ЛОГИКИ, а именно проверка jv.isObject()
Данная ЛОГИКА была заменена проверку через dynamic_cast.
Для текущей версии библиотеке - все ок, но, теоретически, если в следующей версии появится новый класс, который использует JSONObject как базовый, то не факт, что ваш пример сможет с ним корректно отработать.

Так и другой вариант так же с ним не сможет работать)

 
Andrei Trukhanovich:
UB никакого нет, mql каст включает в себя в том числе и dynamic_cast. просто все упадет в случае неправильного указателя.

Разве? В случае  dynamic_cast ничего не упадёт, если проверить результат на NULL. При обычном касте сразу упадёт. Или  я не про то понял?

 
Vladimir Simakov:

ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)

В плюсах должно произойти исключение. И письмо авторам, потому как исключение не есть хорошо, а просто затыка. В mql такого нет, поэтому классы выдумываются с прицелом на будущее, с полным протоколом. 

Про обсуждаемые json  -  вариантов всего 2, либо следовать стилю и решениям автора либо делать свой форк.  Прочее от лукавого. 😉

 
Vladimir Simakov:

И поделом))) НИКОГДА нельзя напрямую кастить от базового к наследнику - это UB ( UNDEFINED BEHAVIOR)

В плюсах вообще опасно кастить ссылки (хоть вверх, хоть вниз) через стандартный оператор приведения, который нам привычен и удобен.

1...737475767778798081828384858687...97
Новый комментарий