MS
…вмонтированный или в структуру, или в указатель на неё.
Size: a a a
2020 July 09
IK
Если в ANTLR при этом выключен backtracking, то почему бы и нет. Если включен, то без parse tree, как я понимаю, придётся проходить один и тот же путь несколько раз.
Это вряд ли - бектрекинг не учитывает построенное дерево, а вызывает функцию генерации после окончательного парсинга.
f
Это вряд ли - бектрекинг не учитывает построенное дерево, а вызывает функцию генерации после окончательного парсинга.
Жаль, я надеялся, что ANTLR умеет мемоизировать, как packrat.
AT
ну хорошо, что компилятор должен сгенерить для такого кейса
x(rand() > 0.5 ? new Foo() : new Bar() )
A *ptr;
if (rand() > 0.5) {
Foo *tmp = new Foo();
ptr = (A *)( (char *)tmp + A_offset_in_Foo );
} else {
Bar *tmp = new Bar();
ptr = (A *)( (char *)tmp + A_offset_in_Bar );
}
x(ptr);
Примерно такой.
IK
Так он умеет мемоизировать, речь шла о конечном дереве разбора.
IK
Так ведь изначальный вопрос был — что может top-down, чего не может bottom-up, а не наоборот? 😉
Походу если сравнивать в общем LL(*) и LR, то они заменяемы. А вот с частными случаями все сложнее: https://cs.stackexchange.com/a/48/47361
f
Так он умеет мемоизировать, речь шла о конечном дереве разбора.
Выше я специально упомянул "промежуточное parse tree", а не конечное.
f
Походу если сравнивать в общем LL(*) и LR, то они заменяемы. А вот с частными случаями все сложнее: https://cs.stackexchange.com/a/48/47361
LL(k)-грамматики являются подмножеством LR(k)-грамматик, но не наоборот.
c
A *ptr;
if (rand() > 0.5) {
Foo *tmp = new Foo();
ptr = (A *)( (char *)tmp + A_offset_in_Foo );
} else {
Bar *tmp = new Bar();
ptr = (A *)( (char *)tmp + A_offset_in_Bar );
}
x(ptr);
Примерно такой.
ок с этим понятно, спасибо
а что если функция принимает 2 обязательных интерфейса как в расте
а что если функция принимает 2 обязательных интерфейса как в расте
x(A + B g)f
@KvanTTT Наверное, когда выясняют, кто является подмножеством кого, имеют в виду левую рекурсию.
IK
LL(k)-грамматики являются подмножеством LR(k)-грамматик, но не наоборот.
LL(k) и LL(*) - это разные вещи. Первые являются подмножеством, вторые - нет.
AT
ок с этим понятно, спасибо
а что если функция принимает 2 обязательных интерфейса как в расте
а что если функция принимает 2 обязательных интерфейса как в расте
x(A + B g)А в Rust и Haskell виртуальные таблицы передаются отдельными аргументами и мы, соответственно, можем передать их сколько хотим.
IK
Написано: LL(∗)×LR (left recursion versus arbitrary lookahead)
c
А в Rust и Haskell виртуальные таблицы передаются отдельными аргументами и мы, соответственно, можем передать их сколько хотим.
т е примерно так да
x(A g1, B g2)
f
Написано: LL(∗)×LR (left recursion versus arbitrary lookahead)
Хорошо, LL(∞) не являются подмножеством LR(k), т.к. LR(∞) практически неосуществима 😊
AT
т е примерно так да
x(A g1, B g2)
Примерно
x(A tblA, B tblB, SomeStruct g).f
@val_krylov ^ кажется, мы нашли случай, где LL круче, чем LR 😉
c
@GabrielFallen а в чем тогда проблема что работать с полями в интерфейсах если в функцию нам приходит конкретное смещение для этого интерфейса? нам ведь ничего не мешает прочитать и записать в конкретное поле что нибудь
AT
@GabrielFallen а в чем тогда проблема что работать с полями в интерфейсах если в функцию нам приходит конкретное смещение для этого интерфейса? нам ведь ничего не мешает прочитать и записать в конкретное поле что нибудь
То, что поле одно на весь объект, а интерфейсов может быть много. Добро пожаловать в dimond inheritance problem — можете на Википедии почитать про эту шизофрению.
AT
Ещё раз повторю, что поля понимаются как реальные поля объекта, а не "проперти" или ещё какая-нибудь скрытая форма функций.