Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В учебнике говорится о невозможности копирования содержимого структур из разных веток наследования.
Для начинающих пользователей - поясню в чем принципиальность ошибки: функция f() скрытно изменила будущую целостность объекта помимо воли его владельца. Проще говоря: на вход объект пришел как const, а на выходе получили как не const
В (2) случае компилятор стоит на страже, и при попытке вызвать g2() выдает ошибку
Во (4) случае появилась неграмотная функция f(), против которой компилятор бессилен и вынужден вызвать g2()
Семантика моего примера подразумевает неизменность параметра внутри функции и класса. Модификатор const подчеркивает этот контракт (дает напоминание для программиста и защиту через компилятор на случай, если метод позднее разрастется и кто-то решит сделать внутри присваивание). Тут нет никаких обязательств по поводу использования переданного объекта вовне.
Любую конструкцию языка можно использовать во благо или во вред, особенно если целенаправленно.
Был приведён рабочий пример копирования структур из разных веток, который, по информации из учебника - не работает.
В тексте учебника говорится иное. Вы какую-то отдельную фразу читаете, а не абзац целиком.
В результате операции присваивания m3 = in, поля X и Y (общая часть для обоих типов) скопируются из переменной in базового типа в поля X и Y в переменной m3 производного типа. Поле code переменной m3 останется без изменений.
Однако подобное копирование не работает между двумя "детьми", двумя "внуками" и прочими вариантами сочетания типов из разных ответвлений.
Любую конструкцию языка можно использовать во благо или во вред, особенно если целенаправленно
Я соглашусь с A100, нельзя в учебнике приводить настолько небрежные примеры кода.
Как по-вашему изменить конкретно этот метод с учетом его специфики, а не вырванным из контекста?
Семантика моего примера подразумевается неизменность параметра внутри функции и класса. Модификатор const подчеркивает этот контракт (дает напоминание для программиста и защиту через компилятор на случай, если метод позднее разрастется и кто-то решит сделать внутри присваивание). Тут нет никаких обязательств по поводу использования переданного объекта вовне.
Любую конструкцию языка можно использовать во благо или во вред, особенно если целенаправленно.
Серьезный автор признал бы ошибку и моментально бы ее исправил (там всего то одну строку изменить нужно), а несерьезный будет оправдываться, приводя несуразные аргументы
Если Вы не в состоянии это сделать, то сделаю это за Вас:
Теперь компилятор стоит на страже в обоих случаях и выдает ошибку
А если, по каким то причинам на входе должен быть обязательно const, то и на выходе пишем const - это азы!
А если, по каким то причинам на входе должен быть обязательно const, то и на выходе пишем const
Наиболее простой и понятный уход от разыменования указателя. Все остальные примеры - излишнее усложнение.
ООП высшего класса типа? С учетом совместимости с плюсами? Учебник большой труд, если уж есть ошибки, то лучше выявлять их на свет с учетом этого труда. Не уместно, да тут говно, и код говно... .... Ошибки на уровне разных пониманий разрабов языков, это к разрабам, а не к учебнику.
Всех уважаю, с наступающим.))))
А если, по каким то причинам на входе должен быть обязательно const, то и на выходе пишем const - это азы!
Конечно)))