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

[Igors]

С чего это? Никакого "завершающего" (</span>) там уже не будет. Внимательно смотрим код.

Давайте посмотрим

Код

C++ (Qt)
template <class FormatFunc>
QString regex_replace(const QString & input, const QRegExp & regex, FormatFunc format_func)
{
    QString out = input;
    int pos = 0;
    while ((pos = regex.indexIn(out, pos)) != -1)
    {
        auto s = format_func(regex.cap(1));
        out.replace( pos, regex.matchedLength(), s );
	pos += s.length();
    }
    return out;
}

В момент out.replace: pos стоит на первом пробеле для замены (в строке out). Потом Вы добавляете длину строки-замены, в итоге pos стоит на начале хвостика </span>. Что не так?

Адище какое
Находим через регексп текст внутри спана. Только В НАЙДЕННОМ ДИАПАЗОНЕ заменяем пробелы. Повторяем поиск с позиции конца заменененного диапазона.
Профит.

С "идеологией" никто не спорит Вот только как это технически исполнить?

[Racheengel]

QRegExp::indexIn - дает нам начало текста.
QRegExp::matchedLength() - дает нам длину текста.
Полученный текст подвергаем replace, и вставляем его в оригинал.
Зная, на сколько поменялась длина нового текста, сдвигаем оффсет регэкспа и повторяем поиск.
Код писать влом, но по моему, задача примитивная

[GreatSnake]

Потом Вы добавляете длину строки-замены, в итоге pos стоит на начале хвостика </span>. Что не так?

QRegExp::matchedLength() даёт длину всего вхождения, т.е. <span>....</span>, поэтому после замены этого вхождения в out уже не будет.

[m_ax]

Адище какое
Находим через регексп текст внутри спана. Только В НАЙДЕННОМ ДИАПАЗОНЕ заменяем пробелы. Повторяем поиск с позиции конца заменененного диапазона.
Профит.

Вы тоже реплэйсом их заменять предлагаете?)  

Кстатии:

Эх, напишу-ка я файнд-реплейс

Код

C++ (Qt)
...
QString ReplaceBlanks( const QString & src )
{
	QString dst;
	const QString & spaceTxt("�");
	int srcPos = 0;
	TVec vec = CollectPairs(src, "<span", "</span>");
	for (int i = 0; i < vec.size(); ++i) {
		int beg = vec[i].first;
		int end = vec[i].second;
		dst += QStringRef(&src, srcPos, beg - srcPos);
		for (int j = beg; j < end; ++j)
			dst += spaceTxt;
		srcPos = end;
	}
 
	dst += QStringRef(&src, srcPos, src.size() - srcPos);
	return dst;
}
...
 

У Вас ведь тоже dst копируется постоянно:

Код

C++ (Qt)
dst += QStringRef(&src, srcPos, beg - srcPos);
...
dst += spaceTxt;
 

Нехорошо)

[Racheengel]

Адище какое
Находим через регексп текст внутри спана. Только В НАЙДЕННОМ ДИАПАЗОНЕ заменяем пробелы. Повторяем поиск с позиции конца заменененного диапазона.
Профит.

Вы тоже реплэйсом их заменять предлагаете?) 

Думаю, в контексте данной задачи это непринципиально.
Против реплейса я в общем ничего не имею, если это не вредит производительности и пониманию.
Вырезать строку - подменить пробелы - засунуть строку взад, как по мне, будет быстрее, чем по всему тексту шарить.

[m_ax]

Думаю, в контексте данной задачи это непринципиально.

Угу, скажите это пользователям не нового железа с 512 MB ОЗУ на борту и 32-битной архитектурой, которым нужно обрабатывать файлы за 100MB)

[Racheengel]

Думаю, в контексте данной задачи это непринципиально.

Угу, скажите это пользователям не нового железа с 512 MB ОЗУ на борту и 32-битной архитектурой, которым нужно обрабатывать файлы за 100MB)

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

[m_ax]

Думаю, в контексте данной задачи это непринципиально.

Угу, скажите это пользователям не нового железа с 512 MB ОЗУ на борту и 32-битной архитектурой, которым нужно обрабатывать файлы за 100MB)

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

Так,.. и каие альтернативы реализации replace Вы видете? Хотя бы концептуально, в общем?

[Racheengel]

Допустим, исходные данные у нас имеют длину L байт, заменяемый элемент S байт, целевой - R байт.
Тогда максимум памяти, необходимой для результата, составит (L / S) * R.
Далее, (подразумеваем тупой вариант - посимвольное сравнение и замену, без всяких там регистров и перекодировок), достаточно просканировать исходные данные на вхожения заменяемых элементов и побайтово скопировать их в результирующий массив. Т.е. найдено совпадение - пишем замененное значение в результат, не найдено - пишем исходный байт и переходим к следующему и т.д.
Не знаю, что еще тут можно придумать, т.к. задача действительно тривиальная и требует только одного прохода по исходному массиву.
Быстродействие в итоге зависит от реализации сравнения паттернов, но тут тоже задача "в лоб".
Не думаю, что "слабые машины" не потянут такое


 

[Igors]

QRegExp::matchedLength() даёт длину всего вхождения, т.е. <span>....</span>, поэтому после замены этого вхождения в out уже не будет.

Так ведь задача была менять не весь блок <span>....</span>, а только пробелы в нем. Ладно, не суть, но обратите внимание: я все время путаюсь в том "коротком и простом" (дальше некуда) что Вы написали И мои слабые способности - не единственное тому объяснение 

У Вас ведь тоже dst копируется постоянно:

