c
ну это в момент имплементации класса можно ругнуть что у нас конфликт имен полей
Size: a a a
2020 July 09
AT
ну это в момент имплементации класса можно ругнуть что у нас конфликт имен полей
Таблица виртуальных функций — одна для всех объектов данного класса. Так что если мы туда засунем поле — это будет (статическое) поле класса, а не объекта. Но статические поля класса — это и так просто глобальные переменные, так что для них таблица не нужна.
c
это понятно, но ведь ничто не мешает положить в эту таблицу и смещение полей
c
ведь все поля в разных инстансах одного класса имеют одно смещение же?
AT
ведь все поля в разных инстансах одного класса имеют одно смещение же?
Да, но смещение относительно чего? Смещение фиксировано и известно относительно "начала объекта", но таблица методов может быть смещена на разное смещение от начала для разных объектов, так что относительно неё все смещения вне таблицы могут быть какими попало.
ВМ
поля при наследовании складываются последовательно от разных родительских классов
ВМ
у тебя же может быть много интерфейсов с полями
AT
Кроме того, получится как минимум double indirection, что gets old pretty quickly. В смысле, сильно портит кеши и предсказание переходов.
AT
Но в Swift, кажется, делают что-то такое в ограниченных масштабах — можно глянуть что именно и как.
c
ну я имел ввиду такое
obj = [/*поля интерфейса А*/a, b, c, /*поля интерфейса B*/, c, d, e]
obj[Ashift + 2] = 1
obj[Bshift + 1] = 2
AT
ну я имел ввиду такое
obj = [/*поля интерфейса А*/a, b, c, /*поля интерфейса B*/, c, d, e]
obj[Ashift + 2] = 1
obj[Bshift + 1] = 2
Тут два режима. Либо мы знаем конкретный фактический класс объекта, и тогда нам плевать на таблицы, мы и так знаем где что лежит. Либо всё что мы знаем — это указатель на таблицу, и тогда мы понятия не имеем в каком месте какого фактического объекта она торчит, и, соответственно, что вокруг неё и по каким смещениям.
AZ
Тут два режима. Либо мы знаем конкретный фактический класс объекта, и тогда нам плевать на таблицы, мы и так знаем где что лежит. Либо всё что мы знаем — это указатель на таблицу, и тогда мы понятия не имеем в каком месте какого фактического объекта она торчит, и, соответственно, что вокруг неё и по каким смещениям.
Теоретически можно передавать таблицу интерфейса и начало объекта. А в таблице хранить смещения относительно начала объекта
AZ
Да, будут дублирования для каждого интерфейса если они пересекаются
AZ
Но можно
c
Тут два режима. Либо мы знаем конкретный фактический класс объекта, и тогда нам плевать на таблицы, мы и так знаем где что лежит. Либо всё что мы знаем — это указатель на таблицу, и тогда мы понятия не имеем в каком месте какого фактического объекта она торчит, и, соответственно, что вокруг неё и по каким смещениям.
вроде же все тоже самое что ты мне показывал?
function x(A g) {return g.a}
x(rand() ? new Foo() : new Bar)
function x(ptr) {return ptr + a_shift_in_A}
x(rand() ? fooPtr + A_shift_in_Foo : barPtr + A_shift_in_Bar)AT
вроде же все тоже самое что ты мне показывал?
function x(A g) {return g.a}
x(rand() ? new Foo() : new Bar)
function x(ptr) {return ptr + a_shift_in_A}
x(rand() ? fooPtr + A_shift_in_Foo : barPtr + A_shift_in_Bar)Теперь
Что куда нужно записать чтобы добраться до
Foo layout:
X_vtable
A_vtable
B_vtable
field_foo : i32
Bar layout:
A_vtable
C_vtable
Y_vtable
fielf_foo : i32
Что куда нужно записать чтобы добраться до
field_foo в каждом из объектов? И это ещё не самы сложный layout.c
field_foo он к какому интерфейсу относится?AT
field_foo он к какому интерфейсу относится?Мы же уже пришли к заключению, что он не может физически принадлежать интерфейсу, а должен быть расположен в самом объекте (вне виртуальных таблиц). Что должно быть в интерфейсе (виртуальной таблице) A, чтобы получать доступ к нужному полю вне зависимости от фактического класса объекта?
c
интерфейс просто содержит список имен своих полей с типами и смещениями относительно 0
c
компилятор когда видит поле
A obj = new Bar() // barPtr +
a из интерфейса A то он подставляет это число A obj = new Bar() // barPtr +
A_shift_in_Bar
obj.a // objPtr + a_shift_in_A