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

[Old]

Сама по себе идея foreach прекрасна и должна была появиться вместе с классическим for. То, что каждый реализует его через свою Ж. - это проблема не foreach, а языка, в котором такая конструкция должна быть частью синтаксиса, а не сторонним расширением.

m_ax говорил о том, что такая конструкция стала частью языка, и она как раз требует от контейнеров наличие итераторов для своей работы.

Совсем не должны. Более того - это противоречит самой идее "стандартности".

А в чем вы видите противоречие? Есть алгоритм, который одинаково работает с любыми коллекциями - это стандартность.

А вообще, принципы KISS и Less is more рулят
Как сказал Richard P. Gabriel, "Полнотой можно жертвовать в пользу остальных качеств и обязательно нужно жертвовать, если она мешает простоте."

А никто не против простоты. Для вас это сложно, потому что вы никогда этим не пользовались. Для другого будет сложным QString, для третьего iostream, по этой же причине.
Вот есть задача, разобрать правила cron, с помощью которых удобно задавать моменты времени. За сколько вы сможете реализовать их разбор с контролем правильности? Сколько это будет занимать строк кода? Как сложно это будет в дальнейшем сопровождать?
Я эту задачу решил за пару часов с помощью boost.spirit (и то столько времени потратил, потому что последний раз я пользовался им несколько лет назад). Решение занимает несколько строк кода, структуры для хранения разобранных данных занимают значительно больше.
Несколько строк с правилами разбора - вот это простота.

[Old]

Так это придется писать для каждого some_algorithm.

Ну если вам необходимо такое "упрощение", то конечно придется.

Поэтому обычно это делают макрухой. Помню варианты в тех или иных исходниках, но ни разу не возникло желания так делать.

Это же хорошо.

Что std сделан "не по руке" - это точно.

Да, не по вашей руке. Но это никак не беспокоит оставшейся мир.

[Racheengel]

А в чем вы видите противоречие? Есть алгоритм, который одинаково работает с любыми коллекциями - это стандартность.

А должен работать исключительно с коллекциями, предоставляемыми стандартной библитекой и самим языком.
Не обязана библиотека, работающая с байтами и стандарными строками, поддерживать все виды QString, AtlString, CPupkinString и прочее.
Пусть это будет заботой пупкиных.

А никто не против простоты. Для вас это сложно, потому что вы никогда этим не пользовались. Для другого будет сложным QString, для третьего iostream, по этой же причине.

Пользовался, представьте себе, и не раз. И именно поэтому пишу здесь про недостатки, которые сам заметил.
А если для человека даже QString сложен - то ему уже ничто не поможет, тем более STL.

Вот есть задача, разобрать правила cron, с помощью которых удобно задавать моменты времени. За сколько вы сможете реализовать их разбор с контролем правильности?

Понятия не имею, что такое "правила cron" Поэтому, не зная контекста, судить не могу.

[Igors]

Да ладно, это Вы то мне такое говорите? Вы ж с товарищем Racheengel суровые мужики, что для Вас написать свою небольшую утилити?

Да за этим бы дело не стало, но Вы же сами видите что хороший код здесь не получить, по той простой причине что std на это не рассчитан. А с др стороны ф-ционал не так уж полезен/необходим чтобы "идти на жертвы",

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

QString & QString::replace(const QString & before, const QString & after, Qt::CaseSensitivity cs = Qt::CaseSensitive)

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

[Old]

А должен работать исключительно с коллекциями, предоставляемыми стандартной библитекой и самим языком.

Да почему должен? Может быть 100500 различных контейнеров заточенных под конкретную задачу, а вы меня хотите ограничить коллекциями из stl.

Пользовался, представьте себе, и не раз. И именно поэтому пишу здесь про недостатки, которые сам заметил.

Скажем так, это не недостатки, а неудобства stl лично для вас. Я не считаю ваши неудобства недостатками stl.

