- 1
- 2
- 3
- 4
local buff = ""
for line in io.lines() do
buff = buff .. line .. "\n"
end
Метатабличный / Говнокод #24031
0
Несмотря на его безобидный вид, этот код может сильно ударить по быстродействию для больших файлов:
например, чтение файла размером 1 Мб занимает 1,5 минуты
Запостил: 
3oJIoTou_xyu,
(Updated )
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
хуй
хуйхуй
хуйхуйхуй
хуйхуйхуйхуй
итд
Прежде чем GC его заберет у тебя будет тратиться память.
В жабах и CLR для этого есть StringBuilderы
Погугли "Shlemiel the painter’s algorithm"
Шлемиль устроился на работу маляром и должен был наносить разметку посредине дороrи. В первый день он взял бочку краски и разметил 300 метров дороrи.
-Неплохо! - сказал босс - Ты быстро работаешь! - И заплатил ему денежку.
На следующий день Шлемиль осилил только 150 метров.
- Ну что ж, не так здорово, как вчера, но ты все равно быcrpо работаешь. 150 метров это не мало, - сказал босс и заплатил ему денежку. Еще через день Шлемиль расчертил 30 метров дороrи.
Bcero 30 метров! - рассвирепел босс - Это никуда не годится. В первый день ты сделал в десять раз больше. Что случилось?
- Ничеrо не могу поделать, - говорит Шлемиль. С каждым днем приходится все дальше и дальше уходить от бочки с краской..
Возможно еще придется находить длину строки. Я не знаю как Lua ее хранит: если строки там null terminated то каждый вызов у нас будет иметь O(длина строки), и тогда будет еще хуже.
11.6 String Buffers
Suppose you are building a string piecemeal, for instance reading a file line by
line. Your typical code would look like this:
local buff = ""
for line in io.lines() do
buff = buff .. line .. "\n"
end
Despite its innocent look, this code in Lua can cause a huge performance penalty
for large files: for instance, it takes 1.5 minutes to read a 1 MB file on my old
Pentium machine.1
почему
a.concat(a, ",") тоже не работает.
table.concat(a, ",") почему-то работает.
Почему-то именно a.concat(a, ",") и синтаксический сахар a:concat(",") не хотят захватывать значение a.
в луа это одно и тоже
b.concat(a, ",") работает.
b=a
b.concat(a, ",") не работает.
rawget(table,"concat")(a,",")
А так не работает:
rawget(a,"concat")(a,",")
То есть конструктор {} не добавляет к таблице методы.
хуйня-с
вот у строки есть
ташто в table.concat table это модуль(сиречь таблица) а не тип.
Вооще говоря противно конечно, почти так же противно как тот факт што
``"A".find`` это синт ошибка, а
a = ""
a.find --это функция
Lua непредскаузем, как C++:)
a = {"a", "b", "c", concat = table.concat}
Тогда всё будет работать.
даже твой пример можно переписать так
setmetatable(a, table)
Тогда всё работает.
лол, этоже прототи наследованне (я еще до ООП не дочитал)
lua: attempt to call method 'concat' (a nil value)
metatableу делегируются вызовы неизветсных методов, вставки, получения длины итд, но только надо это явно сообшщить
три раза
пишут что у метатаблы есть метод __index, который вызывается при обращении по индексу при отсутвтвии значения
Вероятно можно это как-то обыграть
Делаем так, чтобы метод __index искал методы не в нашей таблице, а в table.
1. У типов table и userdata создаётся своя метатаблица на каждый экземпляр, поэтому её придётся привязывать после каждого вызова конструктора.
2. У строковых и числовых типов метатаблица одна на класс.
3. Для строк уже создана метатаблица, а поскольку она одна на весь класс строк, то moyastroka:format работает.
4. Парсер — лох, поэтому "петух":format не работает. Приходится литерал сохранять во временной переменной.
5. Переменная table — это такая „таблица“, не содержащая данных, но содержащая методы, поэтому table.concat работает.
И к коду выше. Зачем мучаться каждый раз привязывать метатаблицу к таблице, заебешься когда у тебя будет 100500 таблиц и придеться явно каждый раз привязывать данную метатаблицу.
Можно юзнуть метаметод __newindex у _G, главное в рекурсию не улететь. И когда мы будет создавать глобаль уже будет автоматом таблице привязавоться метатаблица с методом __index с той самой библой table.
С локалями данный метод не работает так как локали не создаются в _G а где-то в другом месте. Пока сам не знаю где, не доходило дело и до них.
Зойчем зосорять просранство имён?
("питух"):format
работает
("petuh"):upper()
незасорил пространство имен, проверьт
Ну теперь точно ничего не сделает, потерял ссылку на сам сборщик.
Добро пожаловать утечка
foo зажат у setmetatable между булками
В луа же так идеома итератора работает
так гц же
>>сборщик мусора в поток параленьно
так, вот отсюда поподробнее.
Я знаю только про корутины которые работают в одном треде операционки.
Разве в луа есть какие-то другие треды?
Что будет если у меня переменная указывает на объект, который забрал гц? Может так быть? Если да, то что будет? nil?
Нет не нил, а помоему вывалится с ошибкой. НО ВСЕ ЭТО НИТОЧНО, НАДО БОЛЬШЕ ИСЛЕДОВАНИЙ, я давно с этим баловался
гарантировать патокабизопастность должен host, в который встроен lua
сам lua для этого средств не имеет
Пиздешь.
file = io.open("petux.txt","r")
file:close()
a = {"a", "b", "c",
concat = table.concat,
insert = table.insert,
move = table.move,
pack = table.pack,
remove = table.remove,
sort = table.sort,
unpack = table.unpack}
Ничего не забыл?
foo = {["spam"] = 42}
можно записать как
foo = {spam = 42}
Что то есть неуловимое от старого JSа где объект есть массив ассоциативный
a:concat(",") -- теперь работает
2. Повторил тебе джважды, проверь.
a:concat(",") -- теперь работает
В питоне такой код пишут часто и всем похуй. Пока не понадобится запустить его на жытоне, например.
Жытон - это Jython? Я на нём ни разу не писал, ты о чём?
Для жытона модули кто пишет?
Я не понял, ты хочешь мутабельную уникодную сьроку????
А ты доходчивый.
Легко сделать мутабельность для строки, у которой представление символа имеет фиксированный размер: для байтового массива, для восьмибитных кодировок, для UCS-2 (строго 16 бит = 2 байта на символ), для UCS-4 (строго 32 бита = 4 байта на символ).
Трудно сделать мутабельность для строки, символ которой имеет переменный размер (для UTF-8 и прочих MBCS). Почему? Потому что при изменении единственного символа строки может измениться длина байтового представления. Разработчики испугались трудностей.
Вернёмся к примеру:
Если s в UTF-8, то, во-первых, для поиска s[1] придётся просканировать всю строку до интересующего индекса, ведь заранее нельзя угадать, сколько байт занимают предыдующие буквы. В данном случае требуется узнать, сколько байт займёт буква "х". Во-вторых, если будем заменять "а" на "у", то всё хорошо, а если попытаемся заменить на латинскую букву (которая в UTF-8 занимает меньше места), то придётся сдвигать на 1 байт весь остаток строки.
Можно для пирфоманса внутри хранить строку в UCS-4 (4 байта на символ), а преобразовывать в utf-8 только при вводе-выводе, но тогда хранение строк будет жрать больше памяти.
Мутабельность строк это, ваще гря, ящик пандоры. Открыли его только в Ruby (и там пришлось ввести понятие symbol чтобы не юзать строки в качестве ключей хеша), остальные языки боятся.
Потому что строки имеют дурную привычку быть инициализированными строковыми литералами, и у тебя 100500 строк, которые все указывают на строчку "pitux" где-то в коде, и когда ты хочешь поменять один символ тебе придетца делать CopyOnWrite со всеми вытекаюшими.
А в случае сишечки так еще и копелятор имеет право сунуть литерал в место, запрешенное для записи (ну в страницу кода там или в сегмент какой-нить).
мутабельность строк имеет ровно одну проблему - ее нельзя будет использовать в качестве ключа в словаре, но тебе это и так никто не даст.
Для ключей они, разумеется, не подходят: нужны символы
Ненавижу, когда пассы руками лезут куда не просят. во время ёбли.
1) выделает N памяти
2) если место кончается -- делает realloc.
> если место кончается -- делает realloc.
Чувствуешь разницу?