LINUX.ORG.RU
ФорумTalks

PHP — почему оно такое в 2016?

 , , , ,


1

1
<?php
preg_match_all('/.*(дай)/u', 'Маздай', $Positions, PREG_OFFSET_CAPTURE);
print_r($Positions);
?>


Array
(
    [0] => Array
        (
            [0] => Array
                (
                    [0] => Маздай
                    [1] => 0
                )

        )

    [1] => Array
        (
            [0] => Array
                (
                    [0] => дай
                    [1] => 6
                )

        )

)
При этом в доках на официальном сайте:

If this flag is passed, for every occurring match the appendant string offset will also be returned.

String, Карл!

А пользуясь случаем спрошу - собираюсь запилить сайт с электронной коммерцией на который будет высокая нагрузка. ЧТо лучше вместо ПХП использовать?

Deleted
()
Ответ на: комментарий от Deleted

А пользуясь случаем спрошу - собираюсь запилить сайт с электронной коммерцией на который будет высокая нагрузка. ЧТо лучше вместо ПХП использовать?

А php то чем не угодил? Со скоростью у него проблем нет.

aiive
()
Ответ на: комментарий от aiive

Не знаю, но его все дико обсирают почему-то)

Deleted
()
Ответ на: комментарий от crutch_master

String offset - это отступ в строке. Что не так-то?

Отступ в строке с многобайтными символами не может измеряться в байтах, иначе есть вероятность разрезать один символ пополам.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Вопрос в том что мешает разработчикам автоматически для внутреннего представления в PHP использовать UTF-16/32 вместо перекладывания ихней проблемы на пользователя

То, что оно жрёт память, замедляет работу, и не всегда нужно?

Инструмент должен решать проблему, а не добавлять новых

Есть такая басня «Мартышка и очки».

ихней

Фу нах.

no-such-file ★★★★★
()
Ответ на: комментарий от Deleted

будет высокая нагрузка.

Насколько высокая? Если больше 1000rps, то в классическом виде (apache/nginx + php_fpm) будет хреново. Можно попробовать ReactPHP и т.п. но насколько оно адекватно держит нагрузку - хрен его знает.

ЧТо лучше вместо ПХП использовать?

Ноду или го.

no-such-file ★★★★★
()
Ответ на: комментарий от h578b1bde

А, ещё забыл упомянуть ударе́ния

Обработку ударения и прочих составных знаков с 99% вероятностью нужно будет закостыливать, или подключать какие-то сторонние библиотеки практически в любом языке, даже там где поддержка юникода декларируется из коробки.

no-such-file ★★★★★
()
Ответ на: комментарий от aiive

Со скоростью у него проблем нет

При классическом использовании создается отдельный процесс/тред на каждый запрос. Т.е. чтобы обрабатывать 1000rps нужно держать порядка 500 процессов/тредов. Отгадай сколько памяти это сожрёт?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

То, что оно жрёт память, замедляет работу

Ты считаешь что в результате перекладывания проблемы на пользователя она решится эффективнее?

не всегда нужно

Сейчас 2016 год, UTF-8 в вебе — стандарт де-факто. Если ты англичанин или американец с такой же ЦА, тогда оно, возможно, тебе и не нужно, да, но это лишь слишком частный случай.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от crutch_master

Если руки из жопы, то можно и 1.5 символа вернуть. В чём проблема?

Если у разработчиков руки из жопы то да, бывает и такое. Нормальные же люди оперируют символами а не байтами.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Как ты предлагаешь оперировать символами, если у тебя переменная длинна этого самого символа? Делать костыль типа

if ($enconing == "utf8") $sym_len = 2;
?

crutch_master ★★★★★
()
Ответ на: комментарий от h578b1bde

это лишь слишком частный случай

Частный случай, это когда нужно матчить и доствать не только матч, но и смещение. ЭТО не всегда нужно, я бы даже сказал - очень редко.

UTF-8 в вебе — стандарт де-факто

В вебе да, внутри языков нет. Это стандарт для обмена информацией, а не для обработки.

в результате перекладывания проблемы на пользователя она решится эффективнее?

Конечно. Потому что только пользователь знает специфику своей задачи и что ему лучше подойдёт. Вполне возможно, что даже используя не мультибайтные функции можно решить конкретную задачу - обычное дело, если тебе не нужно, например. case-insensitive поведение.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

ЭТО не всегда нужно, я бы даже сказал - очень редко.

Ну так не используй специальный флаг для определения смещения если оно тебе не нужно, всего делов-то.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от crutch_master

Как ты предлагаешь оперировать символами, если у тебя переменная длинна этого самого символа?

Сторонники юникодов для этой цели предлагают юзать UTF-32 и ICU (для исключения модификаторов). Жуть-то какая, а...

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

4.2

Я ничего не утверждаю, это просто пример костыля, зачем принимать всё так близко к сердцу?