Понятия не имею, что такое "правила cron" Поэтому, не зная контекста, судить не могу.

Оно выглядит примерно так:
0 10 */4 1-5 *

и означает, что событие будет происходить в любой день недели, с января по май, каждый четвертый день в 10:00.

Секции разделены пробелами, каждая секция означает (с лево на право):
минуты (0-59)
часы (0-23)
дни (1-31)
месяцы (1-12)
дни недели (0-6)

каждая секция может содержать через запятую:
конкретное значение: 1,4,12
диапазон: 1-12
диапазон с делителем: 0-10/2
звездочку: * - означает все значения
звездочку с делителем: */10

примеры секций:
1,2,3,6-10,12-20/2,25,27
*/12
0-20/4,21-40/2,45

[Racheengel]

Серьёзно? А если мне вдруг будет необходимо передать определённый range?

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

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());

или

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

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

[Old]

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

Пожалуйста.
http://www.boost.org/doc/libs/1_60_0/doc/html/string_algo/usage.html#idm45555128686640

[Old]

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

Я за.

[Igors]

Пожалуйста.
http://www.boost.org/doc/libs/1_60_0/doc/html/string_algo/usage.html#idm45555128686640

Там пишут

Container parameters: Unlike in the STL algorithms, parameters are not specified only in the form of iterators. The STL convention allows for great flexibility, but it has several limitations.

Хмм...  

Да, и вот еще

It is considerably easier to write to_lower(str1), than to_lower(str1.begin(), str1.end()).

И я так считаю 

[Old]

Там пишут

Так и что?
boost песочница для stl, они пробуют разные подходы, разные концепции.
Окажется концепт удобным, возможно попадет в стандарт, нет - останется в boost с попытками его улучшить.

[Old]

И я так считаю 

И я. И Racheengel. И, думаю, m_ax. И еще 100500 программистов...
Но мы, к сожалению (а может радости), не в комитете.

[m_ax]

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

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

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

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

[m_ax]

Да за этим бы дело не стало, но Вы же сами видите что хороший код здесь не получить, по той простой причине что std на это не рассчитан.

Ну это спорно..
Вообще Racheengel сказал чего хочет. Что плохого в этом коде:

Код

C++ (Qt)
template <class Container>
void some_algorithm(const Container & c)
{
    std::some_algorithm(c.begin(), c.end());
}
 

 

[Igors]

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

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

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

Что плохого в этом коде:

Код

C++ (Qt)
template <class Container>
void some_algorithm(const Container & c)
{
    std::some_algorithm(c.begin(), c.end());
}
 

 

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

На всякий случай напомню мое предложение

QString & QString::replace(const QString & before, const QString & after, Qt::CaseSensitivity cs = Qt::CaseSensitive)

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

Не хотите ответить? Ну как хотите, я даже знаю почему И еще разок с удовольствием процитирую буст

Container parameters: Unlike in the STL algorithms, parameters are not specified only in the form of iterators. The STL convention allows for great flexibility, but it has several limitations. It is not possible to stack algorithms together, because a container is passed in two parameters. Therefore it is not possible to use a return value from another algorithm. It is considerably easier to write to_lower(str1), than to_lower(str1.begin(), str1.end()).

The magic of Boost.Range provides a uniform way of handling different string types. If there is a need to pass a pair of iterators, boost::iterator_range can be used to package iterators into a structure with a compatible interface.

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

[m_ax]

На всякий случай напомню мое предложение

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

Пожалуйста:

Код

C++ (Qt)
template <class T>
using range = std::pair<T, T>;
 
template <class T>
range<typename T::const_iterator> make_range(const T & src)
{
    return range<typename T::const_iterator>(std::begin(src), std::end(src));
}
 
template <class T1, class It1, class It2>
T1 replace(const T1 & src, const range<It1> & before, const range<It2> & after)
{
...
}
 

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

Код

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));
 

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