Заблокирован
|
||||||
1 | ||||||
Неочевидные грабли полиморфизма с++23.11.2011, 01:05. Показов 13181. Ответов 101
Метки нет (Все метки)
Наткнулся в интернете на любопытный код.
Спешу поделиться с сообществом. Просто, что бы кто если не в курсе - узнал, и не попал на эти грабли:
Но в любом случае, нужно быть предельно осторожным. А по сути, полиморфизм + множественное наследование = мина замедленного действия. Поэтому, при проектировании полиморфных классов, лучше до последнего избегать множественного наследования.
1
|
23.11.2011, 01:05 | |
Ответы с готовыми решениями:
101
Неочевидные особенности выдачи pg таблиц Неочевидные результаты очевидных css-свойств Грабли с кодировкой Xmega грабли |
Заблокирован
|
||||||
24.11.2011, 12:41 [ТС] | 81 | |||||
Пример наглядно иллюстрирует, что к одному и тому же объекту можно обращаться, и вызывать его методы. И при этом компилятор будит считать что этот объект - каждый раз разный.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
24.11.2011, 12:44 | 82 |
Ты используешь НЕ виртуальные функции. Т.е. вызов функции происходит по адресу, известному во время компиляции (выводится из типа указателя). Полиморфизма в этом примере нет в принципе.
0
|
Заблокирован
|
|
24.11.2011, 12:51 | 83 |
У вас происходит статическое связывание функций по типу указателя на этапе компиляции. Компилятор видит тип указателя и соответственно вставляет статически код вызова соответствующей функции.
Признаюсь, я не понял, что вы хотели продемонстрировать.
0
|
Заблокирован
|
|
24.11.2011, 12:55 [ТС] | 84 |
Данный пример наглядно демонстрирует, как один и тот же объект может быть интерпретирован и так, и этак.
А вот в примере по сабжу уже используется полиморфизм, и вот уже он наглядно демонтирует, что интерпретация объекта в качестве объекта другого типа может иметь неочевидные последствия. В примере по сабжу используется.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
||||||
24.11.2011, 13:01 | 85 | |||||
В принципе, можно и так писать
Добавлено через 1 минуту Некоторые гвозди микроскопом забивают, но ведь это не значит, что микроскопом не нужно пользоваться. А если будете гвозди микроскопом забивать, то это "может иметь неочевидные последствия".
0
|
Заблокирован
|
|
24.11.2011, 13:06 [ТС] | 86 |
Плоха та архитектура, которая вынуждает программиста все время помнить о низко-уровневой работе механизмов, и все время думать: а нет ли здесь каких нибудь невидимых граблей?
Одна из фундаментальных задач ООП - гасить сложность архитектуры проекта. А не увеличивать её. Полиморфизм + множественное наследование значительно увеличивают сложность понимания архитектуры, и вынуждают думать сразу о многом. На мой взгляд, это плохая практика. Гораздо выгоднее использовать неглубокие, и неширокие деревья наследований + композиция. Вместо потенциально опасных глубоких и запутанных иерархий
0
|
4226 / 1795 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
|
|
24.11.2011, 14:03 | 87 |
Где грабли? Решил сделать типы не совместимыми - не приводи один к другому. Плоха технология намеренного отказа от гибкости из-за якобы абстрактной опасности. Например, указатель опасен не абстрактно, а только при выдаче на чужой уровень. И необходимо его просто иметь. Использовать лучше всего только внутри классов, но при большом желании можно даже глобально. Но при работе с каким либо уровнем абстракции любая технология должна позволять ограничиваться рассмотрением только этого одного уровня. Больше того, эта возможность должна всегда и использоваться. Ну так вот, с какими бы классами ты ни работал, их отношение вида предок-потомок - именно тот уровень, с которым ты при этом работаешь. Ну так вспоминай иерархию и смотри, какой класс от кого происходит. Если классы не связаны, то нельзя приводить. И не надо кивать на динамический каст. Эта технология продвинутая, она умеет превращать даже автомобиль в лодку и назад, если уже изобретены амфибии. Нет амфибий - лодка и автомобиль не совместимы даже для этой технологии. Старая же технология приведения работает только с указателем без обращения к таблицам. И для неё лодка с автомобилем остаются несовместимыми в не зависимости от изобретения гибридного транспорта. В частности поэтому, кстати, опасны любые библиотеки классов, пока не изучишь их иерархию. Да и просто семантика методов и их параметров. Вот взять строки. С какого символа они начинаются? С первого, или с нулевого? Если класс строк не делает какой нибудь разбор сам, то тебе может понадобиться сделать его как посимвольный. Какой символ последний? Измерить длину и от неё? Если ты думаешь, что строка начинается нулевым символом, а на самом деле первым, то ты никогда не обработаешь последний символ, если в нём важная информация, то ты её никогда не учтёшь, прога просто повиснет. Даже утечка далеко не так страшна. Ну кончится память. Перезагрузи прогу и может быть ось за ней подчистит. Не помогло? Перезагрузи ось и память вся вернётся. А за висяк ты не пройдёшь никогда. И тестить бесполезно, пока не догадаешься, куда смотреть. К тому же даже если ты допустил ошибку, провоцирующую утечку, её можно найти просто внимательным чтением только своего исходника и больше ничего. Даже тест не нужен в принципе. То же самое, если важен первый символ, ты его считаешь первым, а он нулевой. Висяк слепишь и даже не увидишь. Вот попроюбуй bmp файл переименованием превратить в метафайл, а потом исполнить. А!!! Винда суперопасна!!! В ней под водой плавают грабли переименования!!! Не делай фигни - не изобретёшь грабли. Причём, они твои, а не полиморфизма. Ещё опаснее шаблон, если не понимаешь его назначения и начинаешь скармливать классы банковских счетов, или каких нибудь интерфейсов шаблону строк с отдельным полем числа символов, конкретизируемым unsigned small int для строк до 255-ти символов, unsigned short int - до 65535 и unsigned long int - до 4-х гигасимволов.
0
|
Заблокирован
|
||||||
24.11.2011, 17:54 [ТС] | 88 | |||||
Итак. Я уже почти было убедился, что приведение типов вызывает конструктор копирования.
То есть, "привести тип A к типу B" фактически означает "создать временный объект типа B, при помощи конструктора копирования этого типа B, аргументом которого будит являться объект типа А". То бишь, временный объект типа B будит создан при помощи копирующего конструктора по прототипу типа A. На самом деле, для меня это было открытием. Я то думал, что приведение типов меняет лишь интерпретацию типа объекта, и никаких расходов на копирование не произойдёт! Естественно, я обеспокоился, и начал обшаривать существующую архитектуру своего прожекта. Поскольку я пихал приведение типов везде где только можно. Я ж не знал, что это может привести к падению производительности из-за запусков копирующих конструкторов. Я решил, что если такие места есть, то можно избавиться от ненужного копирования за счёт приведение типов указателей, а не самих объектов. То есть изменить интерпретацию типа объекта, за счет приведения указателя на нужный тип, и подсовывание указателя вместо объекта. Я почти не сомневался в том, что предстоит довольно кропотливая работа по чистке всего кода, и спасению производительности (так то оно конечно не тормозит. Так что можно было и не заострятся. Но я ж не зря свой скилл прокачиваю. Надо использовать полученное знание). И я был поражон.... Объясните мне, почему так?
А он в свою очередь проталкивает этот объект своему базовому классу. Но базовый класс в качестве аргумента принимает только объекты своего класса! Таким образом в момент передачи типа Derrived методу класса Base должно произойти приведение типа! И соответственно, должен быть вызван копирующий конструктор. Почему этого не произошло? Неужели сменилась просто интерпретация типа?
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
24.11.2011, 18:00 | 89 |
Не должен. Ведь ты передаёшь по ссылке. При передаче по ссылке или по указателю приведение типа объекта не происходит, происходит приведение типа ссылки. Соответственно и срезки не будет. Именно поэтому по ссылке и передают, чтобы избежать ненужного копирования.
1
|
Заблокирован
|
|
24.11.2011, 18:05 [ТС] | 90 |
Хм... ну я у себя везде где ток можно юзал ссылки. А где не можно - юзал указатели.
Я то собрался код чистить, а он у меня оказывается такой... итак чистенький) А тут значится, что ссылка - это не просто псевдоним объекта. Это вообще как бы и не объект вовсе.. гм гм... Это именно указатель на объект. Только замаскированный так, словно "другое имя объекта".
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
24.11.2011, 19:44 | 91 |
Именно так. Фактически, это полиморфный указатель, но без указателя. Т.е. полиморфный адрес объекта, который используется непосредственно, а не посредством указателя. Как-то так.
0
|
84 / 57 / 8
Регистрация: 07.08.2010
Сообщений: 185
|
||||||
18.12.2011, 05:03 | 92 | |||||
Очевидно, это не так:
* dynamic_cast нужен для преобразования между типами, между которыми отсутствует наследственная связь. Иначе работает простой static_cast.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
18.12.2011, 07:41 | 93 |
Нет. Для преобразования от родительского к дочернему static_cast не подходит, только dynamic_cast.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
18.12.2011, 12:19 | 94 |
Deviaphan, Если нету множественного наследования и есть уверенность, что преобразование корректно - reinterpret_cast.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
18.12.2011, 12:31 | 95 |
0
|
1500 / 1146 / 165
Регистрация: 05.12.2011
Сообщений: 2,279
|
||||||
18.12.2011, 12:40 | 96 | |||||
статик каст подойдет и это скомпилится. только результат каста может быть не таким, какой ожидается. А компилится это потому, что компилятор видит наследственную связь между базой и производным классом. При множественном наследовании это возможно со своими хитростями будет работать или не работать, но в простом случае статик_каст от родителя к потомку компилится:
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
18.12.2011, 12:52 | 97 |
Честно говоря, я потрясён. Заведомо ошибочный код компилируется - это не есть хорошо.
Добавлено через 4 минуты Впрочем, это лишний повод не использовать static_cast там, где его использовать не следует.)
0
|
1500 / 1146 / 165
Регистрация: 05.12.2011
Сообщений: 2,279
|
|
18.12.2011, 13:01 | 98 |
Компилябельность объяснить можно тем, что не везде используют RTTI по разным причинам. Но в то же время хочется иметь возможность каститься с хоть какой-то диагностикой на этапе компиляции. Ну и как я уже сказал, поскольку компилятор видит связь между родителем и дочерним классом, он разрешает такой каст.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
18.12.2011, 13:07 | 99 |
Никогда так не писал, поэтому был уверен, что компилятор будет ругаться.) MFC не в счёт.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
18.12.2011, 13:20 | 100 |
Выдержки из стандарта на эту тему.
1
|
18.12.2011, 13:20 | |
18.12.2011, 13:20 | |
Помогаю со студенческими работами здесь
100
Грабли с USART_FLAG_RXNE Наступлю на те же грабли? Грабли с WM_DEVICECHANGE Грабли malloc/free Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |