- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
sub check_license {
my ($license) = @_;
my $is_valid = 0;
if (-f $license) {
open(my $fh, '<', $license);
my $content = do { local $/ = undef; <$fh> };
close($fh);
$content =~ s/\r\n/\n/g;
$is_valid = $content =~ /^-{5}BEGIN LICENSE-{5}$/m;
$is_valid = $content =~ /^-{5}END LICENSE-{5}$/m;
}
return $is_valid;
}
Follow us!
Но тут ведь какая фишка?
Во-первых автор не умеет многострочных регулярок (нафига две проверки?)
Во-вторых регулярки тут вообще не нужны: perldoc index!! Не ради экономии нажатий на дефис же он это писал?
В-третьих хороший IDE подсказал бы что переменную переписали не использовав (правда, для перла нет хороших IDE, потому что никто не знает что такое "хорошо" в перле)
В-четвертых почему нет my? Куда use strict смотрит?
В-пятых я вообще не понимаю зачем сейчас писать на перле?
&&= даже.
> В-четвертых почему нет my? Куда use strict смотрит
Четвёртая строчка
Везде бы так лицензии валидировались :)
Кстати, в 5.12 появилась интересная фича:
http://perldoc.perl.org/perlsyn.html#The-Ellipsis-Statement
Честно говоря, они начали просто фигней страдать.
Вместо того что бы работать над прикручиванием какого JIT, они просто feature-creep занимаются.
нет, не так: скорость работы это основная причина почему на перле стали меньше писать?
если бы был джит, то расширилась бы сфера применения.
несколько раз приходилось парсить двоичные данные - на чем перл просто немеряно тормозит. в смысле: для скриптового языка, производительность очень хорошая. но, на то что перлу было нужно 40 минут, С прога сделала за 15 секунд. (Перл, на системе где тестил, около 1М TLV триплетов в секунду обрабатывал. Очень хорошее время для скриптового языка.)
та же петрушка с большими XML.
но в общем случае тормозов инициализации JIT я тоже не хочу.
что я хочу, это нечто типа:
Нативные модуля еще написать надо.
И это как бы сводит на ноль преимущества скрипта по сравнению с С программами.
> Маршалинг нужен?
Маршалинг^WСериализация это всего лишь частный случай. (И откуда вы это кривое слово "маршаллинг" только подцепили? Никто кроме Некрософта сериализацию так не называет.)
Общий паттерн: код делает много мелких операций. В текущем Перле это просто не поддаётся никакой оптимизации.
google://java+marshalling
google://golang+marshalling
> И это как бы сводит на ноль преимущества скрипта по сравнению с С программами.
Одно дело пилить всё приложение на сишке, совсем другое - один изолированный модуль, ворочающий байты.
> google://java+marshalling
которые и есть почти все повально виндозники. QED.
> Одно дело пилить всё приложение на сишке, совсем другое - один изолированный модуль, ворочающий байты.
90% логики приложения на С + 10% бойлерплэйта на перле (как минимум три файла), по-моему опыту слегка хуже чем 100% pure С (один файл).
Если какой-нибудь тупой трансформатор/парвер данных, лучше на крестах/сях написать.
Если какой-нибудь серьёзный комбайн, особенно с генерацией каких-нибудь отчётов и записью в базу - часто проще модуль запилить. Хотя я плавно для тулов переезжаю на Go - шустрый и батарейки ништяшные.
> И это как бы сводит на ноль преимущества скрипта по сравнению с С программами.
Тут или шашечки или ехать.
Но XS (нативные модули) в перле -- та еще наркомания. Вот, на затравку:
http://perldoc.perl.org/perlguts.html
http://perldoc.perl.org/perlxs.html
если нужно просто переписать функцию на С то все относительно просто. (за исключением передачи параметров.)
если нужно больше - то там начинаются огороды, потому что документация и половины случаев не описывает. в добавок, дока подразумевает что ты знаешь внутренности перла.