А если не секрет, что послужило уверенностью в знании Си/Си++? Спрашиваю, потому как там масса очень нетривиальных моментов (попробуйте, например, сделать такое: coliru.stacked-crooked.com/a/5e8e0c4f76c7cb1a и понять почему этот код не компилируется (в других компиляторах компилируется, но напечатает CErrorsBased вместо CErrors, что полностью рушит задумку) ). И таких мест - тьма (вот тут есть тестики: www.quizful.net/test - попробуйте пройти базовый - там, правда, есть ошибки, но в целом тесты вроде как работают) Ну и всякие замыкания, функторы, лямбды, умные указатели тоже оптимизма не добавляют.

Юношеский максимализм, несколько неплохих, но простеньких программ на Qt и эффект Да́ннинга — Крю́гера.
Кстати, лямбд и смартпойнтеров в крестах тогда, по-моему, ещё не было...

Понятно. И удалось по Си++ поработать в серьёзной IT-конторе? А то я думаю сменить работу, но, почитав статьи на хабре по Си++, я не уверен, что мой уровень С++ достаточен для серьёзных IT-фирм (я не говорю про микроконтроллеры). Впрочем, на хабре, возможно, либо суперпрофессионалы, либо чистые теоретики.

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

Удалось. Впрочем, японские IT-конторы и серьёзная разработка - понятия слабо совместимые, но тем не менее.
Как показывает практика, в основном там пилят дремучее легаси, а если пишут новое - то ничего из перечисленного вами не используется. И я тоже почти ничего из этого не знаю.
Ну, лямбды кое-где, очень редко. Ну, шаблоны. Простые, те, которые ещё с самого начала были. В общем, никакого С++14, С++17, максимум кое-что из С++11.
Ну, приходится определять именно перемещающий конструктор, чтобы память в железке экономить. Ну, о порядке работы конструктора/деструктора знать. Всё.

>>>stl
Из stl только по мере надобности приходилось таскать контейнеры: вектор там, очередь... Но это осваивается по мере надобности за час.

>>>циклы, основанные на диапазонах
foreach что ли? А что в нём сложного? Он же ещё в VB/VBA был...

>>>паттерны
Паттерны - это отдельный разговор. Их и не зная С++ знать надо.

>>>я не уверен, что мой уровень С++ достаточен для серьёзных IT-фирм
Уверен в вашем уровне должен быть собеседующий вас технарь, я считаю. А себя можно и по книгам подтянуть, и на пет-проекте потренироваться.
Я вот планирую вообще кардинально уйти: на Angular/Vue для фронта и Go для бэка. При том, что в продакшене с ними не работал, только дома.

>>>И я тоже почти ничего из этого не знаю.

Нет, я перечисленное знаю и использовал. Но радости особой не доставило - синтаксис всё более уходит до нечитаемости. Вот очередной пример: habr.com/ru/company/jugru/blog/438260/
Как вам такое?
template<Semiregular T> struct maybe_view : view_interface<maybe_view<T>> { maybe_view() = default; maybe_view(T t) : data_(std::move(t)) { } T const *begin() const noexcept { return data_ ? &*data_ : nullptr; } T const *end() const noexcept { return data_ ? &*data_ + 1 : nullptr; } private: optional<T> data_{}; }; inline constexpr auto for_each = []<Range R, Iterator I = iterator_t<R>, IndirectUnaryInvocable<I> Fun>(R&& r, Fun fun) requires Range<indirect_result_t<Fun, I>> { return std::forward<R>(r) | view::transform(std::move(fun)) | view::join; }; inline constexpr auto yield_if = []<Semiregular T>(bool b, T x) { return b ? maybe_view{std::move(x)} : maybe_view<T>{}; };

Там автор пишет «Быть может, что для кого-то это язык родной, но для меня всё это ощущается как если бы кто-то решил, что Perl излишне читабельный, а Brainfuck — излишне нечитабельный, поэтому давайте целиться между ними. Я программировал в основном на C++ все последние 20 лет. Может быть, я слишком тупой, чтобы во всём этом разобраться, отлично.» Вот я тоже 19 лет на Си++ потратил, но этот синтаксис мне абсолютно не нравится.

>>>Из stl только по мере надобности приходилось таскать контейнеры: вектор там, очередь...

Ну, это не интересно. Вот вкладывать одно в другое и смешивать с библиотекой алгоритмов до нечитаемости, вот это оно. И отдельно vector <bool> в подарок.

>>>foreach что ли? А что в нём сложного?

В нём самом - ничего. Но он есть с Си++ 11. И в stl он тоже есть. Свой. С итераторами.

>>>Паттерны - это отдельный разговор. Их и не зная С++ знать надо.

Вот в Си++ вы какие паттерны применяли и для каких задач? Синглетон, фабрики, адаптер и, возможно, наблюдатель (в MFC так прямо в документ-вид встроен)? Ещё что-то?

