Неочевидные грабли полиморфизма с++

Наткнулся в интернете на любопытный код.
Спешу поделиться с сообществом.
Просто, что бы кто если не в курсе - узнал, и не попал на эти грабли:


От себя могу добавить, что разные компиляторы по разному могут реализовывать механизм полиморфизма. Поэтому, при множественном наследовании если что и спасет - только dynamic_cast
Но в любом случае, нужно быть предельно осторожным.

А по сути, полиморфизм + множественное наследование = мина замедленного действия.

Поэтому, при проектировании полиморфных классов, лучше до последнего избегать множественного наследования.

1

Сообщение от Bers Вот вы и объясните почему?

Спустимся немного вглубь.
Все указатели на уровне реализации - абсолютно одинаковы. Поэтому явное преобразование типа указателя - это просто для порядку на уровне С++. На самом деле никаких преобразований не производится. Как и было в С.
А вот при наличии в классе виртуальных функциях нужно знать тип ВО ВРЕМЯ ВЫПОЛНЕНИЯ. Чтобы вызвать нужную функцию. Это довольно сложная операция. Это и есть механизм RTTI.

0

Сообщение от Bers Вот вы и объясните почему?

Позволь я объясню. Но это объяснение подходит только для компилятора MSVC, т.к. реализация виртуальных функций никак не регламентирована и реализуется разработчиками по своему усмотрению.
Итак MSVC:
В начале каждого объекта, содержащего виртуальные функции, записывается адрес используемой им таблицы виртуальных функций. Адрес объекта совпадает с указателем на эту таблицу. Виртуальные функции добавляются в эту таблицу в том же порядке, в котором они объявлены в классе. Вызов происходит не напрямую по адресу, а через индекс этой функции. Т.е. вместо непосредственного использования адреса функции, происходит индексированный доступ к таблице и вызов функции по соответствующему адресу.
При множественном наследовании всё усложняется. Для первого базового класса указатель по прежнему записан в самом начале, затем идут данные-члены этого класса и только потом указатель на таблицу второго базового класса. Когда ты выполняешь приведение типа с помощью dynamic_cast, адрес объекта изменяется, т.к. он переносится на "начало" объекта второго базового класса. Ты можешь это легко проверить, выводя адрес объекта после кастования.
Используя reinterpret_cast (круглые скобки это он и есть в данном случае), ты интерпретируешь указатель на один объект, как указатель на другой. Программа бы могла упасть, но прототипы функций одинаковые, поэтому порчи стека не происходит. Данные объекта тоже не используются. Но происходит индексированый доступ функции. Что ты и видишь в консоли.
Можешь добавить в классы поля и попробывать их выводить в консоль (но не изменять) и зразу увидишь, что там не то, что ты ожидаешь.

И это не грабли полиморфизма, это некорректная программа. Не зря ведь говорят ЗАБУДЬТЕ ПРО ПРИВЕДЕНИЕ ТИПОВ В СТИЛЕ Си.

4

Сообщение от Bers Меня не интересует, есть там перекрестки, или нет. Меня интересует, почему динамик_каст корректно приводит, а приведение в стиле си - не корректно. И что происходит с объектом, в момент приведения его типа к одному из базовых (срезка). По русски, с толком, с расстановкой. Не? Я вам намекну, динамик_каст - дорогое приведение, потому что юзает технологию определения типа объекта в рантайме.

Дык в С - не было классов! И тем более - не было виртуальных функций. И наследования.
Потому и не приводит. Обратная же совместимость!

0

Спустимся:

Корректно.

Вы по прежнему щитаете, что между ними нет связи?

0

Сообщение от Bers И что происходит с объектом, в момент приведения его типа к одному из базовых (срезка).

Именно срезка. Но только при приведении типа объекта. При приведении указателя на объект к указателю на базовый тип никакой срезки не происходит. И при ссылке срезки тоже не происходит.

1

В общем-то насколько мне известно, множественный полиморфизм может быть реализован с использованием нескольких таблиц виртуальных методов (в данном случае двух). Собственно, как выше и говорилось, для этого и нужен dynamic_cast. Если использовать преобразование в стиле Си, то указатель vtable получается фактически случайным из двух.

0

