c
Ты сначала находишь адрес виртуальной таблицы для соответствующего интерфейса, далее просто по смещению там смотришь. Получается несколько шагов
ну вот вопрос, а как найти адрес таблицы интерфейса для приходящего инстанса класса?
Size: a a a
2020 July 09
f
Зачем делать это не знаю, но не строить дефолтное дерево в LL парсере нужно, чтобы потреблять меньше памяти и использовать привычные и удобные LL грамматики, которых много.
Если в ANTLR при этом выключен backtracking, то почему бы и нет. Если включен, то без parse tree, как я понимаю, придётся проходить один и тот же путь несколько раз.
c
типа у нас есть огромная таблица многие ко многим классов и интерфейсов чтобы одним лукапом найти?
AT
ну вот вопрос, а как найти адрес таблицы интерфейса для приходящего инстанса класса?
Не для инстанса, а для самого класса. Он будет одинаковый у всех инстансов. И компилятор знает, какой именно он сгенерировал.
c
Не для инстанса, а для самого класса. Он будет одинаковый у всех инстансов. И компилятор знает, какой именно он сгенерировал.
ну еще раз, приходящий класс мы не знаем, это рантайм информация же
ВМ
ну еще раз, приходящий класс мы не знаем, это рантайм информация же
знаем, для этого есть RTTI
AT
ну еще раз, приходящий класс мы не знаем, это рантайм информация же
Он нужен в месте вызова, а там знаем. В функцию параметром приходит уже указатель сразу куда надо.
c
все равно не понимаю, как в
x в месте g.print() определить смещение? классы же приходят разные interface A {void print()}
interface B {...}
interface C {...}
interface D {...}
class Foo implements B, A {...}
class Bar implements C, A {...}
function x(A g) {g.print()}
x(new Foo())
x(new Bar())ну вот же я пример привел, мы даем функции разные классы
AT
знаем, для этого есть RTTI
Не усложняйте и не запутывайте человека — он ещё самых тривиальных случаев не осознал.
AT
ну вот же я пример привел, мы даем функции разные классы
И в каждом месте вызова компилятор знает какой конкретно класс. А внутри функции пофиг — она видит сразу правильный указатель.
IK
Есть известная картинка: https://i.stack.imgur.com/rivKh.jpg
На ней видно, что существуют грамматики, которые покрыты LL(1) и, тем более, LL(k), но не LALR(1). (Впрочем, обратное тоже верно).
С другой стороны, LALR(k) покрывает и LR(k), и LL(k) — этого на картинке нет (генераторы LALR(k) лично мне неизвестны, но если я правильно помню теорию, то это так.)
На ней видно, что существуют грамматики, которые покрыты LL(1) и, тем более, LL(k), но не LALR(1). (Впрочем, обратное тоже верно).
С другой стороны, LALR(k) покрывает и LR(k), и LL(k) — этого на картинке нет (генераторы LALR(k) лично мне неизвестны, но если я правильно помню теорию, то это так.)
А вот наглядный практический пример: https://stackoverflow.com/a/8811523/1046374
MS
типа у нас есть огромная таблица многие ко многим классов и интерфейсов чтобы одним лукапом найти?
Один ко многим.
MS
Один класс ко многим интерфейсам.
AT
Один класс ко многим интерфейсам.
Та не, один интерфейс могут реализовывать много разных классов. Но это ничему не мешает.
f
А вот наглядный практический пример: https://stackoverflow.com/a/8811523/1046374
Так ведь изначальный вопрос был — что может top-down, чего не может bottom-up, а не наоборот? 😉
MS
Та не, один интерфейс могут реализовывать много разных классов. Но это ничему не мешает.
Ой, да, не то сказал.
c
И в каждом месте вызова компилятор знает какой конкретно класс. А внутри функции пофиг — она видит сразу правильный указатель.
ну хорошо, что компилятор должен сгенерить для такого кейса
x(rand() > 0.5 ? new Foo() : new Bar() )
MS
ну хорошо, что компилятор должен сгенерить для такого кейса
x(rand() > 0.5 ? new Foo() : new Bar() )
При условии что Foo и Bar удовлетворяют одному интерфейсу?
c
MS
Указатель на структуру и указатель на лукап-таблицу с реализациями функций интерфейса.