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

[m_ax]

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

Ok, покажите, например, какой дожна быть сигнатура алгоритма std::copy? Какие конкретные типы контейнеров она должна принимать?
Думаю после этого примера всё станет на свои места)

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

O____o Т.е. только QString? А если я не хочу прикручивать к моей маленькой консольной програмке Qt? Я работаю с string и wstring. Что мне делать?

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

Так в той теме (по ссылке) как раз-таки и было показано ровно противоположное, а имено костыльность и неуниверсальнось реализации того класса "для ДЕЛА "

Как-то здесь мелькнула удачная фраза типа "если и без какой-то технологии цель легко достигается - то такая технология не очень нужна".

Ну если написание 100500 велосипедов дя разбора 100500 вариантов задач - это легко, то настаивать не вижу смысла) К чёрту регулярки) Хардкор, только хардкор)
   

[Old]

Ну если написание 100500 велосипедов дя разбора 100500 вариантов задач - это легко, то настаивать не вижу смысла) К чёрту регулярки) Хардкор, только хардкор)

m_ax, вы предложите задачу посложней, например разбирать и валидировать номера телефонов, набранных как угодно, а лучше паспортные данные с домашним адресом.
И сразу в теме возникнет тишина.
А если и QString у ребят "заберете", то будет как на картинке.

/* Цифры из строки доставать или простые теги, оно легко велосипедиться, а как что посложней сразу регулярки становятся нужными, а лучше boost.spirit. */

[Racheengel]

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

O____o Т.е. только QString? А если я не хочу прикручивать к моей маленькой консольной програмке Qt? Я работаю с string и wstring. Что мне делать?

Почему "только QString" то??? Разве юникод только QStringом ограничивается?

Я имел в виду другое - Вы же не думаете, что движок регулярок имеет отдельные имплементации для string и отдельно для wstring (хотя, конечно, можно собрать несколько версий одного и того же с разными типами данных, но я правда так не думаю - это был бы ад для тех, кто его разрабатывает). "Внутри" этот движок, скорее всего, юзает 2-байтовое (например) представление всех символов и жёстко оптимизирован на это. А то, что подаётся на вход boost-функции, в первую очередь "переводится" в это 2-байтовое представление, и уже эти данные подаются в движок.

Я к тому - зачем нам иметь лишний слой итераторов, когда можно просто подать, скажем, std::wstring на вход (стандартная же библиотека, все таки). А пользователь, если работает с QString или чем подобным, пусть сам позаботится о конвертации в wstring. В конце концов, регулярки придуманы для работы с текстовыми строками, а не с абстракными контейнерами

Ok, покажите, например, какой дожна быть сигнатура алгоритма std::copy? Какие конкретные типы контейнеров она должна принимать?

У алгоритма std::copy абсолютно иной use case. В отличие от регулярок, он оперирует тупо с последовательностью байт, без разницы, в каком формате входные данные. И копирование не всего контейнера, а только его подмножества - довольно часто встречающаяся задача. Хотя его сигнатура тоже не небезопасна - так, вместо end-итератора, как по мне, было бы более правильно указывать длину последовательности. А выходным параметром, соответственно, кол-во скопированных символов. Как то так, наверное.

[Racheengel]

/* Цифры из строки доставать или простые теги, оно легко велосипедиться, а как что посложней сразу регулярки становятся нужными, а лучше boost.spirit. */

А чем плох кутишный движок регулярок? (все-таки в исходном топике вопрос был про QRegExp)

[Old]

А чем плох кутишный движок регулярок? (все-таки в исходном топике вопрос был про QRegExp)

Ничем. Ну может только не так быстр, как бустовский.

[m_ax]

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

Да не.. Вы что из лесу вышли что-ли? "Букварь" - это пойло для лохов) А  как же творческий подход?)Да и потом собственный велосипед и ближе и дешевле в конечном итоге)

Я имел в виду другое - Вы же не думаете, что движок регулярок имеет отдельные имплементации для string и отдельно для wstring  

   
Нет конечно, в бусте имплементация одна, но её фишка в том, что она может работать и с QChar и с char и с short и т.д..

