Size: a a a

2021 August 18

f

for(int c; (c = getc... in ru.nim.talks
Если бы это можно было делать, то сериализация например бы упрощалась до

for name, field in fieldPairs(target):
   write(buffer, field)

for name, field in fieldPairs(target):
   load(buffer, pos, field)
источник

VB

Vladimir Berezenko in ru.nim.talks
я про то что kind технически можно попробовать сменить, но физически на уровне кода это не будет иметь смысла. в С этот трюк с юнионом часто используется, кстати, а вот в nim это не вариант.
источник

f

for(int c; (c = getc... in ru.nim.talks
И это как раз использует тот факт что мы выделяем сразу всю память, так что
proc load(seq[T] может загрузить данные просто скопировав побитно
источник

VB

Vladimir Berezenko in ru.nim.talks
у меня при написании кода для rabbitmq и redis оверхед получается знатный
источник

VB

Vladimir Berezenko in ru.nim.talks
Ну тут да, но это грязный хак :)
источник

G

Gabben in ru.nim.talks
Так убери struct X, если не используешь)
источник

f

for(int c; (c = getc... in ru.nim.talks
Альтернативой было бы делать подклассы, которые затем (если нужно хранить в одном контейнере) были бы аллоцированы в куче? Ну тогда в чем проблема вынести struct X в ref object
источник

VB

Vladimir Berezenko in ru.nim.talks
не в этом цимес. дело в том что такое "убери" для разных частей кода должно быть разным.
источник

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
class B {}; class D : public B {}
источник

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
В тех случаях когда оверхед практически нулевой. К тому же для конкретно того что я делаю я слабо себе представляю ООП - все было бы угажено десятками подклассов и методов, которые можно совершенно спокойно положить в одну процедуру
источник

f

for(int c; (c = getc... in ru.nim.talks
+ я вижу всю логику кода *сразу*, и мне не нужно бегать по 15-30 реализациям чтобы понять что делает compiler/sem.semStmt
источник

f

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

f

for(int c; (c = getc... in ru.nim.talks
И к вопросу об оверхеде - тот факт что мы можем держать все на стеке или одном блоке памяти, не тратим времени на динамическую диспетчеризацию вызовов и т.д. тоже нужно учитывать. sizeof это конечно важно, но не единственное что нужно проверять
источник

VB

Vladimir Berezenko in ru.nim.talks
с вариантами весьма сложно делать динамическую диспетчеризацию. везде по факту надо vtable городить + очень сложно с результирующими данными. я конечно тоже навтырялся, но выглядит не очень красиво.
источник

f

for(int c; (c = getc... in ru.nim.talks
В ООП я делаю тот же самый case, только в 15 методах а не 15 ветках
источник

VB

Vladimir Berezenko in ru.nim.talks
динамическая диспетчеризация в С++ оверхеда не даёт никакого практически, тот-же case of даст куда больший.
источник