Нет, в большинстве случаев срабатывает пул QString и никаких выделений памяти не происходит. А вот предрассчитывать нужный размер ценой создания QStringList - явный перебор

Так,.. и каие альтернативы реализации replace Вы видете? Хотя бы концептуально, в общем?

Ну чего уж останавливаться на полуслове? Продолжайте, типа "а вот boost::xxx умные люди давно уже все написали!!!". Может и так, но выворачиваться наизнанку с гребаными функторами и операторами как-то не хочется. "Концептуальность" не имеет ничего общего с заучиванием очередного кусочка готового. Вероятно Вы использовали это слово по ошибке (в дусте часто встречается "concept")   

[poru]

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

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

[m_ax]

Допустим, исходные данные у нас имеют длину L байт, заменяемый элемент S байт, целевой - R байт.
Тогда максимум памяти, необходимой для результата, составит (L / S) * R.
Далее, (подразумеваем тупой вариант - посимвольное сравнение и замену, без всяких там регистров и перекодировок), достаточно просканировать исходные данные на вхожения заменяемых элементов и побайтово скопировать их в результирующий массив. Т.е. найдено совпадение - пишем замененное значение в результат, не найдено - пишем исходный байт и переходим к следующему и т.д.
Не знаю, что еще тут можно придумать, т.к. задача действительно тривиальная и требует только одного прохода по исходному массиву.
Быстродействие в итоге зависит от реализации сравнения паттернов, но тут тоже задача "в лоб".
Не думаю, что "слабые машины" не потянут такое

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

А вот предрассчитывать нужный размер ценой создания QStringList - явный перебор

А там QStringList не только для этого нужен. Я же писал, что это даёт мне возможность "на лету" в лямбде обрабатывать более сложные условия/случаи. Вам же для этого придётся писать новые функции..

Ну чего уж останавливаться на полуслове? Продолжайте, типа "а вот boost::xxx умные люди давно уже все написали!!!".

А что в этом плохого? Да, буст это инструмент, гибкий и отлично продуманный. Там можно подсмотреть не мало концептов и решений. И понимание и изучение их гораздо более полезнее для собственного развития, чем написания велосипедов в стиле C с классами. )
 

[Racheengel]

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

Реаллокаций памяти тут в любом случае не избежать. Можно сделать более "хитро" и сначала подсчитать количество всех заменяемых объектов, аллоцировать память за один раз и вторым проходом выполнить замену - но тогда придётся расплачиваться быстродействием. Ну или же сразу выделить огромный буфер, заведомо покрываюший все нужны - но тогда платим памятью

А там QStringList не только для этого нужен. Я же писал, что это даёт мне возможность "на лету" в лямбде обрабатывать более сложные условия/случаи. Вам же для этого придётся писать новые функции..

"Лямбда" - это по сути тоже функия И Вам придется писать новые лямбды, от этого тоже никуда)

Да, буст это инструмент, гибкий и отлично продуманный.  

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

[m_ax]

"Лямбда" - это по сути тоже функия   И Вам придется писать новые лямбды, от этого тоже никуда)

Конечно, только лямбду пишет сам пользователь "на лету" в зависимости от его конкретной задачи. Как правило это будет лёгковесное изменение. Ему не нужно для этого писать заново всю regexp_replace. Тем самым с одной функцией он может решать разные задачи.

Но поскольку это форум по Qt, наверняка народ ожидает решений в стиле Qt...

Я понима, что форум по Qt, но зачем ограничиваться только лишь их ситилем? Всегда полезно обсудить и сравнить несколько различных подходов к решению задачи) Их синтез - двигатель прогресса)  

[Racheengel]

Вот, предположим, я поверил в непогрешимость буста И начал прикручивать regex_replace.
Ок, идем в доку (сюды http://www.boost.org/doc/libs/1_61_0/doc/html/boost/xpressive/regex_replace.html), смотрим...

template<typename OutIter, typename BidiIter, typename Formatter>
  OutIter regex_replace(OutIter out, BidiIter begin, BidiIter end,
                        basic_regex< BidiIter > const & re,
                        Formatter const & format,
                        regex_constants::match_flag_type flags = regex_constants::match_default,
                        unspecified = 0);

Ну ок, итераторы там (хотя на что? что есть входными и выходными параметрами для них? какой тип данных? какие контейнеры? Надо ли мне иметь уже преалоцированный контейнер для результатов или оно "само сделается"?)

Ладно, нашел вариант, который использует Char* str как инпут... Но вопрос, а где тогда output?? Ни примеров, ни описания...

Дальше,  basic_regex - по идее, тут я должен прописать свой РыгЭксп... Упираемся в такое: http://www.boost.org/doc/libs/1_61_0/doc/html/boost/xpressive/basic_regex.html

template<typename InputIter>
  static basic_regex< BidiIter >
  compile(InputIter begin, InputIter end,
          flag_type flags = regex_constants::ECMAScript);

Ок, рыгэксп надо задавать какими-то биде-итераторами... Ни примеров, ни-че-го

Идем дальше, нужен  Formatter const & format, который, судя по мелкому примечанию внизу, будет вызван после каждого поиска:

Otherwise, for each match found, if !(flags & format_no_copy) calls std::copy(m.prefix().first, m.prefix().second, out), and then calls m.format(out, format, flags).

То есть, оно таки берет и тупо копирует кусок памяти (с аллокациями и т.д.), а потом вызывает форматтер... Приехали к тому, что обсуждалось выше
 
Самое веселое - API данного форматера я так и не увидел, покажите...?