![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Согласен)) Это я по плюсовому)))
пока писал тут вон оно как все развернулось
т.е. не по плюсовому, а по мюклу предыдущий вариант будет работать правильно?
пока писал тут вон оно как все развернулось
т.е. не по плюсовому, а по мюклу предыдущий вариант будет работать правильно?
Этот вариант - да))
Только в нем два неявных dynamic_cast1) Выделил. Проверка только на следующей строке))) В примере у создателя либы, как раз наоборот, сначала проверка, потом каст)
2) если появится наследник у JSONObject, то с чего это упасть должно?
1) По сути один и тот же код в рамках данной темы обсуждается несколько дней: тут, и тут, и тут.
То что в одном из примеров пользовательского использования библиотеки нашли проблему - вы молодец, спасибо.
Однако вы заявляли о проблеме в логике использования библиотеке в целом, а на деле оказалось, что проблема касается конкретного примера.
2) Где вы увидели заявление, что что-то должно упасть?
Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.
2) Где вы увидели заявление, что что-то должно упасть?
Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.
ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)
Нет, может быть намного хуже - код будет отлично работать, но выдавать некорректный результат.
маловероятно, мой пример это метод из базового класса, JSONObject * это результат выполнения, это указатель на парсер, а сам json-парсинг в методе наследника происходит с полученным указателем, который и нужно было "прибить" в упомянутых ранее моих вопросах
проверок довольно много, в предложенном примере 3 шт и в производном классе каждый вызов методов getInt(), getDouble() происходят с проверками
ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)
Опять двадцать пять, при чем тут указатели и не указатели, мануалы и т.д. ?
В вашем примере из функции будет выкинута часть ЛОГИКИ, а именно проверка jv.isObject()
Данная ЛОГИКА была заменена на проверку через dynamic_cast.
Для текущей версии библиотеке - все ок, но, теоретически, если в следующей версии появится новый класс, который использует JSONObject как базовый, то не факт, что ваш пример сможет с ним корректно отработать.
Опять двадцать пять, при чем тут указатели и не указатели, мануалы и т.д. ?
В вашем примере из функции будет выкинута часть ЛОГИКИ, а именно проверка jv.isObject()
Данная ЛОГИКА была заменена проверку через dynamic_cast.
Для текущей версии библиотеке - все ок, но, теоретически, если в следующей версии появится новый класс, который использует JSONObject как базовый, то не факт, что ваш пример сможет с ним корректно отработать.
Так и другой вариант так же с ним не сможет работать)
UB никакого нет, mql каст включает в себя в том числе и dynamic_cast. просто все упадет в случае неправильного указателя.
Разве? В случае dynamic_cast ничего не упадёт, если проверить результат на NULL. При обычном касте сразу упадёт. Или я не про то понял?
ИМХО конечно, но если я в либе, при обращении к объекту по указателю на базовый класс получаю неопределенное поведение, то это должно отражаться в мануале к библиотеке (это там есть?), а так-то этого не должно быть)
И поделом))) НИКОГДА нельзя напрямую кастить от базового к наследнику - это UB ( UNDEFINED BEHAVIOR)
В плюсах вообще опасно кастить ссылки (хоть вверх, хоть вниз) через стандартный оператор приведения, который нам привычен и удобен.