"Внутри" этот движок, скорее всего, юзает 2-байтовое (например) представление всех символов и жёстко оптимизирован на это.

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

Я к тому - зачем нам иметь лишний слой итераторов, когда можно просто подать, скажем, std::wstring на вход (стандартная же библиотека, все таки).

 
Так пожалуйста, подавайте) Вас же никто не заставляет подавать на вход итераторы) Я вот недавно приводил пример, без всяких итераторов) И не зря там несколько перегрузок функций существует)

У алгоритма std::copy абсолютно иной use case.

Так значит у copy он иной) Хорошо, а в какой, например, алгоритм из stl Вы бы рекомендовали передавать конкретные типы контейнеров/данных?

Хотя его сигнатура тоже не небезопасна - так, вместо end-итератора, как по мне, было бы более правильно указывать длину последовательности.

Т.е. Вы гарантируете, что с длиной последовательности мы скорее всего не ошибёмся (а если мы её заранее не знаем?), или это будет реже, чем, например, если в качестве второго аргумента мы невзначай укажем end от другого контейнера? Это Ваш аргумент?  

[Racheengel]

Так значит у copy он иной) Хорошо, а в какой, например, алгоритм из stl Вы бы рекомендовали передавать конкретные типы контейнеров/данных?

Я больше скажу - copy среди всех остальных алгоритмов - единственное исключение, где использование итераторов оправдано тем, что задача скопировать часть последовательности возникает гораздо чаще, чем задача поиска, скажем, минимума только в части контейнера (иначе copy(a.begin(), a.end(), b.begin()) вырождается в b = a).

Насколько часто Вам лично приходилось передавать в алгоритмы итераторы, отличные от begin() и end()? Только честно
Я полагаю, что это что-то между 99% и 99.9%. То есть мы пишем do_stuff(a.begin(), a.end(), b.begin()) в подавляющем большинстве случаев.
Почему бы не расширить API всех алгоритмов на использование полных контейнеров? Например, до do_stuff(a, b) вместо вышенаписанного.

Кстати, именно по этой причине в c++ появился foreach
В реальности, 90% записей оператора for выглядело как for (i = 0; i < v.size(); ++i)...

Т.е. Вы гарантируете, что с длиной последовательности мы скорее всего не ошибёмся (а если мы её заранее не знаем?), или это будет реже, чем, например, если в качестве второго аргумента мы невзначай укажем end от другого контейнера? Это Ваш аргумент? 

Да. Гарантирую. Тем, что переданная длина, если она превышает реальную, может легко быть ограничена реальной длиной контейнера (length = min(realLength, inputLength), чего не добиться в случае "неправильных" итераторов.

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

[Igors]

Ну если написание 100500 велосипедов дя разбора 100500 вариантов задач - это легко, то настаивать не вижу смысла) К чёрту регулярки) Хардкор, только хардкор)

Ну чего Вы заливаете? Какие 100500? Я лично не могу вспомнить когда последний раз что-то заменял. Судя по тому что Ваша реализация написана прямо сейчас - у Вас то же самое. Не надо суетиться с немедленным обобщением - дождитесь когда пойдет "струя" таких задач, к этому времени уже накопится опыт 2-3 решенных, т.е. Ваше обобщение будет зрелым.

Нет конечно, в бусте имплементация одна, но её фишка в том, что она может работать и с QChar и с char и с short и т.д..

Боже мой, сколько сил, в конце-концов интеллекта бездарно разбазарено на эту "манечку общности" Загадить текст итераторами по самые помидоры, заставить всех изучать эту хренотень, и потом еще ходить с гордым видом "Во, общий!! И с этим работает и с тем, и ВООБЩЕ С ЧЕМ УГОДНО!". Браво!