Сообщение от Bers Спустимся: C++ 1 2 aPtr->Func1(); //вывод: A::Func1  bPtr->Func2(); //вывод: B::Func2 Корректно. Вы по прежнему щитаете, что между ними нет связи?

А и В вообще разными программистами в разных файлах могли быть написаны. И транслируются в разное время. Один вчера, а другой - сегодня. ГДЕ тут связь?
Откуда компилятор мог знать, что Берс возьмет эти два класса и множественно унаследует.
А потом явные имена при вызове будет писать и требовать "продолжения банкета" с виртуальными функциями.

0

Сообщение от Bers Вы по прежнему щитаете, что между ними нет связи?

Между А и В связи нет.
Но!
Если А* и В* на самом деле указывают на объект типа С, то связь есть. Но только в случае использования dynamic_cast. При желании, можно вручную рассчитать необходимое смещение, сдвинуть указатель и поменять его тип. Но такому желанию лучше не возникать.)

0

ну так вот, возвращаясь к моему тезису:
1. Избегайте множественного наследования + полиморфизм.
2. Избегайте динамического кастования, если дорога производительность.

В противном случае не удивляйтесь ничайному выстрелу себе в ногу.

0

Сообщение от Bers ну так вот, возвращаясь к моему тезису: 1. Избегайте множественного наследования + полиморфизм. 2. Избегайте динамического кастования, если дорога производительность. В противном случае не удивляйтесь ничайному выстрелу себе в ногу.

1 - Нет!
2 - Это миф.
3 - Учитесь программировать и не придётся искать достаточно длинную верёвку, чтобы выстрелить себе в ногу.

2

сказал Deviaphan, ничерта не пролив свет на происходящее

0

Сообщение от Bers ничерта не пролив свет на происходящее

На странице ТРИ я в подробности описал, как работает полиморфизм в С++. Если не желаешь читать, это не мои траблы.

Добавлено через 32 секунды
От тута Неочевидные грабли полиморфизма с++

0

Deviaphan, На счет динамик каста я бы поспорил. Много динамик кастов убивают производительность. В одной проге профайлер показывает, что динамик каст занимает 14% общего времени, правда используется он там действительно немало где

0

Сообщение от ForEveR В одной проге профайлер показывает, что динамик каст занимает 14% общего времени

Скорее всего ошибка в проектировании. В 80% случаев, повышающий каст означает ошибку проектирования. В 20% программисту удаётся доказать, что это не ошибка.)

И маленький примерчик, для "закрепления материала"
Добавлено через 1 минуту
Можно закомментировать слова virtual, чтобы совсем уж точно материал усвоить.)

2

Сообщение от Bers #include <iostream> using namespace std; struct A { * * virtual void Func1(){cout<<"A::Func1"<<endl;} }; struct B { * * virtual void Func2(){cout<<"B::Func2"<<endl;}} ; struct C: public A, public B { * * virtual void Func3(){cout<<"C::Func3"<<endl;} }; int main() { * * A *ptr = new C; * * void *ptr1 = new C; ((A*)ptr)->Func1(); //вывод: A::Func1 * * ((B*)ptr)->Func2(); //вывод: A::Func1 Почему? * * ((C*)ptr)->Func3(); //вывод: C::Func3 A* aPtr=dynamic_cast<A*>(ptr); * * B* bPtr=dynamic_cast<B*>(ptr); * * C* cPtr=dynamic_cast<C*>(ptr) //нельзя кастовать от void* * * //void* ничего не знает ни о каких классах * * //и ни о каких таблицах виртуальных функций C* cPtr=dynamic_cast<C*>(ptr1); //ошибка компиляции * * //error C2681: void *: недопустимый тип выражения для dynamic_cast aPtr->Func1(); //вывод: A::Func1 * * bPtr->Func2(); //вывод: B::Func2 * * cPtr->Func3(); //вывод: C::Func3 delete ptr; * * delete ptr1; return 0; }

Не вижу граблей, а вот если бы компилятор проглотил void*, то это и были бы грабли.

0

0

Сообщение от Сыроежка вывод: A::Func1 Почему?

