Когда-то были времена, когда еще не существовало ни инсталляторов, ни толком Windows, жесткие диски были маленькими, а найти нужный разархиватор для экзотического формата типа rar было не так просто. Поэтому если бы не было необходимости в SFX-архивах, то их бы и не реализовывали лидеры индустрии — ARJ, например, или HA.
В своем предыдущем комментарии я привел код реализации, которую я не могу назвать совсем уж оптимальной, но которая, во всяком случае, как минимум в несколько раз быстрее регулярных выражений, и предложил вам оценить скорость ее работы по сравнению с вашим "простым решением". Пространство для оптимизации по скорости выполнения присутствует — можно, например, сделать inplace-версию, т.к. это более частый сценарий использования.
Писать статью для тривиального решения? Зачем? Максимальное значение кодепоинта юникода — 0x10FFFF, значит, битовая карта из 0x110000 бит покроет весь диапазон, а для хранения этой карты достаточно 17408 значений по 64 бита каждое. Проходимся по списку фильтруемых символов, заносим их в битовую карту. Проходим по строке, и если знак отсутствует в битовой карте, то дописываем его в конец результирующей строки. Если место в результирующей строке закончилось, то увеличиваем ее в 1.25 раз, а в конце отрезаем хвост по фактической длине, включая терминатор. Мое решение еще включает два частных случая — когда в списке фильтров нет ни одного символа вообще (строка просто копируется), и когда там один символ (можно обойтись без битовой карты). В принципе, можно еще было бы сократить потребление памяти, если сначала выделять битовую карту на 28 бит, и увеличивать ее до 216 бит при использовании соответствующих символов, и только затем поднимать до 221 при выходе за пределы BMP.
К чему очередная мусорная статья "Как я писал Hello world", если подобное реализует любой начинающий программист?
Самое простое решение может быть не самым удачным только в двух случаях
В теории разницы между теорией и практикой нет — а на практике есть. Вся проблема в т.н. «дырявых абстракциях» — большинство вещей устроено намного сложнее, чем позволяет предположить их внешний интерфейс. Примеров множество — конкатенация строк в цикле без использования StringBuilder-а, побайтовое копирование памяти, работа с сетевыми ФС как с локальными, перемещение файлов между границами разделов, «заторы» в TCP, использование регулярок без кэша, и т.д.
Насчет «статистики» — простите, а какого вида статистику вы ожидаете? Внутри NSRegularExpression не магия происходит — посмотрите исходники, почитайте, как в принципе работают регулярные выражения, и какой оверхед имеет компиляция регулярного выражения (токенизация, разбор в AST, генерация байткода и его последующее выполнение). То, что у вас речь не идет о романах объема «Войны и мира», только усугубляет ситуацию, т.к. на маленьких строках компиляция регулярок займет больше времени, чем непосредственно обработка.
Любопытства ради, проведите тест по производительности, и скажите, на каких начальных данных ваш код окажется быстрее?
Пользоваться моим кодом в результате не сложнее, чем вашим — прошу лишь извинить, что я не знаю ObjC и поэтому не могу привести NSString к массиву codepoint-ов самостоятельно.
И третье, опытному программисту, скорее всего, эта статья не откроет новые горизонты, но остальным, мы надеемся, сэкономит драгоценные минуты их личной жизни.
А потом люди удивляются — как так выходит, что современные компы тупят, как в старые-добрые времена? Ну, зато программист время сэкономил. Ваш подход учит неопытных программистов плохому, и это грустно.
Ну и вы никак не прокомментировали, каким образом короткая реализация поможет пользователю библиотеки, который все равно в исходники заглядывать не будет (пока что-нибудь не сломается), и будет использовать одну лишь функцию?
Далеко не всегда самое короткое решение — самое удачное с точки зрения производительности и/или потребления памяти. Например, компиляция регулярного выражения — ужасно ресурсоемкий процесс, по сравнению с проходом по строке и фильтром по таблице.
Более того, если вы предоставляете библиотеку, то какая разница конечному пользователю, сколько строк занимает реализация той или иной функции? Все равно для пользователя это единственный вызов.
С удивлением обнаружил боковые колесики у этого агрегата. Т.е. держать равновесие оно не умеет — а чем он, в таком случае, отличается от обычной радиоуправляемой машинки?
Точно, и понаделывать всяких LIDRов (Local ID Registry), RIDRов (Regional ID Registry), еще до кучи PIDRов каких-нибудь, простихоспади. "Купи десять ID и получи первый год со скидкой 50%! Всего $1999, только сейчас!"
Плохой, нехороший автор сайта! Надо было владельцу сайта позаботиться о своей совместимости с Яндексом! Куда он смотрел вообще? Он понимал, кому дорогу переходит, на кого вообще тэг открывает?
Надо решить проблему радикально — просто все владельцы сайтов должны будут перед размещением получить у Яндекса соответствующее разрешение, подтверждающее совместимость сайта с техническими возможностями Яндекса, а также его целями и намерениями. Естественно, не бесплатно.
Ну, эта штуковина выглядит монолитной, и, возможно, защелкивается — иначе бы она отваливалась от терминала, так ведь? Банкоматы всегда говорят "убедитесь, что внешний вид банкомата соответствует образцу", т.е. есть, с чем сравнивать — с чем сравнивать терминалы? Ну и накладки на банкомат оставляют щели по краям — а тут как, переворачивать терминал пузиком кверху?
Но ведь можно просто с некоторой периодичностью обрубать историю. Например, каждые 5 лет создавать "снапшот" состояния сети — а именно, на каком кошельке сколько денег, и какие есть активные транзакции на момент взятия снапшота. Таким образом, все, что было до, можно будет удалить. Да, потеряется возможность проследить каждую монету до ее рождения, но так ли это нужно на промежутках в пять лет? Те, кому это действительно нужно, смогут хранить у себя полную версию дерева, например.
>>> list(unicodedata.normalize('NFD', chr(1105))) ['е', '̈']Писать статью для тривиального решения? Зачем? Максимальное значение кодепоинта юникода — 0x10FFFF, значит, битовая карта из 0x110000 бит покроет весь диапазон, а для хранения этой карты достаточно 17408 значений по 64 бита каждое. Проходимся по списку фильтруемых символов, заносим их в битовую карту. Проходим по строке, и если знак отсутствует в битовой карте, то дописываем его в конец результирующей строки. Если место в результирующей строке закончилось, то увеличиваем ее в 1.25 раз, а в конце отрезаем хвост по фактической длине, включая терминатор. Мое решение еще включает два частных случая — когда в списке фильтров нет ни одного символа вообще (строка просто копируется), и когда там один символ (можно обойтись без битовой карты). В принципе, можно еще было бы сократить потребление памяти, если сначала выделять битовую карту на 28 бит, и увеличивать ее до 216 бит при использовании соответствующих символов, и только затем поднимать до 221 при выходе за пределы BMP.
К чему очередная мусорная статья "Как я писал Hello world", если подобное реализует любой начинающий программист?
Насчет «статистики» — простите, а какого вида статистику вы ожидаете? Внутри NSRegularExpression не магия происходит — посмотрите исходники, почитайте, как в принципе работают регулярные выражения, и какой оверхед имеет компиляция регулярного выражения (токенизация, разбор в AST, генерация байткода и его последующее выполнение). То, что у вас речь не идет о романах объема «Войны и мира», только усугубляет ситуацию, т.к. на маленьких строках компиляция регулярок займет больше времени, чем непосредственно обработка.
Любопытства ради, проведите тест по производительности, и скажите, на каких начальных данных ваш код окажется быстрее?
А потом люди удивляются — как так выходит, что современные компы тупят, как в старые-добрые времена? Ну, зато программист время сэкономил. Ваш подход учит неопытных программистов плохому, и это грустно.
Ну и вы никак не прокомментировали, каким образом короткая реализация поможет пользователю библиотеки, который все равно в исходники заглядывать не будет (пока что-нибудь не сломается), и будет использовать одну лишь функцию?
Более того, если вы предоставляете библиотеку, то какая разница конечному пользователю, сколько строк занимает реализация той или иной функции? Все равно для пользователя это единственный вызов.
Надо решить проблему радикально — просто все владельцы сайтов должны будут перед размещением получить у Яндекса соответствующее разрешение, подтверждающее совместимость сайта с техническими возможностями Яндекса, а также его целями и намерениями. Естественно, не бесплатно.