Как регуляркой найти первую точку в строке?

Question

[moskwin68]

Строка:
Ivanov I.Petrov P. Sidorov S.
Желаемый результат:
Ivanov I.<br>Petrov P. Sidorov S.

Answer 1

[Владимир Куц]

"Ivanov I.Petrov P. Sidorov S.".replace(/\./, '\.<br>')

"Ivanov I.<br>Petrov P. Sidorov S."

Comments

[moskwin68]

Спасибо за ответ, мне бы хотелось подобрать именно регулярное выражение которое ищет первую точку без метода replace, зря поставил тэг javascript

Answer 2

[Дмитрий Беляев]

Зачем нагружать CPU компиляцией и обработкой регулярок, когда все прекрасно работает без них?

function insertAfter(source, search, insert) {
  const p = source.indexOf(search);
  return (p === -1
    ? source.slice()
    : source.slice(0, p + 1).concat(insert, source.slice(p + 1))
  );
}
console.log(insertAfter('Ivanov I.Petrov P. Sidorov S.', '.', '<br>'));
// а еще кроме строк можно и массивы той же функцией обрабатывать
console.log(insertAfter(['Ivanov I', '.', 'Petrov P.', ' Sidorov S.'], '.', '<br>'));

Comments

[Interface]

Зачем нагружать CPU компиляцией и обработкой регулярок

Все таки, когда речь заходит о производительности, я считаю хорошей практикой подкреплять утверждения, что что-то работает быстрее или медленнее какими-то бенчмарками или другими измерениями. Потому как не всегда результат очевиден. Так, например, согласно моему наколеночному бенчмарку (код могу выложить если интересно, но не вижу смысла этого делать), ваша реализация медленнее, чем очевидное решение (которое вдобавок еще и соответствует вопросу) Владимир Куц от 2 до 7 раз.

По итогу:
- производительность ниже
- кода больше
- код сложнее понять
- "а еще кроме строк можно и массивы той же функцией обрабатывать" я бы не стал позиционировать это как преимущество решения

[Дмитрий Беляев]

- производительность ниже

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

- кода больше

странная претензия...

- код сложнее понять

у регулярок? да, регулярки вообще нечитаемое нечто

- "а еще кроме строк можно и массивы той же функцией обрабатывать" я бы не стал позиционировать это как преимущество решения

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

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

Синтетические бенчмарки слабо коррелируют с действительностью. За долгие годы я видел единичные реализации, работавшие корректно, с отключением всех оптимизаций и т.д. Я не большой спец по написанию бенчмарков, чтоб их писать, в своей обычной жизни я привык полагаться на знания, какие алгоритмы работают под капотом, и какая у них сложность в нотациях О-большое и Омега-большое. И этот опыт мне говорит, что линейный поиск - это O(n), а регулярка - O(n log n)

По итогу:
Регулярки - это нечитаемый тормознутый костыль, говорящий о беспомощности разработчика, у которого в момент написания решения или не было времени или не хватало знаний, чтобы написать нормально.