MQL5 Компилятор не различает класс и указатель на него - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
неявный кастинг этого указателя к объекту
Правильнее назвать "Неявное разыменование указателя".
Поддерживаю предложение запретить, оставить неявное разыменование только при обращении к члену класса, типа:
Тут наоборот - указатель a неявно кастится к объекту (разыменовывается), и затем к нему применятся оператор=. Вчера fxsaber также упоминал об этом.
И вот в этом случае я соглашусь, что такое поведение лучше запретить. Хоть по логике оно не противоречит правилам MQL (т.к. вызов оператора= равносилен вызову любого другого метода объекта), но это приводит к неоднозначности восприятия такого кода и трудноуловимым ошибкам. И это касается не только оператора=, но также == и !=, как минимум. А возможно и для других операторов нужно запретить такой кастинг. Потому как в C++ к операторам можно применять: +-<>[].
Короче вердикт такой: при применении к указателю операторов, которые в C++ разрешены для указателей, запретить неявный кастинг этого указателя к объекту. Соответственно в вышеприведённом примере будет ошибка компиляции.
Да эт понятно. На этих простых примерах я хотел показать всем сомневающимся, что указатель и объект суть - разные сущности и мешать их никак нельзя.
А это обстоятельство предполагает как минимум определенного стиля написания кода, чтобы по ошибке(не знанию) не построить код, который откомпилируется и даже пройдет тест но в реальных условиях рухнет, тем хуже если писалось на продажу. Найти место ошибки в коде, где всё так "неявно" равнозначно будет довольно не простой задачей.
Найти место ошибки в коде, где всё так "неявно" равнозначно будет довольно не простой задачей.
Лучше бы разработчики оставили все как есть. Если сейчас менять начнут опять, язык, куча программ перестанет компилироваться, или что ещё хуже - перестанет работать как ожидалось, то тут поднимется вселенский шухер.
С моей точки зрения автообъекты в мкл это рудимент, недо-указатели с ограниченными функциями (константный указатель с автоудалением), и их использовать по большому счету не нужно вообще (разве что под garbage collector).
Лучше бы разработчики оставили все как есть. Если сейчас менять начнут опять, язык, куча программ перестанет компилироваться, или что ещё хуже - перестанет работать как ожидалось, то тут поднимется вселенский шухер.
Тут изменений то минимум. Просто добавить правила компиляции к
Чтоб он не позволял компилировать ту ересь которая сейчас считается годной.
Чтоб он не позволял компилировать ту ересь которая сейчас считается годной.
типа A a = new A? Или что конкретно ) strict сейчас используется всеми, так что это вообще не имеет эффекта
вот при обратной записи типа A a, *b = a; получается runtime error, в этом случае явно компилятор должен выдавать предупреждение "probable use of uninitialized variable 'b'" как он это делает со всеми другими типами. Если не ошибку компиляции вообще. Но не из-за присваивания как такового, а из-за использования перегруженной функции на неинициализированной переменной, что приводит к ошибке выполнения, разумеется. Это действительно баг и связан похоже он с чрезмерной оптимизацией кода
А вообще в присваивании авто к дино и обратно нет никакой ереси, это могут быть полезные фишки.
А вот такую фишку как неявное копирование у объектов я бы отменил вообще. Хоть оно и является стандартом в С++. Из-за него собственно все эти проблемы и возникают.типа A a = new A? Или что конкретно )
Ну это само собой. Тут сразу утечка памяти.
А вообще в присваивании авто к дино и обратно нет никакой ереси, это могут быть полезные фишки.
Да пусть будет. Но явное. И это будет сделано не по моей ошибке а потому что мне так надо.
Ну это само собой. Тут сразу утечка памяти.
Ну так эта утечка чисто по твоей вине. Если слева у тебя объект, то зачем писать такую конструкцию?
А вот обратная ситуация, когда ты указателю что-то присваиваешь, а он вдруг разыменовывается, это уже неочевидная ошибка.
Тут намешали всё в кучу, и мух и котлет. Это я про обсуждение темы.
Если слева у тебя объект, то зачем писать такую конструкцию?
Человеческий фактор! Компилятор должен свести его к минимуму.
Человеческий фактор! Компилятор должен свести его к минимуму.