Как заменить неизвестное заранее число вхождений в QRegExp ?

[Old]

Перегрузка для каждого алгоритма с полным основанием должна быть признана "костылем".

Вот если бы в алгоритм передавался контейнер, и мне приходилось бы для обработки части контейнера копировать этот кусок во временный для передачи в алгоритм, вот это был бы костыль.
А сейчас, как правильно заметил Racheengel, есть маленькое неудобство, что в алгоритмы нельзя передать весь контейнер, и это неудобство легко обходиться как уже не раз показал m_ax.
Сделать из общего частное легко, вот сделать наоборот очень сложно.

Как видите даже городится адаптер чтобы использовать контейнеры (а не итераторы). И это правильно

Это библиотека строковых алгоритмов, в ней передача в качестве параметра строки это естественный шаг. Алгоритмы stl не предназначены для строк, строка в них это скорее частный случай.
И что там стало "правильным"? Как только мне понадобится работать с частью строки, мне все равно придется задавать диапазоны. Что я в открытую укажу итераторами начало и конец последовательности, что спрячу их же в range. Ничего не поменяется, вернемся к тому же самому.

[Racheengel]

Вот, думается мне, что бы было еще более правильным - некая сущность типа "виртуального контейнера". Ну то есть ему можно сказать, кого он виртуализирует, а также с какого по какой элемент. Т.е. некий ContainerView, который существует "над" реальным с нулевым оверхедом...

[Racheengel]

Хм... я, по моему, не предлагал отказываться от range нигде, кроме регэкспов. Я предложил РАСШИРИТЬ API алгоритмов так, чтобы можно было передавать не итераторы, а контейнеры в целостном виде.

Ну так что Вам мешает это сделать? 

Я то могу нагородить адаптеров, это не проблема. Но проблема в другом - что мне приходится городить адаптеры для 90% СЛУЧАЕВ ИСПОЛЬЗОВАНИЯ. А это я считаю неправильным по отношению к пользователям.

Вам первый вариант с итераторами кажется проще и читабельней? Правда?

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

а я ведь намеренно допустил ошибку в своём примере:

std::some_alg1(a.begin(), a.end(), b.begin());
std::some_alg2(b.begin(), d.end(), c.begin());
std::some_alg3(c.begin(), c.end(), d.begin());

И, полагаю, никто её не заметил, включая компилятор
Чего бы не случилось, используй я вариант с контейнерами.

[Old]

Вот, думается мне, что бы было еще более правильным - некая сущность типа "виртуального контейнера". Ну то есть ему можно сказать, кого он виртуализирует, а также с какого по какой элемент. Т.е. некий ContainerView, который существует "над" реальным с нулевым оверхедом...

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

[Old]

И, полагаю, никто её не заметил, включая компилятор

Я заметил. Но в С++ таких ошибок может быть по десять в строке и программа будет замечательно компилироваться и даже работать.

[Racheengel]

И, полагаю, никто её не заметил, включая компилятор

Я заметил. Но в С++ таких ошибок может быть по десять в строке и программа будет замечательно компилироваться и даже работать.

Ну а так хоть на пару проблем будет меньше) Это не может не радовать)

[Igors]

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

При интенсивном использовании любое неудобство становится не маленьким

..и это неудобство легко обходиться как уже не раз показал m_ax.

Я бы не сказал что "легко" Бросается в глаза неестественность этой конструкции. Что мы ищем (на что меняем)? Строку(и) - ну значит их и надо подавать (хоть с template хоть явно). Но мы упорно стремимся к "паре итераторов". Зачем? Из-за мнимой общности. Вот кто-то может и не иметь метода size(), а вот std::distance должно(?) вернуть всегда. Даже если и так - никто не мешал сразу соскочить на итераторы в начале реализации. Зачем надо было калечить вызов?

Вот, думается мне, что бы было еще более правильным - некая сущность типа "виртуального контейнера". Ну то есть ему можно сказать, кого он виртуализирует, а также с какого по какой элемент. Т.е. некий ContainerView, который существует "над" реальным с нулевым оверхедом...

То чем пользуюсь я было охаяно здешними знатоками Ладно, см QStringRef - чистой воды "виртуальный контейнер". В конце-концов сам буст ясно говорит что, по крайней мере в некоторых случаях, итераторы не обеспечивают нужного ф-ционала и надо юзать контейнеры (тут один знаток как-то засомневался ).

Почему все должно быть примитивным "диапазоном" задаваемым парой итераторов - хз. Гораздо естественнее "все может быть контейнером", это по крайней мере элегантно. Вот правда как буст это делает - увы, сходу понять не удалось Ну ничего.

И использование:

Код

C++ (Qt)
std::list<int> src = {1,2,3,4,5,6,7,8,9, 10};
std::vector<int> before = {2,3,4};
std::array<int, 5> after = {-2,-3,-4,-5,-6};
 
auto out = replace(src, make_range(before), make_range(after));
 

Хорошо. Правда не знаю как "только с итераторами" вернуть контейнер, но мой вопрос был не об этом. Но, елы-палы, кому (или на хрена) нужна такая общность? Когда мне приходилось что-то менять в массиве/контейнере int? Не помню. Да, Вы достигли цели и показали что можете менять "что угодно" - признаю. Но с точки зрения практика это достижение, ну, скажем, "невелико". И наоборот, то что Вы считаете "мелкой деталью" (так, немного поменять аргументы) для него очень важно, и Вы бы услышали немало эпитетов в свой адрес - и совсем не лестных 

Мне кажется Вы замкнулись в схоластическом мире (или "мирке") теории и напрасно тратите свое время на абстрактные финтифлюшки. Прикладное программирование (по-простому - решение разнообразных задач) предоставляет гораздо больший простор для фантазии/самовыражения.

[Old]

При интенсивном использовании любое неудобство становится не маленьким

Так исправьте это неудобство - напишите удобные для вас враперы.

Зачем? Из-за мнимой общности.

А в чем ее мнимость? Покажите ее ограничения.

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

Буст ничего не говорит. boost это сборник 100500 библиотек написанных 100500 программистами. Если разработчик одной из них, посчитал, что для работы со строками удобней в качестве параметров передавать именно строки, то это его право. В этом действительно, что-то есть.
Но это вовсе не означает, что это отличная идея для всего остального. Скорее наоборот.

Почему все должно быть примитивным "диапазоном" задаваемым парой итераторов - хз. Гораздо естественнее "все может быть контейнером", это по крайней мере элегантно.

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

Но, елы-палы, кому (или на хрена) нужна такая общность? Когда мне приходилось что-то менять в массиве/контейнере int? Не помню.

А в контейнере точек вам приходилось что-то менять? Так он ничем не отличается от массива интов.

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

Надо такому "практику" подучиться и у него все начнет получаться. Он сам сможет упрощать неудобные для него вещи (а не ждать, что кто-то ему что-то упростит) и эпитеты его будут переадресованы себе.
Не надо сложности каждого практика-недоучки выдавать за всеобщие проблемы. У C++ множество проблем, но итераторы не входят в их число или расположены в самом конце.

Мне кажется Вы замкнулись в схоластическом мире (или "мирке") теории и напрасно тратите свое время на абстрактные финтифлюшки. Прикладное программирование (по-простому - решение разнообразных задач) предоставляет гораздо больший простор для фантазии/самовыражения.

Я чуть выше привел задачу с правилами cron, попробуйте ее решить с помощью "прикладного программирования", а я покажу как я ее решил с помощью абстрактных финтифлюшек. И сравним за сколько вы ее решите и посмотрим на это решение.
У меня это решение используется в "ядре комплекса" и там нет Qt. Но понимая, что без QString эта задача вообще не решиться, то пусть будет QString.

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

[Igors]

Я чуть выше привел задачу с правилами cron, попробуйте ее решить с помощью "прикладного программирования", а я покажу как я ее решил с помощью абстрактных финтифлюшек. И сравним за сколько вы ее решите и посмотрим на это решение.

Судя по тому что Вы привели - там "разборок" на час отсилы. Вот научитесь себя вести корректно - тогда может и покажу как А пока свободен.

[Old]

Судя по тому что Вы привели - там "разборок" на час отсилы. Вот научитесь себя вести корректно - тогда может и покажу как А пока свободен.

Ну другого ответа я и не ожидал.
Оно когда число из строки достать, то вы первый показыватель, а как что сложней, сразу слив. Понимаю, потратить несколько дней что бы отладить свою лапшу тратить не хочеться.
А так да, я свободен. У меня не вызывают проблемы использовать C++, хоть он и не "красавица".

[Racheengel]

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

[Old]

Ну, эти правила действительно достаточно просты

Мне такой срок реализаци (2-3 дня) объявил мой гном, который должен был писать шедулер. В это время, другой гном, просто бы курил.
На это я пойти-ть никак не мог, поэтому отложив пасянчик, за пару часов, вспомнив спирит, я написал шедулер сам.

и там можно обойтись и без регулярок.

Несомненно.

[Igors]

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

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

Note that in general regexps cannot be used to check for balanced brackets or tags.

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

ren a*.gif b*.bmp

Ну думаю, наконец-то освою могучую технологию! Ни фига, выяснилось что здесь регулярка не подходит 

Не, конечно если б подходящие задачи лились бурным потоком - вывчыв бы (куда делся). А так, "раз в неск лет" - точно успею забыть все что учил, смысла нет. Велик выходит и дешевле и быстрее

[Old]

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

Быстрее по сравнению с чем?
За кажущейся простотой задачи разбора, скрывается огромное число проверок, которые нужно реализовать и отладить. И именно это занимает большую часть времени.
Для некоторых задач, проще и быстрее разобраться с регулярками, чем велосипедить свое решение. Не хотите правила cron, давайте другой пример - номера телефонов, что бы они разбирались при любом написании. На сколько дольше их будет делать человек без регулярок, по сравнению с регулярщиком? На недели? Насколько это решение будет расширяемым?

[Igors]

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

Для некоторых да - а для некоторых нет

Не хотите правила cron,

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

давайте другой пример - номера телефонов, что бы они разбирались при любом написании. На сколько дольше их будет делать человек без регулярок, по сравнению с регулярщиком? На недели? Насколько это решение будет расширяемым?

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