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

[Old]

А тратить время на изучение инструмента/технологии которая нужна в году раз - считаю непрофессиональным.

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

И владение молотком еще никому не мешало.

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

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

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

[poru]

Знатный холивар 

Кстати в нашем кружке "умелые руки", как и в некоторых по соседству, крайне не в почете stl, boost и всякого рода templat'ы, если нет на то серьезного обоснования. Не всякий кодер знает или помнит возможности той или иной либы, тех или иных технологий и да же возможностей языка, учитывая, что код должен быть прост и лаконичен. Из дискуссии я в большей степени поддерживаю Racheengel и Igors.

Про регулярки. Применил я их как-то для верификации протокола обмена. Пришел новенький и дали ему что-то там изменить. И как говорил Old, переписать этот кусок кода было быстрее, чем научить новичка регуляркам.  Это опять в пользу первого пункта. Писать надо не для компьютера, а для человека, который будет разбираться в этом коде после тебя (это камушек в огород! буста).

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

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

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

[Old]

Пришел новенький и дали ему что-то там изменить.

Вот это и вызывает большое сожаление.
В 80-х мы старались писать красивый код, использовать новые и интересные подходы, пробовали, по сегодняшним меркам, безумные штуки, экспериментировали...
А сейчас мы вынуждены делать код для средних программистов и надеяться, что завтра его сможет разобрать еще менее квалифицированный "специалист".
Поэтому, раньше были редакторы кода (почти IDE) с подсветкой кода для нескольких языков, умещающийся в 64Кб, а сейчас IDE на 4Гб тупит и требует 8.

[Racheengel]

Пришел новенький и дали ему что-то там изменить.

Вот это и вызывает большое сожаление.

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

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

Но сейчас уже 21 век, а не 70-е годы
Нельзя жить прошлым, надо двигаться вперед. И если технологии застряли в 70-х годах (а API STL и Boost исходят именно оттуда), то это не значит, что их надо тащить в светлое будущее

Поэтому, раньше были редакторы кода (почти IDE) с подсветкой кода для нескольких языков, умещающихся в 64Кб, а сейчас IDE на 4Гб тупит и требует 8.

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

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

[Old]

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

Эта технология сделана для C++. Да, он многословен и тяжел, но лучше пока ничего нет. Точнее есть, но для групповой разработки не подходит.

Но сейчас уже 21 век, а не 70-е годы

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

И если технологии застряли в 70-х годах (а API STL и Boost исходят именно оттуда), то это не значит, что их надо тащить в светлое будущее

Нет, boost и stl моложе Qt.

[Racheengel]

Стандартная библиотека C++ появилась в 1983 году.
Первый релиз Qt: 1995 год.

[Old]

Стандартная библиотека C++ появилась в 1983 году.
Первый релиз Qt: 1995 год.

В 83 году в stl еще ничего не было из "неудобного для вас". Это все появилось гораздо позже.

[Igors]

Но сейчас уже 21 век, а не 70-е годы
Нельзя жить прошлым, надо двигаться вперед. И если технологии застряли в 70-х годах (а API STL и Boost исходят именно оттуда), то это не значит, что их надо тащить в светлое будущее

Да, такие мысли/соображения "витают в воздухе". Не раз видел рекламы новых языков которые хотят показаться в выгодном свете сравнивая себя с плюсами. Мол, в плюсах довольно высокий порог вхождения, а вот мы... Объем написанного на плюсах огромен, поэтому думаю минимум еще лет десять ему ничего не грозит. С др стороны не видно бурного (или хотя бы бодрого) развития, скорее мышиная возня в деталях синтаксиса. Что несколько удручает 

[Racheengel]

Как по мне - самое важное, что появилось в new-C++ - это auto
Остальное - мелочь какая-то... Язык умирает, к сожалению
Хотя да, лет 10-15 проживет, думаю. А "новоявленные языки" типа Rust и прочих Каклинов - сегодня есть, завтра нет.

ЗЫ. Всегда раздражала необходимость добавлять слово template<...> в имплементацию темплейтных методов...
Разве компилятор настолько туп, что не может это сам разрулить

[Igors]

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