crutch_master ★★★★★
()
Ответ на: комментарий от h578b1bde

Зачем это вообще нужно?

Ну, как-то же нужно считать количество символов в строке. И вообще, дай определение понятию «символ» для начала.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Ну, как-то же нужно считать количество символов в строке

mb_strlen же, а какое представление у него там унутрях — не моя забота.

дай определение понятию «символ» для начала

https://en.wikipedia.org/wiki/Character_(computing)

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

а какое представление у него там унутрях — не моя забота.

Говнокодера ответ же, лол. Как ты сможешь нормальных код писать, если не понимаешь, как оно работает и на что оно способно?

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от crutch_master

Как ты сможешь нормальных код писать

А как нормальный код связан с длиной символа?

если не понимаешь, как оно работает и на что оно способно

Понимать как оно работает и плясать вокруг него с бубном и костылями — разные вещи. Абстракции для того и существуют чтобы облегчать жизнь. Попробуй поработать со строками на сишке, например.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

Абстракции для того и существуют чтобы

усложнять и запутывать.

Попробуй поработать со строками на сишке, например.

Так всё работает. Разница только в том, что для однобайтных кодировок можно продолжать юзать char и классические функции, а мультибайтные функции работают с wchar_t, который на линуксах 4 байта и превращает всё в UTF-32.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

усложнять и запутывать.

Пишешь с калькулятора?

Так всё работает

Пока у тебя в твоём таком простом коде на сишечке очередное переполнение буфера не найдут, ага.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

А как нормальный код связан с длиной символа?

Это зависит от того что ты с собрался делать со строками.

Абстракции для того и существуют чтобы облегчать жизнь.

В каком смысле облегчить? Писать код на отвяжись? Код под абстракцией может делать столько всего не нужного, что решение станет просто невозможно использовать.

Попробуй поработать со строками на сишке, например.

Не надо превращаться в свинью под дубом. В конечном итоге вся работа идёт через код, который как раз таки и написан на C.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

В каком смысле облегчить?

Не задумываться о том, один, два или три байта выделяется для буквы в том или ином языке.

Код под абстракцией может делать столько всего не нужного, что решение станет просто невозможно использовать.
В конечном итоге вся работа идёт через код, который как раз таки и написан на C.

Нет, в конечном итоге всё сводится к машинным инструкциям, которые на самом дне абстракций. Но мы ведь не пишем на них, правда?

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Все компьютеры - автоматизированные калькуляторы. И если коду требуется какой-нибудь Intel Xeon E5-2670 v3 @ 2.30GHz с 32-мя гигами оперативы, чтобы хоть как-нибудь взлететь - его сложно назвать нормальным.

saahriktu ★★★★★
()
Ответ на: комментарий от h578b1bde

Не задумываться о том, один, два или три байта выделяется для буквы в том или ином языке.

Да ты что? Правда что-ли? Никогда о таком не слышал.

Нет, в конечном итоге всё сводится к машинным инструкциям, которые на самом дне абстракций. Но мы ведь не пишем на них, правда?

И получается, что для того, чтобы найти символ в строке делается, допустим, 50к операций вместо 10.

crutch_master ★★★★★
()
Ответ на: комментарий от h578b1bde

Но мы ведь не пишем на них, правда?

Кто как. Линус Торвальдс в своё время писал прямо в машинных кодах, когда ещё не знал о существовании ассемблера, который сильно облегчил его жизнь. На ассемблере и сегодня пишут, хоть и не очень много, поскольку есть тот же Си.

saahriktu ★★★★★
()

http://php.net/manual/en/ref.mbstring.php Это к тому, что уже писали, т.е. mb_ereg.
В документации есть такое

UTF-8 validity of the pattern is checked since PHP 4.3.5.

а уже если залезть в код, то становится понятно, что если в шаблоне символа нет – получим ошибку. Что является диким трешем, я согласен, ибо считаю, что _не нужно_ было добавлять модификатор /u, если он не может работать как нужно и приходится держать в голове кучу нюансов. В любом случае аналоги есть, поэтому просто забудьте про эти функции если работаете с юникодом.
P.S.: А еще лучше – забудьте PHP.

znenyegvkby
()
Последнее исправление: znenyegvkby (всего исправлений: 1)
Ответ на: комментарий от crutch_master

И получается, что для того, чтобы найти символ в строке делается, допустим, 50к операций вместо 10.

Нет, не получается. Это зависит от степени упоротости и рукожопия создателей абстракции.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от saahriktu

Линус Торвальдс в своё время писал прямо в машинных кодах

И где теперь этот код? В своё время программы на перфокартах писали, это же не повод использовать их сейчас.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

В личном архиве, наверное. Никто же не говорил, что он где-то публиковал тот софт. А если бы и публиковал, то архивы старых бинарников и сегодня живее всех живых, цифровые археологи охотятся и за ними.

