Так а мы же от конкатенации уходим,а тут она, родимая...

Так а мы же от конкатенации уходим,а тут она, родимая...

Смотри на количество элементов. До условных 10 небольших элементов, эвристически конкатенировать быстрее чем мутить таблички.

Функция выглядит вот так: function string.joinsep(orig, sep, ...) sep = sep or "" local result = {} table.insert(result, orig) for _, field in ipairs(table.pack(...)) do table.insert(result, field) end return table.concat(result, sep) end

Чем вот так будет плохо? function string.joinsep(orig, sep, ...) return table.concat({orig, ...},sep) end

И оно будет неправильно работать при nil'ах в orig или "...", вот эта штука правильно вернёт правильные ошибки. table.concat((table.pack or pack)(orig, ...), sep)

Из минусов - одна аллокация таблицы, но с этим можно жить, имхо.

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

Так в случае {...} размер известен

Байзевей никогда не пакуй туплы в {...} напрямую, только через table.pack который нормально переносит все значения и добавляет ключ n, а table.unpack вполне себе использует этот ключ и возвращает ровно тот тупл который был запакован.

Ну ссылку на документацию по Lua-то можно?

В 5.2 была локальная переменная arg. Не знаю, осталась ли сейчас. В ней как раз {...} Поэтому рекомендация не понятна. Да, я знаю, чем отличается pack, но считаю это преждевременной оптимизацей

Этот arg — это аргументы командной строки при запуске приложения, это не локальные аргументы функции.

Надо будет чекнуть байткод.

Качаю блин 5.2

В 5.3, время качать 5.2

Хммм

print(_VERSION) ?

Тут как раз по делу lua.org/pil/5.2.html

У тебя блин скриншот, или ты думаешь я обманываю? ) _VERSION тоже можно переписать кста. Но я только что скачал бинарь для 5.2.4, можешь сделать то же самое.

Вот это очень странно, потому что в 52.exe никак не может подгружать 53.dll если в нём самом не прописаны фолбеки. Имя шаред либы должно быть совершенно конкретное, иначе бы все либы а ля openal32 и openal64 пытались бы подгружать друг друга с закономерным результатом.

Зависит от того, как выполнен отладчик. Отладчик Lua может быть привязан к конкретной версии. Если нет отладчика в запуске, то у меня только вопрос про конкретный релиз 5.2. Может, Роберт удалил этот arg при обновлении. И я не хотел бы спорить насчёт {...} vs pack. У каждого свои предпочтения. Насчёт скорости, соглашусь, что нужно замерять.

И я не хотел бы спорить насчёт {...} vs pack. У каждого свои предпочтения. Тут нет предпочтений. {...} не позволяет точно распаковать наборы значений вроде {1, 2, nil, 5, nil, nil}. # не сможет определить длину, споткнувшись о случайный nil, потому что использует бинарный поиск. ipairs споткнётся об первый же nil. pairs/next определит только граничные не-nil-значения, он не в курсе что там есть хвост из nil'ов. Поэтому есть только два способа упаковывать варарги в таблицу — pack или — вручную перебирать через select, плюс указать точное значение элементов, то есть вручную сделать то же что делает pack. ВСЕ другие способы приводят к потерям данных. Точка.

Господа и, если таковые присутствуют, дамы! С новым годом всех! Полез я тут, значится, почитать про оптимизацию кода в Lua и наткнулся на сайт ComputerCraft. В частности, на вот эту статью. Увидел про упоминание тернарных операторов и пошел читать. Как говорится, век живи, век учись! До сегодняшнего момента я, честно говоря, не совсем понимал как это работает, а ларчик-то простой и гибкий, оказывается! Из всех приколов я использовал только or при переборе значений и реализацию опциональных параметров. Но, знаете ли, там можно пойти еще глубже! И это охренеть как круто! Про оптимизацию, я подозреваю, что сказано не все.

потоковое чтение для json не сделать, т.к. только дойдя до конца можно понять, что коллекция/массив в json валидная. Но есть jsonl, который можно по-строчно парсить, именно что в поточном режиме

t={...}; return #t вернёт длину без хвостовых nil. Это единственное, что может потеряться при сравнении с pack. В языке, где лишние параметры функций просто отбрасываются, считаю это разумным компромиссом. function g(v) end g(1,2,3) Кроме этого, в случае pack в дополнение к выделению памяти под индексную часть будет выделение памяти под key-value хранилище (хэш) ключей в таблице — под ключ "n". В случае {...} выделяется только память под индексную часть. Оттого эта {...} конструкция и существует, логично вписываясь в сделанные компромиссы при реализации интерпретатора и концепцию языка.

Хотя, чему там тормозить. . . Сишное все. Памяти потратится только на шаблон, чанки в параметрах и результирующую строку.

Чел.. Ты слышал что-то про бинарный поиск? Пора привыкнуть, что если я что-то говорю, под это существуют совершенно конкретные объективные причины, и если я ДЕСЯТЬ раз повторяю одно и то же — значит это проверено многократно и я тут в своё время успел обосраться раза три. table.len использует тот же самый тот же бинарный тот же поиск, поэтому смухлевать не получится. На тему хвостовых nil — от них может зависеть логика, например в местах где отправка nil'ов чаще приводит к ошибкам, и надо ругнуться "чел ты мне nil послал последним аргументом, почему всё таки послал а не опустил этот аргумент?".

Если вы хотите опровергнуть мои утверждения про {...}, то используйте {...}, пожалуйста, а не оператор инициации таблицы.

Будет выполняться код разбора шаблона, что, очевидно, небыстро.

Та чему там быть медленным? Функция string.format по сути выполняется на нативной стороне, это же не логика скрипта. Ну а функции такого рода в сях будут всяко быстрее, чем интерпретируемый код.

Если вы хотите опровергнуть мои утверждения про {...}, то используйте {...}, пожалуйста, а не оператор инициации таблицы.

Зачем вообще пытаться nilы пихать в таблицу? 😐 Если подобное и нужно, то лучше заменить nilы на false и не мучаться.

Например, возьмём ловку. Конструкция вида love.graphics.draw(img, x, y, _, _, _, 32, 32) встречается регулярно, потому что впадлу заполнять аргументы по дефолту. И кстати, там luajit (5.1). Что было бы если ловка паковала это как варарги в табличку и итерировала бы по ним? Она бы обосралась в 5.1 без pack'а.

Я просто даю пример где бы был обсёр. Понятное дело что сама ловка не использует варарги в таких местах.

Ну там, где-то в далёком 98 году приравняли скорость тиков ядов к фреймрейту. На старом компудахтере игра работает в 20 fps, и там тики нормальные. На современном 600 fps и яды шотают, стоит мизинчиком наступить в лужицу. Или нечто аналогичное.