Только вот почему Qt так не делает? Почему ф-ционал QString никак не распространяется на что-то еще? Хорошо, пусть исключение. Др фреймворк, напр wxWidgets - почему и там то же самое с wxString? Не знаете? Так я Вам скажу почему: потому что умные люди. Потому что понимают что выгодная запись ежедневных операций для программиста куда важнее "улетов в концептуальность".

Ok, покажите, например, какой дожна быть сигнатура алгоритма std::copy?

Да никакой это не "алгоритм", а бессовестная эксплуатация той же "общности". Смотрите - и так можно, и эдак, сработал бы оператор =. Да, мило, забавно, но это экономия 2 строк (чаще одной). А Вы воспринимаете это серьезно.

А для алгоритмов есть раздел на этом форуме. И там очень быстро "наступает тишина" (даже отнимать ничего не надо  ). И куда только деваются обширные познания std и.т.п?  И нужны ли они если никак в работе не помогают?   

[Old]

Загадить текст итераторами по самые помидоры, заставить всех изучать эту хренотень

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

Только вот почему Qt так не делает? Почему ф-ционал QString никак не распространяется на что-то еще? Хорошо, пусть исключение. Др фреймворк, напр wxWidgets - почему и там то же самое с wxString? Не знаете?

Знаем. Потому что это GUI-библиотеки и задачи перед ними стоят другие - создавать GUI.
А вот стандартная библиотека и boost, как раз должны уметь работать как с QString, так и с wxString, или MySuperString. Что бы разработчик независимо от используемых фрейворков мог использовать заложенный в них (в stl и boost) функционал.

А для алгоритмов есть раздел на этом форуме. И там очень быстро "наступает тишина" (даже отнимать ничего не надо  ). И куда только деваются обширные познания std и.т.п?  И нужны ли они если никак в работе не помогают?   

Там наступает тишина совсем по другой причине и она никак не связана с программированием.

[Igors]

Знаем. Потому что это GUI-библиотеки и задачи перед ними стоят другие - создавать GUI.

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

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

А вот стандартная библиотека и boost, как раз должны уметь работать как с QString, так и с wxString, или MySuperString. Что бы разработчик независимо от используемых фрейворков мог использовать заложенный в них (в stl и boost) функционал.

Вот и хорошо, и пусть Андрюша Александреску этим занимается. А нормальному человеку лезть в этот дурдом совершенно незачем. 

[Old]

Ну UI-то здесь причем

Притом, что задачи у них разные. Стандартная библиотека должна уметь работать с разными последовательностями символов (QString/wxString/MySting/string/char*/...), на то она и стандартная. Для Qt и wxWidgets таких задач не стоит, поэтому они пошли простым для себя путем.

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

По разному бывает. Бывает общее решение намного короче и эффективней некоторых частных.

Вот и хорошо, и пусть Андрюша Александреску этим занимается. А нормальному человеку лезть в этот дурдом совершенно незачем. 

Нормальные человеки этим замечательно пользуются, быстро получая эффективные решения.

[m_ax]

Я больше скажу - copy среди всех остальных алгоритмов - единственное исключение, где использование итераторов оправдано тем, что задача скопировать часть последовательности возникает гораздо чаще, чем задача поиска, скажем, минимума только в части контейнера (иначе copy(a.begin(), a.end(), b.begin()) вырождается в b = a).

Насколько часто Вам лично приходилось передавать в алгоритмы итераторы, отличные от begin() и end()? Только честно  
Я полагаю, что это что-то между 99% и 99.9%. То есть мы пишем do_stuff(a.begin(), a.end(), b.begin()) в подавляющем большинстве случаев.
Почему бы не расширить API всех алгоритмов на использование полных контейнеров? Например, до do_stuff(a, b) вместо вышенаписанного.

Ну так расширте, если Вам так удобнее, кто мешает?

Код

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

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

Кстати, именно по этой причине в c++ появился foreach  

foreach это хорошо.. А знаете что он требует от контейнера, чтоб он с ним мог работать?

В реальности, 90% записей оператора for выглядело как for (i = 0; i < v.size(); ++i)...

