Проверка наличия IP-адреса в строке.

И правильно делаешь)))
Потому, что это будет шустрее и удобнее)

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

И тут еще все от компа зависит...

 

А если оба одинаково удобны?

вот придёт runcore, подправит регулярку (я не настолько силён в них) и можно закрывать тему, ответов больше чем достаточно набралось, на любой цвет и вкус

 

Массивы могут быть с разными названиями и разной длины.

Например проверка на "1000" элементов с ключами массива и значений "текст и цифры в перемешку" и с выводом на страницу:
$a as $k => $v дало результат 0.00482

А вот:

$a as $k дало результат 0.00584


У меня всегда быстрее 1 вариант, также как и sizeof() быстрее count() если массивы с выше 50.000 элементов.

 

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

Код (Text):

1. (?:^|\D)((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)(?:\D|$)

Perl вон, является лидером по эффективности обработки текстов, а там ВСЕ завязано на регулярки.
так что они МОГУТ работать очень быстро, если уметь их готовить. конечно, это не значит что нужно применять их вообще везде. голову никто не отменял

 

Я так понимаю, это окончательный вариант решения?

Код (PHP):

1.     <?php
2.     $str = "kkk265.355.255.255aaa127.5.3.5sss222.222.33.44skds132.123.1.1w";
3.     $pattern = '#(?:^|\D)((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)(?:\D|$)#';
4.     preg_match_all($pattern, $str, $rows);
5.     foreach ($rows[0] as $row) {
6.             echo $row;
7.     } 

 

да

 

igordata, слишком упрощено. Затраты времени должны сводить к конечной экономической выгоде самого ресурса. Т.е. в расчёт должны браться ещё такие показатели, как трафик сайта, время ожидания пользователя (в том числе индексация поисковыми пауками). Если пользователь вынужден дольше ожидать отклика сайта, то потенциально мы теряем посетителя при условии что существует подобный ресурс (конкурент), но с более быстрой обработкой запросов. Скорости может и маленькие, но все мы сталкивались с этим "мне кажется что-то сайт притормаживает"... Потеря потенциального пользователя для коммерческого проекта не выгодна, да же не сама потеря, а возможность потери как экономической составляющей.

И разговор идёт о конкретном скрипте. В расчёт нужно брать все скрипты проекта, 1000 секунд могут превратиться в реальные задержки. Так же мы не берём в расчёт тот факт, что программист имеет опыт работы, а значит уже знает или потенциально должен знать какой скрипт будет оптимальнее. По этому "20 минут на умный код" он будет тратить единожды.

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

С другой стороны, мы тратим своё время на форуме, а значит оно у нас есть. Мы делимся решениями, значит у нас уже есть практика. И теперь если мне понадобится решить подобную задачу, то я конечно же возьму это уже готовое решение.

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

 

Но ведь 65.22.22.22 - это же ip. Регулярка правльно его нашла в строке. А первая двойка - это просто типо часть строки. Такая же, как и буквы там всякие и прочие символы.

 

это неправильный IP.
А может это окончание предложения: "Я живу в доме 265.07.09.76 это дата моего рождения". Перед "07" просто нет пробела )))))