>>>Я вот планирую вообще кардинально уйти: на Angular/Vue для фронта и Go для бэка.

Вот этот перекос в Web мне удивителен. Чем он вам всем так нравится? Какие задачи решает?

>>в Си++ вы какие паттерны применяли и для каких задач?
Синглтон, RAII, посредник, MVC, а как без той же стейт-машины смоделировать ну скажем телефонную станцию или умный домофон - я уж и не знаю.

>>Вот этот перекос в Web мне удивителен. Чем он вам всем так нравится? Какие задачи решает?
Во-первых, мне это интересно. Во вторых, перечисленное - не обязательно web. Go - язык общего назначения, а к некоторым железкам web-интерфейсы на чём-то же надо строить? В-третьих, это самый простой способ построить распределённую ИС. Ну и платят хорошо.

Только RAII не паттерн.

>>В-третьих, это самый простой способ построить распределённую ИС.

Которая нужна для чего? Для купи-продай?

>>>как без той же стейт-машины смоделировать ну скажем телефонную станцию

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

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

А вот и узнаю, когда-таки решусь "выйти из зоны комфорта".

Почитал про конечные автоматы, что это и с чем едят. Боже, да это же и есть стейт-машина. Только вокруг определения столько всякого ненужного матана нагорожено, что за деревьями не видно леса Это как теорему Пифагора через дифуры доказывать.
Так что от паттерна не отвертеться

Паттерн Состояние - это вот что такое: cpp-reference.ru/patterns/behavioral-patterns/s... Это способ реализации автомата.
А детерминированный конечный автомат - это просто система с состоянием и графом переходов между ними. Машина Тьюринга и есть детерминированный конечный автомат. Регулярные выражения тоже сводятся к конечному автомату.

Например:
enum STATE { STATE_ONE, STATE_TWO, STATE_THREE }; //функция смены состояния void Push(char a,STATE &state) { if (state==STATE_ONE) { if (a=='1') state=STATE_TWO; if (a=='2') state=STATE_THREE; } if (state==STATE_TWO) { if (a=='2') state=STATE_TWO; if (a=='1') state=STATE_THREE; } if (state==STATE_THREE) { if (a=='2') state=STATE_ONE; if (a=='1') state=STATE_TWO; } } void main(void) { STATE state=STATE_ONE; //подаём на автомат символы Push('1',state); Push('2',state); Push('3',state); }

Nio , я вот хотел спросить : японцы точно совсем не принимают наркотики ? Причина вопроса : www.youtube.com/watch?v=ES_LvdzmKR8&fbclid=IwAR...;. Я не знаю , что нужно употреблять , чтобы так глючило . Это уже даже не трава . . .
P.S . Внимание , шок-контент ! Настоящие японские школьницы !

Shinnosoruda, тю, это вы ещё не видели, как сарариманов глючит.
Вещества здесь хоть и продаются некоторые в свободном доступе (как-нибудь сделаю отдельный пост об этом), но их никто не употребляет: жизнь и так им кажется красочной и удивительной. Сходят с ума от переработок.

nio

Shinnosoruda, тю, это вы ещё не видели, как сарариманов глючит.

Да , вы правы . Этого я ещё не видел . . . Я , в последнее время , увлёкся bakakkoii , вот такие видео смотрю частенько .

Вещества здесь хоть и продаются некоторые в свободном доступе (как-нибудь сделаю отдельный пост об этом)

Да , пожалуйста , сделайте обязательно ! А то вдруг я ещё когда-нибудь в Японию поеду !

жизнь и так им кажется красочной и удивительной.

Лаки бастарды они , вот кто . . .

Кстати, никак не могу понять: вот тут давеча на хабре была статья про страшно примитивнейший 3D-движок уровня вольфа. Набрала оная статья дофига лайков и восторженных комментариев. Так как движок наипростейший и крайне известный, возникает диссонанс с указанным мной выше постом о суперпроффесионалах на хабре. Как такое получается?

Хабражитель хабражителю lupus est.

И как это объясняет?

Ну как же... Восторженный молодняк массово лайкает, миддлы молча заносят в закладки, сениоры читают до половины и закрывают вкладку.

А вот в чём я сильно сомневаюсь, так в таком вот распределении. Чтобы о движке прочесть половину и было не интересно, нужно самому сделать когда-либо свой движок. Вариант когда просто не интересно маловероятен - всё же речь идёт о графике достаточно интересных самих по себе игр, и множество народу мечтало сделать свою такую же (но не сделало - это достаточно непросто ). Так вот, сделанных самодельных проектов 3D движков (особенно с software-рендерингом) весьма немного (и я помню, их даже на "Сборник Хаккера" издавали лет 15 назад отдельным архивом) по отношению к количеству миддлов и сеньёров. Следовательно, ни миддл, ни сеньёр с вероятностью близкой к 90% ничего подобного в своей практике не делали никогда. Тогда, значит, им так же статья будет очень интересна и они так же голосуют за неё положительно.