Некорректное сравнение, поскольку перфокарта - это носитель информации. И если код влазит на перфокарты, то почему бы их и не использовать. Использовать можно любые носители информации, и те же дискеты 3,5" вполне себе продолжают выпускать и использовать. У меня и USB дисковод для дискет 3,5" есть, а на полке сохранилось 16 3,5" дискет. Другой вопрос, что, если уж затрагивать вопрос абстракций, то нет большой разницы с какими блочными устройствами работать. Хоть с перфокартами, хоть с дискетами, хоть с CD/DVD болванками, хоть с флэшками, хоть с магнитной лентой, хоть с HDD,... - данные везде данные.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от no-such-file

Насколько высокая?

Ну пока еще не знаю, хочется что чем больше тем лучше)

Ноду или го.

А я про .NET думал, вроде неплохо будет?

Deleted
()
Ответ на: комментарий от h578b1bde

Нет, не получается.

Ой, да ну ты брось. 3 либы одна на другой + 2 виртуальных машины сделают своё дело. Плюс к тому, если твоя задача отличается от валидации мыла, то 200 операций вместо 10 - уже большая разница.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)

this problem has name «even you mom handle strings better than your language»

bl ★★★
()
Ответ на: комментарий от saahriktu

И если код влазит на перфокарты, то почему бы их и не использовать

Например потому что это слишком неэффективно.

Некорректное сравнение, поскольку перфокарта - это носитель информации
если уж затрагивать вопрос абстракций, то нет большой разницы с какими блочными устройствами работать

Речь о практической применимости в современных условиях, а не о типе носителей.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от saahriktu

Ну так кто мешает писать компактный машинный код и эффективно помещать его на перфокарты?

Это слишком долго, а значит неэффективно.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Эффективность бывает разная. Всё зависит от того, что нужно. Если скорость работы софта гораздо важнее временных затрат на написание кода, то пишут на ассемблере. А можно и сразу в машинных кодах. Высокоуровневый код неэффективен с точки зрения использования ресурсов, но пишется быстрее, да.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

скорость работы софта

Скорость работы кода с перфокарты будет ниже чем с SSD, каким бы компактным этот код не был.

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

Высокоуровневый код ещё и безопаснее т.к. у человека, пишущего код на высокоуровневом языке, меньше шансов сделать ошибку.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Скорость работы кода с перфокарты будет ниже чем с SSD, каким бы компактным этот код не был.

Можно прочитать в RAM. С современными объёмами это не проблема.

Высокоуровневый код ещё и безопаснее т.к. у человека, пишущего код на высокоуровневом языке, меньше шансов сделать ошибку.

Не факт. В интерпретаторах и компиляторах могут быть ошибки, с которыми пишущий низкоуровневый код мог никогда и не столкнуться. Хорошо то, что GCC качественно тестят, но, всё равно, вероятно, и там есть грабли. Не говоря уж о скомпиленной им лапше. ООП, макросы, алиасы,... Редко кто сегодня пишет качественно на Си, всем чешется перейти на C++ и другие ужасы для экономии своего времени. А потом, конечно, такие нагромождения лишних сущностей качественно распарсить просто невозможно... Да и код самой glibc более чем ужасен... Что уж говорить о следующих уровнях библиотек и абстракций...

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Можно прочитать в RAM. С современными объёмами это не проблема.

Можно, но не нужно.

В интерпретаторах и компиляторах могут быть ошибки, с которыми пишущий низкоуровневый код мог никогда и не столкнуться

Раз в год и палка стреляет, да.

А потом, конечно, такие нагромождения лишних сущностей качественно распарсить просто невозможно...

Переведи код какого-нибудь большого проекта на высокоуровневом языке в сишный и распарси, кто тебе мешает.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

Чтобы что-то перевести нужно знать что переводить, как авторы видели это на уровне обработки отдельных данных, включая отдельные байты и биты. А такого и у самих авторов софта на высокоуровневых ООП языках могло и не быть. Мысли на уровне высокуровневых абстракций, пиши код с высокоуровневыми абстракциями,... А потом оно и непереводимо на более низкий уровень...

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Чтобы что-то перевести нужно знать что переводить, как авторы видели это на уровне обработки отдельных данных, включая отдельные байты и биты. А такого и у самих авторов софта на высокоуровневых ООП языках могло и не быть. Мысли на уровне высокуровневых абстракций, пиши код с высокоуровневыми абстракциями,... А потом оно и непереводимо на более низкий уровень...

Хватит упарываться, оно не на магии работает.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Конечно, не на магии, а на алгоритмах, которые обрабатывают отдельные данные. Только с высокого уровня неизвестно какими и как (да таким разработчикам как Вы это и неинтересно) - это решают компиляторы и интерпретаторы. А на низком уровне это всё определяется руками.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

таким разработчикам как Вы это и неинтересно

Понимать как оно работает и плясать вокруг него с бубном и костылями — разные вещи

h578b1bde ★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.