# и table.getn

Страницы: 1
RSS
# и table.getn, # и table.getn - косячно
 
Код
a={}
   a[0]={sellprice=1, bayprice=1}
   a[-1]={sellprice=1, bayprice=1}
   a[-2]={sellprice=1, bayprice=1}
   message(""..#a);
сообщает 0
Код
a={}
   a[0]={sellprice=1, bayprice=1}
   a[1]={sellprice=1, bayprice=1}
   a[2]={sellprice=1, bayprice=1}
   message(""..#a);
сообщает 2, что, кстати, тоже недостоверно.

Какой есть простой способ это победить? table.getn вообще не существует, видимо, выдает "attempt to call a nil value (field 'getn')"
 
В Lua массивы начинают свою нумерацию от 1. Если будет дырка, то оператор # не вернет корректно значение.

Победить - создать метатаблицу, с переопределенным метаметодом  __len
 
Цитата
Nikolay написал:
В Lua массивы начинают свою нумерацию от 1. Если будет дырка, то оператор # не вернет корректно значение.

Победить - создать метатаблицу, с переопределенным метаметодом  __len
Фигня, какая-то, по-моему, это, но спасибо, так лучше... :)
Код
a={}
   setmetatable(a,{__index={len=function(len) local incr=0 for _ in pairs(len) do incr=incr+1 end return incr end}})
   a[0]={sellprice=1, bayprice=1}
   a[1]={sellprice=1, bayprice=1}
   a[2]={sellprice=1, bayprice=1}
   message(""..#a.." "..a:len());
 
Nikolay, Это если их инициализировать прямо в коде. У меня большинство массивов начинаются с нуля, а за дырками (в тех массивах, где они возможны) и размерами массивов слежу сам. Например, в стеках (заявок, сделок, прерываний) длина массива (она же ID последнего элемента) хранится как раз в его нулевом элементе. Очень удобно и очень надёжно, и плевать, что там "оператор #" по этому поводу думает - им я вообще не пользуюсь. Не говоря уже про "переопределенные метаметоды".
 
Да, никто не мешает самому организовать счетчик при добавлении и удалении элемента.
 
Цитата
Владимир написал:
Nikolay, Это если их инициализировать прямо в коде. У меня большинство массивов начинаются с нуля, а за дырками (в тех массивах, где они возможны) и размерами массивов слежу сам. Например, в стеках (заявок, сделок, прерываний) длина массива (она же ID последнего элемента) хранится как раз в его нулевом элементе. Очень удобно и очень надёжно, и плевать, что там "оператор #" по этому поводу думает - им я вообще не пользуюсь. Не говоря уже про "переопределенные метаметоды".
почти как у меня, тоже в нулевом - максимальный размер таблиц сделок и стопов, но храню не стеком.а таблицей.
Стек - это кипа -  LIFO.
В этом случае у Вас последний обрабатывается первым, а до первого очередь может никогда не дойти.
Должна быть либо очередь либо таблица.  
 
nikolz, Стек-то LIFO, если брать только очерёдность обслуживания, но это не обязательно. Чистый стек, который однозначно LIFO у меня только стек прерываний. А стек сделок уже не стек в классическом понимании - там выбирается та сделка, которая сработала - и элемент с этой сделкой может располагаться где угодно. А на его место закидывается действительно последний на данный момент, чтобы дырок в массиве не было, а размер стека тоже уменьшается на единицу. Абсолютно та же техника и в стеке заявок, но там элементы вообще выбираются чуть ли не в порядке очереди. Но не совсем - некоторые элементы могут выбираться и вне очереди. А от стека во всех них то, что меняется всегда именно последний элемент - либо выбрасывается из стека, либо переносится в дырку. И что значит "максимальный размер"? ТЕКУЩИЙ размер! И он в большинстве случаев вообще нигде не хранится (для статических массивов), либо хранится в отдельной структуре данных, а нулевой элемент может использоваться и как обычный элемент массива, и для хранения метаданных о самом массиве. Например, нулевой элемент массива тикеров представляет собой сложное разветвлённое дерево на несколько десятков полей. Всё определяется удобством доступа к данным в каждом конкретном случае.

Как мне много лет назад ответил один программист, когда я ему тоже заявил, что стек это просто LIFO: "Просто LIFO - это магазин к АКМ". И он был прав!  :smile:  
Страницы: 1
Читают тему
Наверх