Понятие "миддл" и тем более "сениор" подразумевает некоторую специализацию, ибо невозможно быть даже миддлом сразу во всём. Следовательно, сениор статью закроет, т.к. она к его специализации не относится и потому неинтересна, а миддл в лучшем случае занесёт в закладки, на будущее. Которое, скорее всего, никогда не наступит.

Ну это моё личное мнение, конечно, могу ошибаться.

А не будет ли такая специализация ну просто очень уж узкой? Фишечка-то в том, что на самом деле написание 3D движков, подобных описанных в статье, достаточно несложное. Но почему-то "не идёт" у большинства. Ну правда, что сложного в текстурировании столбца стенки в wolf-3d? А трассировка лучей по экрану? А в DOOM разбить BSP-деревом лабиринт? А экранный портал в Duke 3D? Элементарщина ведь на самом деле. И всё описано давным-давно (см., например, Шикин, Боресков. "Компьютерная графика. Полигональные модели." - там почти всё есть и на очень простом уровне). Но, повторюсь, "не идёт" у большинства. Отсюда и получаются программисты, поражённые простейшим движком и неспособные почему-то такой написать сами. Которые, замечу, не устают повторять всем остальным "учите алгоритмы!". Я как-то спросил, на кой ляд им сдались эти алгоритмы как самое главное в программе (а понимают под ними набор стандартных алгоритмов на сетках, графах, деревьях, сортировка), где они их применяют и что в моей практике программа из таких алгоритмов не состоит на 99% (если в ней всё же и есть искомый алгоритм, то он там занимает 1% программы, если не меньше)? Получил волну возмущения в ответ и ничего внятного. Все ответы сводились, в общем, к поискам данных. Но разве программа - это бесконечные сортировки, поиск и подобная ерунда? Ну правда, я максимум использовал сортировку (очень нечасто) и обычное BSP дерево (в том же 3D - это один-два раза), хэш-таблицу (один раз - в шахматах, как зобрист-ключи). Алгоритм Дейкстры? Что за решаемая задача такая, что нужно искать минимальное расстояние на графе и вот это будет суть программы? А балансировка дерева как суть программы кому может быть нужна? В моей части Вселенной всё это не применяется - там совсем другие задачи (например, задача управления чем-то или такой обработки данных, где всё это не требуется. Да тот же 3D движок уровня DOOM требует буквально сортировки (для спрайтов) и... всё. Даже BSP дерево не нужно - его отлично заменяет экранный портал.). Или вот ещё: для меня дикость, что человеку не хватает скорости обычного умножения чисел и он реализует его через умножение Карацубы. Я не могу понять, чем занимается у этого человека математический сопроцессор. Жрёт электричество? Оказывается, у оппонента Java. Вот уж не знаю, как она делает умножения, но логично было бы поместить два числа в регистры сопроцессора и вызвать умножение. Видимо, она так не делает. Но тогда зачем использовать java для столь ресурсоёмкой задачи? В общем, ответа на причины такого сильного акцента на стандартных алгоритмах я так и не узнал. Но появилось сильное ощущение, что оппоненты никогда не писали полностью самостоятельно приличных размеров программу и плохо представляют, с чем при этом они столкнутся и на каком месте окажутся алгоритмы в иерархии сложности и проблем при разработке. И вот тут возникает полнейшее непонимание, чем же все эти миддлы, джуниоры и сеньёры занимаются в своей практике?

Ну вот возьмём, например, web. Нужно html, css, Javasсript (а это уже далеко не тот простенький недоязык для скриптов на страничках, каким он когда-то был), TypeScript, jQuery, JS-фреймворки (Angular, Vue, React, тысячи их), упаковщики (webpack, babel, что там ещё?) , php-фреймворки, CMS (Joomla, Kohana, Wordpress, etc), отдельный и непонятный мир Битрикс, рассадник неочевидных и неоднозначных технологий вроде WebRTC, и так далее. А ещё отдельный зоопарк с Node.JS, да Электрон этот (да проклянёт его Дийкстра и сгноит в аду) во все щели ползёт...
И во всём этом зоопарке надо хоть как-то ориентироваться, куда тут ещё 3D-движки? Узкая специализация? Ну-ну.

И в мира Андроида похожий зоопарк, и под Яблоком, наверное, и у джавистов наверняка такое.

Ну так и что? Перечисленное никак не является списком специализации в смысле направлений. В смысле используемого инструментария является. Но 3D движки можно писать да хоть на чём угодно - это не используемый инструментарий. Вот С++ - инструментарий, java инструментарий, фреймворки тоже. А движок на них просто "алгоритм работы с 3D графикой". В этом случае специализация получается куда как узкой.