Как распарить строку c++?

NooooN, тестируйте на regex101.com, там можно вписать тестовую строку, редактировать регэксп, и он автоматически подсвечивает найденные группы и выводит алгоритм, по которому разбирает выражение.
В вашем случае оно ждет "owner" во вторых скобках, а у вас "ва", или это описка? Пример: cpp.sh/963mm

Как распарить строку c++?

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

Как распарить строку c++?

NooooN, забыл добавить, как хороший инструмент для справки при написании и тестировании регэкспов советую regex101.com

Как распарить строку c++?

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

Какая идеальная страна для айтишника?

Только если все-таки прислушаться к совету про Россию, Украину и Беларусь, то не забыть ознакомиться с 9.5 правилами ведения IT-бизнеса в этих странах:
blog.micromarketing.ru/advice/9-point-5-rules-fot-...

Как перестать кодить и начать программировать?

iamevg_,

Если вам дадут задачу написать новый ЯП, вы скажете что зачем создавать новый, если уже есть 100500 готовых решений?

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

определенно не доросли еще

скорее наоборот, это означает что разработчик уже давно перерос юношеский максимализм и многое повидал в жизни.

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

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

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

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

Есть инженеры, а есть недопрограммисты

Недопрограммистами скорее стоит называть людей с вскукареками "я тут ниасилил XXX и вместо него запилил свой собственный YYY и теперь буду его использовать везде, и пофиг что он ничем не лучше" (единственное исключение - edu-проекты, но там итак все понятно).
Если вам хочется повторно изобретать и реализовывать то, что уже изобретено и реализовано до вас - флаг вам в руки. Мы же, пожалуй, будем заниматься реально новыми и полезными задачами.

Как перестать кодить и начать программировать?

iamevg_,

Стандарт это документ, а style guide это один из многих практик написания кода.

А где шла речь про "стандарт языка"? Речь шла про стандарт написания кода. И логично, что когда его утвердили в вашем проекте (или вы его утвердили сам для себя), он становится "документом" обязательным к исполнению. Термин "coding standard" широко используется именно в этом значении, спросите у гугла, если не верите.
Не говоря уж о том, что "style guide" - это далеко не только "визуальная составляющая". Посмотрите например, MISRA C или стандарт от GNU, или даже Cpp Core Guidlines, упомянутые мною выше, там основная цель - это не просто "красивое форматирование", а именно "однозначность и безопасность" (иногда еще и "переносимость").

К архитектуре и паттернам проектирования, ООП не имеет никакого отношения в общем случае.

Вот это сейчас сильно было.

Как перестать кодить и начать программировать?

iamevg_,

Это где такие стандарты и какого кода?

в зависимости от используемого языка программирования, например:
google.github.io/styleguide/cppguide.html + isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
https://docs.microsoft.com/en-us/dotnet/csharp/pro...
https://google.github.io/styleguide/javaguide.html
https://github.com/airbnb/javascript
https://www.python.org/dev/peps/pep-0008/
Выбрать можно любой по душе, главное чтобы он был (хотя в некоторых проектах стандарт кодирования определяется не только желанием команды, но и требования к надежности ПО, например).
А еще неплохо настроить clang-format/ESLint/StyleCop/etc., чтобы они больно били по рукам при попытке сохранить или закоммитить куда-нибудь код, написанный не по стандарту. В Golang такое, например, "из коробки" является частью языка.

При чем тут вообще ООП?

Правильная архитектура - первый шаг к хорошему коду.
Почитайте про принципы SOLID (про каждый) и про шаблоны проектирования, например.
Еще можно посмотреть на самые частые примеры smelling code (даже хотя бы на Википедии), там тоже довольно много вещей связанных с ООП попадается.

Как перестать кодить и начать программировать?

iamevg_, так-то evgeniy_lm дело говорит.
"Кодинг" - это в общем случае "придумал алгоритм и реализовал его в виде программного кода".
А под "программированием" и "разработкой" обычно понимают гораздо более широкую деятельность, а именно, разработчик кроме непосредственно изобретения алгоритма и переложения его в вид, понятный компилятору, должен еще:
- провести анализ задачи не только в контексте "вот алгоритм чтобы решить проблему", а в масштабах всего продукта, вектора его развития и внешних условий
- придумать/проанализировать use-case'ы и test-case'ы
- подобрать техники оптимизации и best practices используемого языка/фреймворка
- обеспечить возможность внесения изменений в свою часть проекта не требуя серьезной модификации других, и наоборот
- обеспечить пригодность своих модулей/классов/методов к переиспользованию в других частях проекта или возможной замене на другие реализации
- обеспечить пригодность своих модулей/классов/методов для написания к ним автотестов,
... только после этого приступить к придумыванию алгоритма и кодированию....
- сделать код легко читаемым и чтобы он был сходу понятен всем остальным разработчикам, произвести при необходимости рефакторинг других затронутых мест
- написать автотесты
+ и много другое.
И, собственно, по сравнению с фазой "придумать алгоритм и закодить его", фаза "многоуровнево проанализировать задачу, спроектировать программные интерфейсы, тщательно изучить все `точки соприкосновения`, написать документацию, написать тесты" в реальной работе может занять даже гораздо больше времени, и в долгосрочной перспективе будет не менее важной. А после всей проделанной работы, код написать в итоге и макака сможет.
Поэтому "только кодингом" обычно занимаются или новички-говнокодеры (из-за отсутствия опыта), или индусы на фриланс-биржах за копейки (потому что "и так сойдет").