в контексте тегов не бывает последовательности << либо >>, парсер легко это может отслеживать, и нормальные парсеры так и делают, заменяя такие случаи автоматически. Потому я даже как-то не задумываюсь в таких ситуациях. Вот вам пример, что бы вы меньше «умничали» :)
Ой, молодой человек, негоже врать ;) Вы хотя бы внутрь заглядывали? Тесты писали? Сравнивали? А ведь еще подобные модули, коих валом на CPAN.
Вот вам исходничики, извольте разобраться и протестировать:
cpan.uwinnipeg.ca/htdocs/Net-Patricia/Net/Patricia.pm.html
Посмотрите, какой там оверхед везде, даже на этапе add_string(), не говоря уже про остальное. В функциях использованы те же стандартные функции, например, inet_aton(), применяются те же самые побитовые операции. Но с диким оверхедом.
И в дополнение:
search.cpan.org/search?dist=Net-Netmask
search.cpan.org/search?dist=Net-IP
search.cpan.org/search?dist=Net-IP-Match
search.cpan.org/search?dist=Net-IPv4Addr
search.cpan.org/search?dist=NetAddr-IP
Извините но операция and выполняется за один такт машинного времени. Операции перевода из строки в inet_addr являются posix функциями. На операции одной проверки оно быть не может. Оно может быть быстрее на стадии поиска относительно другой либы, да и то сомнительно.
Проверка вхождения IP адреса в подсеть