Потому что это не потомок A. Ты тупо переназначил тип самому адресу, то есть сказал машине, что адрес теперь просто целое и сразу: "Нет, я передумал, это адрес B", и вызвал функцию по определённому смещению в таблице виртуальных функций, но таблица то по этому указателю соответствует классу A и по такому смещению там валяется указатель на функцию A::Func1(). Автор твоих "не очевидных граблей" просто считает всех вокруг идиотами, не способными понять смысл своих действий.

0

1

Сообщение от Bers Ни о чем таком не говорит?

Это говорит о наследовании как таковом, а множественное - это когда и указатели на два разных базовых класса могут указывать на одного и того же потомка, но не друг на друга, то есть когда одновременно:
. У тебя и это есть, а полиморфизм - это вообще возможность перекрывать методы предка, что также имеется в приведённом исходнике.

Добавлено через 7 минут

Сообщение от Bers И потом, класс C здесь - это самый дальний потомок.

О какой дальности может идти речь при одном уровне наследования? C - это ближайший потомок из всех возможных, а здесь - единственный.

Добавлено через 1 минуту

Сообщение от Сыроежка dynamic_cast используется для приведения указателя на базовый класс к указателю на производный класс. При противоположном преобразовании можно использовать обычное присваивание, так как происходит неявное преобразование.

Вывод говорит об обратном.

Добавлено через 1 минуту

Сообщение от taras atavin классу A

Точнее классу C, но начало таблицы класса C совпадает с таблицей класса A.

Добавлено через 9 минут

Сообщение от Bers Указатель может быть типа int. Указателей на int не бывает

наоборот. x типа int, но x не указатель, p указатель, но p не типа int. Как раз p и есть указатель на int. "Указатель на тип", "указатель на класс" означает, что:
1. Это указатель.
2. Ему разрешено указывать только на данные определённого типа, или только на на данные определённого класса - того типа/класса, который поминается в словосочетании.
Чтоб не сбивать тебя с толку следовало бы говорить "указатель на данное типа", "указатель на объект класса", но ни кто так длинно не говорит, все сокращают и все понимают, что на саму абстракцию указатель не указывает.

Добавлено через 3 минуты

Сообщение от Bers объект типа int

Не бывает объектов типа int. int не класс, а скалярный тип, переменные этого типа - не объекты.

Добавлено через 3 минуты

Сообщение от Bers Потому что между типом самого указателя, и типом объекта, куда он смотрит жёсткой связи не существует.

И куда ж она делась то? У всех она есть, только в твоей голове как то проделитилась. Может потому у тебя и падает всё, что с указателями, что ты не отличаешь int* от void*?

Добавлено через 2 минуты

Сообщение от Сыроежка класс - это тип

Согласен. Класс - это тип, в котором разрешены любые члены, как члены-данные (поля), так и члены-функции (методы), а на некоторых языках (в том числе c++) даже члены-операторы. Но всё таки тип, а не константа.

Добавлено через 6 минут

Сообщение от Bers А вот указатель на объект, или функцию, или функцию-член - звучит однозначно.

Как раз неопределённо. Указатель на объект. На какой, простите, объект? На дом? На корабль? На кирпич? А может на домну? Или на пользователя? Прямо так, на настоящего пользователя в реале? А может на машинное представление данных об объекте? Эйси, всегда это подразумевается. Но о каком объекте? О Солнечной Системе? Или о пылинке? А может о стене? Пока не указан тип, не понятно о каком указателе речь, поэтому "указатель на объект" семантически идентично "указатель", прямо так, одним словом. Слово "объект" просто лишнее, оно не несёт ни какой смысловой нагрузки, так как его абстракция запредельна и не лезет ни в какие рамки, кроме как в тексте на метаязыке о самом понятии "объект" и прибамбасах для поддержки объектной ориентированности. И только когда указан класс, объект принимает хоть какие то разумные очертания, но не раньше.

0

Сообщение от taras atavin поэтому "указатель на объект" семантически идентично "указатель"

Противоречишь сам себе. Т.к.

Сообщение от taras atavin Не бывает объектов типа int. int не класс, а скалярный тип, переменные этого типа - не объекты.

Соответственно есть "два типа указателей" На объекты и на скаляры. А ещё есть указатели на массивы (они же на строки). Поэтому уточнение на что конкретно указывает указатель может быть не лишним.
Надо же было твой пост разбить на два.

1