TT
блин, вот что бывает, когда функциональщики пишут сишный код https://github.com/erlang/otp/blob/3715839afb532c156771b8daddcba03fb2902502/erts/emulator/beam/erl_bif_lists.c#L1162
Size: a a a
2019 August 26
TT
хрен его пойми, как сам разворот в памяти происходит)
TT
да, не на 100% уверен, но кажется, что да
TT
список должен быть односвязный, короче. и указатель есть только на первую ноду в этом списке
TT
вот чтоб сделать ++ или там еще что-то, в реальности нужно пройти весь список первый до конца
TT
чтобы найти последний элемент
TT
бинарь же — последовательный кусок памяти, он хранится как просто указатель на начало и длина. соответственно, тебе без разницы, ты и первый элемент этого бинаря найдешь и последний по сути одинаково быстро
TT
ну пару сложений нужно будет выполнить — но это неважно. от размера бинаря это не зависит
TT
а вот у списка зависит
TT
и даже если компилятор делает ту оптимизацию, о которой я выше сказал, вот это уже он никак не сможет убрать
TT
вот если бы в списке хранился указатель на конец этого списка, то да, можно было бы сразу переместиться в конец
TT
но что-то мне подсказывает, что
struct _eterm *tail; — это именно "хвост" в функциональном понимании. т.е. все, кроме первого элементаTT
а не указатель на конец
TT
потому что если это не так, то будет не очень понятно, где хранится указатель на следующий. _eterm *head — это должен быть текущий элемент (голова списка), произвольный терм
TT
одно меня правда смущает, почему
struct _eterm *tail;, а не struct Erl_List *tail;TT
ну да ладно
TT
в любом случае, при использовании ++ это тоже надо иметь ввиду
TT
тут что-то аяй?)
я не понял
я не понял
TT
ну CAR, CDR, CONS