Телеграмм чат группы ru_nim

Size: a a a

ru.nim.talks

2021 August 18

Если бы это можно было делать, то сериализация например бы упрощалась до

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

for name, field in fieldPairs(target):
    load(buffer, pos, field)

источник

11:32пожаловаться #1

Vladimir Berezenko in ru.nim.talks

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

источник

11:32пожаловаться #2

for(int c; (c = getc... in ru.nim.talks

И это как раз использует тот факт что мы выделяем сразу всю память, так что
proc load(seq[T] может загрузить данные просто скопировав побитно

источник

11:34пожаловаться #3

Vladimir Berezenko in ru.nim.talks

у меня при написании кода для rabbitmq и redis оверхед получается знатный

источник

11:34пожаловаться #4

Vladimir Berezenko in ru.nim.talks

Ну тут да, но это грязный хак :)

источник

11:35пожаловаться #5

Gabben in ru.nim.talks

Так убери struct X, если не используешь)

источник

11:37пожаловаться #6

for(int c; (c = getc... in ru.nim.talks

Альтернативой было бы делать подклассы, которые затем (если нужно хранить в одном контейнере) были бы аллоцированы в куче? Ну тогда в чем проблема вынести struct X в ref object

источник

11:37пожаловаться #7

Vladimir Berezenko in ru.nim.talks

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

источник

11:38пожаловаться #8

Vladimir Berezenko in ru.nim.talks

зачем подклассы? просто наследники и всё

источник

11:38пожаловаться #9

for(int c; (c = getc... in ru.nim.talks

ну наследники, хотя мне казалось что это одно и то же

источник

11:39пожаловаться #10

for(int c; (c = getc... in ru.nim.talks

class B {}; class D : public B {}

источник

11:40пожаловаться #11

Vladimir Berezenko in ru.nim.talks

Это разные вещи. Наследование и инкапсуляция.

источник

11:41пожаловаться #12

for(int c; (c = getc... in ru.nim.talks

Не суть. Я имел ввиду что вместо варианта была бы сделана иерархия объектов. Но в целом это вопрос привычки, и использования нужного инструмента в нужном месте. Я бы тоже хотел чтобы в ниме было нормальное ООП, но варианты мне тоже очень нравятся

источник

11:44пожаловаться #13

for(int c; (c = getc... in ru.nim.talks

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

источник

11:46пожаловаться #14

for(int c; (c = getc... in ru.nim.talks

+ я вижу всю логику кода *сразу*, и мне не нужно бегать по 15-30 реализациям чтобы понять что делает compiler/sem.semStmt

источник

11:47пожаловаться #15

for(int c; (c = getc... in ru.nim.talks

Варианты тоже довольно уродские в некоторых местах, особенно когда дело касается инициализации

источник

11:47пожаловаться #16

for(int c; (c = getc... in ru.nim.talks

И к вопросу об оверхеде - тот факт что мы можем держать все на стеке или одном блоке памяти, не тратим времени на динамическую диспетчеризацию вызовов и т.д. тоже нужно учитывать. sizeof это конечно важно, но не единственное что нужно проверять

источник

12:08пожаловаться #17

Vladimir Berezenko in ru.nim.talks

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

источник

12:20пожаловаться #18

for(int c; (c = getc... in ru.nim.talks

В ООП я делаю тот же самый case, только в 15 методах а не 15 ветках

источник

12:21пожаловаться #19

Vladimir Berezenko in ru.nim.talks

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

источник

12:22пожаловаться #20