Название: QPoint Отправлено: lenny от Сентябрь 20, 2011, 10:22 В исходниках Qt вот такая байда:
Код: class Q_CORE_EXPORT QPoint Название: Re: QPoint Отправлено: Igors от Сентябрь 20, 2011, 11:04 Точно не POD, зачем различное расположение данных? Почему не POD если виртуалов не наблюдается?Различное расположение - видимо дань традиции (анахронизм). Вероятно когда-то xp, yp были short (qint16) - напр для совместимости со старым типом Point на Mac. См. также оператор << для QPoint Название: Re: QPoint Отправлено: lenny от Сентябрь 20, 2011, 11:36 Класс не попадает под определение "тривиальный", т.к. присутствует пользовательский конструктор. На это и правда можно забить, но странно.
Название: Re: QPoint Отправлено: Пантер от Сентябрь 20, 2011, 11:41 Цитировать The term POD class types collectively refers to aggregate classes (POD-struct types) and aggregate unions (POD-union types) that have none of the following as members [§9, ¶4]: non-static data (including arrays) of any pointer-to-member type, non-static data (including arrays) of any non-POD class type, non-static data of any reference type, user-defined copy assignment operator, nor user-defined destructor. The term aggregate refers to an array or class that has none of the following characteristics [§8.5.1, ¶1]: user-declared constructors, private or protected non-static data members, base classes, nor virtual functions. Название: Re: QPoint Отправлено: Igors от Сентябрь 20, 2011, 12:39 Цитировать The term POD class types collectively refers to .. Код кто это такой? :) Объяснять "не-полиморфный, но и не POD, а вот, мол, агрегат.." не очень удобно Название: Re: QPoint Отправлено: lenny от Сентябрь 20, 2011, 13:00 Цитировать The term aggregate refers to an array or class that has none of the following characteristics [§8.5.1, ¶1]: user-declared constructors, private or protected non-static data members, base classes, nor virtual functions. Название: Re: QPoint Отправлено: lenny от Сентябрь 20, 2011, 13:03 Чет я засомневался об определении POD из учебников, в реальности тока добавление указателя на vtable ломает представление объекта в памяти.
Название: Re: QPoint Отправлено: lenny от Сентябрь 20, 2011, 13:46 Полистав получше, пока понял, что ничего не мешает делать предположения о расположение в памяти non-POD объектов. Видать я заблуждался. Порядок декларирования в данном случае может иметь значение.
Название: Re: QPoint Отправлено: Igors от Сентябрь 21, 2011, 10:34 Можно проще, напр POD = все что сожрет "С" компилятор. А реальная/практическая разница подлежит ли RTTI или нет (можно ли создать экземпляр(ы) простым malloc).
в реальности тока добавление указателя на vtable ломает представление объекта в памяти. Кстати там 2 указателя (RTTI еще должен знать сам созданный объект)Название: Re: QPoint Отправлено: lenny от Сентябрь 21, 2011, 14:51 Можно проще, напр POD = все что сожрет "С" компилятор. А реальная/практическая разница подлежит ли RTTI или нет (можно ли создать экземпляр(ы) простым malloc). С POD я уже не парюсь. Просто всегда думал, что в случае non-POD нельзя делать предположения о строении объекта в памяти, с чего я это взял, не пойму. В стандарте даже не нашел точного определения POD, разбросано по всему документу. Про то, что пользовательский конструктор сразу относит тип к non-POD, тоже не нашел, вроде это должно быть.в реальности тока добавление указателя на vtable ломает представление объекта в памяти. Кстати там 2 указателя (RTTI еще должен знать сам созданный объект)А что за второй указатель? В случае множественного наследования? Название: Re: QPoint Отправлено: lenny от Сентябрь 21, 2011, 15:16 Так вроде с помощью malloc можно все создать, причем происходит выделение памяти и для указателей на vtable. Главное, вызвать конструктор!
Код: class A Название: Re: QPoint Отправлено: Igors от Сентябрь 21, 2011, 15:36 А что за второй указатель? В случае множественного наследования? Ну в прынцыпе делать предположения о формате RTTI мы не можем, но здравый смысл говорит - один указатель - сам "созданный" объект (вот он может отличаться от this в случае множественного наследования), второй так называемый VMT - имея эти 2 указателя можно разобраться с dynamic_cast.В sizeof это все входит, напр Код Ну понятно если T имеет члены-указатели они могут оказаться невалидны. Виртуалы для созданной "копии" позовутся корректно, а вот на dynamic_cast загнется. Так вроде с помощью malloc можно все создать, причем происходит выделение памяти и для указателей на vtable. Главное, вызвать конструктор! Так ведь можно это все записать в 1 операторе new :) - он заполняет RTTI (а не конструктор) Название: Re: QPoint Отправлено: lenny от Сентябрь 21, 2011, 16:52 Код Ну понятно если T имеет члены-указатели они могут оказаться невалидны. Виртуалы для созданной "копии" позовутся корректно, а вот на dynamic_cast загнется. Код Честно говоря, не знаю как RTTI устроен. Название: Re: QPoint Отправлено: Igors от Сентябрь 21, 2011, 20:20 Проверим
Код
Код: (a) obj = 0x1306340, sizeof = 8, VMT: [0] = 0x4028, [1] = 0x1, Мда, насвистел я про 2 указателя, он там 1 :) А разбирается он за счет уникальности ("просто B" и "B член С" имеют разные VMT) Название: Re: QPoint Отправлено: lenny от Сентябрь 22, 2011, 16:42 Мда, насвистел я про 2 указателя, он там 1 :) |