Size: a a a

2021 August 18

f

for(int c; (c = getc... in ru.nim.talks
Приходится чаще выписывать vtable вручную через case, но зато компилятор может сказать точно где я не обработал что-то
источник

VB

Vladimir Berezenko in ru.nim.talks
Понятно. Унылый вариант ООП :)
источник

f

for(int c; (c = getc... in ru.nim.talks
ну в целом да, хотя как обычно "есть нюансы"
источник

f

for(int c; (c = getc... in ru.nim.talks
По большей части это связано с тем что есть еще set[enum], array[enum, T] через которые можно прикрутить очень интересную логику если нужно
источник

VB

Vladimir Berezenko in ru.nim.talks
Я тут поигрался с case типами в Nim и мне не понравился результат. Там тупо лепится С-union и размер получается в памяти какой-то невменяемый, хотя казалось-бы компилятор точно каждый раз знает размер этого типа...
источник

VB

Vladimir Berezenko in ru.nim.talks
Ну это то что решается в ООП куда проще в целом, без извращений, а лишь через std::map<enum, BaseClass> ну или через массивы. Вот уж казалось что в ниме такой момент продуман, ан нет, скастовал тип к базовому и привет.
источник

f

for(int c; (c = getc... in ru.nim.talks
Невменяемый конкретно значит "большой непонятно откуда взявшийся оверхед"?
источник

VB

Vladimir Berezenko in ru.nim.talks
Не "большой непонятный оверхед", а "большой понятный оверхед" но непонятно почему там получившийся. Точнее понятно как он так получился, но непонятно почему компилятор это всё не ликвидирует на этапе сборки.
источник

f

for(int c; (c = getc... in ru.nim.talks
Вопрос предпочтений. Для работы с AST и околокомпиляторной логикой я бы просто застрелился если бы мне нужно было каждый раз писать по 30-40 классов для каждого типа деревьев
источник

VB

Vladimir Berezenko in ru.nim.talks
Гы, для работы с AST надо брать yacc или bison :))
источник

f

for(int c; (c = getc... in ru.nim.talks
работа с AST не заканчивается на парсинге, она там только начинается. +bison не может из коробки строить дерево, там напильником нужно дорабатывать еще два года потом
источник

f

for(int c; (c = getc... in ru.nim.talks
не совсем понял что там ликвидировать при сборке. Оно генерирует

c
struct T {
 Enum kind;
 union {
 ...
 }
}


и потом просто вставляет группы полей
источник

VB

Vladimir Berezenko in ru.nim.talks
я знаю что он там генерирует, дело как-раз в том самом union. вот вся проблема в том, что юнион всегда расширяется до максимального объёма лежащего там элемента. соответственно если ты положишь byte и struct X c ведром полей, то размер юниона будет равен размеру struct X даже если ты НИ РАЗУ в коде не будешь её использовать хоть как-то. я вот про это.
источник

f

for(int c; (c = getc... in ru.nim.talks
Это да, размер должен быть известен полностью, так как это  value объекты
источник

f

for(int c; (c = getc... in ru.nim.talks
Хотя учитывая что ref object и object практически ничем не отличаются, ведро полей обычно выносится в отдельный объект
источник

VB

Vladimir Berezenko in ru.nim.talks
ну таки указатель на объект и сам объект отличаются КМК. я проверял :)
источник

f

for(int c; (c = getc... in ru.nim.talks
Но зато я теперь могу класть данные в одном блоке и они нормально работают на стеке (если мне нужно иметь список разный подтипов)
источник

VB

Vladimir Berezenko in ru.nim.talks
kind - же нельзя сменить, точнее это бессмысленно. зачем тогда каждый раз выделять на стеке ВЕСЬ объект?
источник

f

for(int c; (c = getc... in ru.nim.talks
В большинстве случаев оверхед не такой большой, так что это не имеет смысла
источник

f

for(int c; (c = getc... in ru.nim.talks
kind менять нельзя, но это имеет смысл
источник