Здравствуйте, гость ( Вход | Регистрация )
lanz | Дата 15.7.2015, 11:08 |
Цитата Проверил в Qt Creator в отладке, адрес один и тот же. Вот этот показывает разные адреса: Раскрывающийся текст
Цитата И при присваивании aa к b1 или b2, в зависимости от типа присваивается vptr. Вообще это связанно не столько с vptr сколько с наследованием. Внутри объекта A содержится и B1 и B2. Естественно, что они не могут оба начинатся по адресу aa+0. Когда мы преобразуем указатель к B1( или B2) то мы получаем адрес объекта внутри A. Он может быть как со смещением относительно aa так и без. Но в любом случае эти адреса будут разными(при такой реализации наследования). |
|
Iron Bug | Дата 15.7.2015, 9:37 |
да, но (*A)b1 == (*A)b2 == aa. потому что в случае с классами для компилятора это не просто работа с указателями, а уже приведение типов и работа с виртуальными таблицами. |
|
ViGOur | Дата 15.7.2015, 9:34 |
Хм, может я чего не понимаю, но адрес будет один и тот же, но вот различаться будет только vptr. И при присваивании aa к b1 или b2, в зависимости от типа присваивается vptr. Проверил в Qt Creator в отладке, адрес один и тот же. Если я не прав, ткните меня в чем, чтобы закрыть пробел. |
|
lanz | Дата 14.7.2015, 18:28 |
Цитата Может ты имел ввиду: b1 == b2 == aa, но вот b1->vptr != b2->vptr != aa->vptr ??? Нет, именно b1 != b2 ->vptr у каждого свой, это да, но b1 != b2 Для того чтобы компилировались одинаково b->f1() и a->f1(), где B1 *b = new B1; B1 *a = new A; Поскольку компилятор в момент вызова не знает, какой объект соответсвует a и b А в момент присваивания знает, это его шанс |
|
ViGOur | Дата 14.7.2015, 17:40 |
Может ты имел ввиду: b1 == b2 == aa, но вот b1->vptr != b2->vptr != aa->vptr ??? |
|
lanz | Дата 12.7.2015, 23:37 |
Не ругайтесь Только два соображения еще: 1. В самих экземплярах классов vtable не хранится, хранится только указатель. 2. При множественном наследовании может быть несколько указателей внутри класса, при этом компилятор нигде не хранит смещение, а просто генерирует код с соответствующим смещением. Об этом кстати написано в той же статье https://ru.wikipedia.org/wiki/Таблица_вирту....BD.D0.B8.D0.B5 Интересным следствием является то что в следующем коде
b1 != b2 |
|
Iron Bug | Дата 10.7.2015, 22:00 |
Хмм. Имей в виду, что это поведение некоторых конкретных компиляторов, и полагаться, что так оно будет "всегда и везде" - крайне опасно. ... Так что, вишь как, могут быть варианты....... я думаю, что мой опыт более 20 лет профессионального программирования на С/C++ под разными системами и на разных архитектурах достаточен, чтобы понимать суть вопроса. я работала с десятками разных компиляторов, и с такими, у которых NULL был определён по-другому, и с такими, у которых char был 8 байт, и с многими другими. так что я представляю себе разнообразие возможностей, как никто другой. тут вряд ли меня можно удивить. я не предлагаю ни на что полагаться. тем более, что мне приходится писать софт под совершенно разные процессоры и я-то точно полагаться ни на что не могу даже в рамках одного проекта. только за последние полгода я работала с пятью совершенно разными архитектурами. но компиляторов С++ не так уж много, надо сказать. и реализаций классов тоже. я думаю, что с вероятностью 99.99%, виртуальная таблица окажется в начале, до полей членов класса. просто потому, что чисто логически её там удобнее располагать. иначе пришлось бы как-то извращаться и высчитывать, где она лежит. и хранить это смещение, опять же, в начале блока с классом это ничего на значит. просто логическое соображение. |
|
TheGuest | Дата 10.7.2015, 13:48 |
Теперь понятно все, спасибо вам всем за разъяснения!!! | |
Влад | Дата 10.7.2015, 13:24 |
Хмм. Имей в виду, что это поведение некоторых конкретных компиляторов, и полагаться, что так оно будет "всегда и везде" - крайне опасно. Приведу пример из собственного опыта: "Считается", что физическое представление NULL-указателя - это 0x00000000. И все известные мне компиляторы для x86 так и поступают. Даже в хидерах оно прописано. Но вот энное время назад мне довелось поработать с архитектурой (Гарвард, ага), в которой адрес 0x00000000 был вполне себе валидным, и по этому адресу могли располагаться реальные объекты. Ага, а NULL-указатель в оной архитектуре имел физическое значение 0xFFFFFFFF...... (Си-компилер автомагически преобразовывал литеральный ноль в это самое значение. Что полностью соответствует требованию Библии.) Так что, вишь как, могут быть варианты....... |
|
Iron Bug | Дата 10.7.2015, 12:30 |
Более точно будет сказать, что компилятор может разместить ТВМ в начале блока. А может - разместить где-то еще, т.к. Стандартом этот layout не специфицирован. именно это я и имела в виду. но по факту все известные мне С++ компиляторы размещают таблицу в начале блока. |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 24.4.2024, 14:29 |