То что Вы в 90% случаев используете контейнеры с доступом по индексу, совсем не означает что все так пишут) Попробуйте таким for'ом по списку пройтись)

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

Хорошо, пожалуйста, stl даёт Вам возможность:

Код

C++ (Qt)
template <class Container>
void some_algorithm(const Container & c, size_t n = 0)
{
    std::some_algorithm(c.begin(), std::advance(c.begin(), n));
}
 

Только чем это лучше? Только тем, что лично Вам так больше нравится? Но это опять же не аргумент.

[Racheengel]

и пусть Андрюша Александреску этим занимается. А нормальному человеку лезть в этот дурдом совершенно незачем.

Александреску - вообще жирный румынский тролль Написал библотеку с названием Loki (посмотрите, кто это в скандинавской мифологии), а опосля срулил с C++ на D и теперь усиленно троллит в этом направлении

Попробуйте таким for'ом по списку пройтись)

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

foreach это хорошо.. А знаете что он требует от контейнера, чтоб он с ним мог работать?

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

Только чем это лучше?

1. Меньше кода.
2. (следствие 1) Меньше потенциальных ошибок.
3. Лучше понимание и читаемость.
4. Компилятору будет проще оптимизировать доступ к элементам контейнера.

А вот стандартная библиотека и boost, как раз должны уметь работать как с QString, так и с wxString, или MySuperString.

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

Разработчики Qt поступили мудро. QString обеспечивает полноценную конверсию в std::string-и и назад. Тем самым stl освобождается от умения работы со всеми остальными типами строк И так должны поступать все производители сторонних либ, если они хотят иметь совместимость с stl, но не наоборот.


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

[Igors]

Ну так расширте, если Вам так удобнее, кто мешает?

Код

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

STL даёт Вам такую возможность, легко..

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

Хорошо, пожалуйста, stl даёт Вам возможность:

Код

C++ (Qt)
template <class Container>
void some_algorithm(const Container & c, size_t n = 0)
{
    std::some_algorithm(c.begin(), std::advance(c.begin(), n));
}
 

А здесь еще size_t не годится, "все" должно быть отрицательное, поэтому напр ptrdiff_t. И std::advance может оказаться совсем не безобидным (для того же списка). И уважающий себя программист не лепит вызов одной ф-ции дважды.

Что std сделан "не по руке" - это точно. Захочешь воспользоваться хоть тем же сопливым std::find, но как вспомнишь что надо сравниваться с end() (а имя контейнера нормальное) - так ну его нафиг. Или тот же remove_if - извольте помнить что он ведь "только переставляет" и не забыть еще надеть erase, пока такое уродство распишешь...

Qt это тонко прочувствовали и подстелили соломки где надо, приятные мелочи типа QMap::value и др. А ведь чистой воды "велосипед" - но критиков почему-то не слышно  

[m_ax]

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

Т.е. Вы сейчас располагаете статистикой по всем большим конторам?

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

У нас сейчас есть foreach и сейчас это часть языка, в чём проблема? Более того, он может работать с любыми типами контейнеров и с со списком и с вектором и с C массивами и даже с доморощенной реализацией от бабы Вали)   Знаете чем это достигается? Итераторами. Он требует наличия у контейнера методов begin() и end().

1. Меньше кода.

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

2. (следствие 1) Меньше потенциальных ошибок.
3. Лучше понимание и читаемость.

Высосана из пальца)

4. Компилятору будет проще оптимизировать доступ к элементам контейнера.

 
А вот здесь можно по-подробнее? Каким образом компилятору будет проще?)

Так это придется писать для каждого some_algorithm. А если еще лямбда или хвунктор, то и его надо тащить.

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

А здесь еще size_t не годится, "все" должно быть отрицательное, поэтому напр ptrdiff_t.

Это с чего это всё должно быть отрицательно? O__o

И std::advance может оказаться совсем не безобидным (для того же списка).

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

И уважающий себя программист не лепит вызов одной ф-ции дважды.

А где Вы там увидели вызов одной функции дважды?