f
Приходится чаще выписывать vtable вручную через case, но зато компилятор может сказать точно где я не обработал что-то
Size: a a a
2021 August 18
VB
Понятно. Унылый вариант ООП :)
f
ну в целом да, хотя как обычно "есть нюансы"
f
По большей части это связано с тем что есть еще
set[enum], array[enum, T] через которые можно прикрутить очень интересную логику если нужноVB
Я тут поигрался с case типами в Nim и мне не понравился результат. Там тупо лепится С-union и размер получается в памяти какой-то невменяемый, хотя казалось-бы компилятор точно каждый раз знает размер этого типа...
VB
Ну это то что решается в ООП куда проще в целом, без извращений, а лишь через std::map<enum, BaseClass> ну или через массивы. Вот уж казалось что в ниме такой момент продуман, ан нет, скастовал тип к базовому и привет.
f
Невменяемый конкретно значит "большой непонятно откуда взявшийся оверхед"?
VB
Не "большой непонятный оверхед", а "большой понятный оверхед" но непонятно почему там получившийся. Точнее понятно как он так получился, но непонятно почему компилятор это всё не ликвидирует на этапе сборки.
f
Вопрос предпочтений. Для работы с AST и околокомпиляторной логикой я бы просто застрелился если бы мне нужно было каждый раз писать по 30-40 классов для каждого типа деревьев
VB
Гы, для работы с AST надо брать yacc или bison :))
f
работа с AST не заканчивается на парсинге, она там только начинается. +bison не может из коробки строить дерево, там напильником нужно дорабатывать еще два года потом
f
не совсем понял что там ликвидировать при сборке. Оно генерирует
и потом просто вставляет группы полей
c
struct T {
Enum kind;
union {
...
}
}
и потом просто вставляет группы полей
VB
я знаю что он там генерирует, дело как-раз в том самом union. вот вся проблема в том, что юнион всегда расширяется до максимального объёма лежащего там элемента. соответственно если ты положишь byte и struct X c ведром полей, то размер юниона будет равен размеру struct X даже если ты НИ РАЗУ в коде не будешь её использовать хоть как-то. я вот про это.
f
Это да, размер должен быть известен полностью, так как это value объекты
f
Хотя учитывая что
ref object и object практически ничем не отличаются, ведро полей обычно выносится в отдельный объектVB
ну таки указатель на объект и сам объект отличаются КМК. я проверял :)
f
Но зато я теперь могу класть данные в одном блоке и они нормально работают на стеке (если мне нужно иметь список разный подтипов)
VB
kind - же нельзя сменить, точнее это бессмысленно. зачем тогда каждый раз выделять на стеке ВЕСЬ объект?
f
В большинстве случаев оверхед не такой большой, так что это не имеет смысла
f
kind менять нельзя, но это имеет смысл