Розвиток C++ девелопера

Хелло колеги по гільдії

Вирішив трохи відійти від політики, бо від неї вже гіпоталамус пухне і запитати думку щодо кар’єрних перспектив.

Дано:
* Сіньйорний член української ІТ-гільдії з перебуванням в київській агломерації.
* 10 рочків веслання на різних аутсорсних галєрах за сіньйорну зарплату в третьому квартилі.
* На мою суб’єктивну думку, посередні програмерські скіли, які тим не менш дозволили пройти всі інтерв’ю у ФБ і Пошуковику, фейлився на архітектурі.
* Дуже мінімальний досвід з іншими технологіями, окрім плюсів.
* Злегка за 30, норм інгліш та наявні софт-скіли.

Що хочеться:
* Заробляти суттєво більше і робити задачі поцікавіше. Ідеально, аби за це ще й було хоча б якесь визнання і користь хоча б комусь.

І тут цікаво, як цього досягти? Бачу такі можливі сценарії:
1) Архітектор Матриці
Нажаль, архітекторів які б спеціалізувались на плюсах я не бачив. Або їх нема або вони мені не зустрічались, тому що їх катастрофічно мало. Тому цей шлях я не дуже розглядаю.
Є варіант розвиватись в напрямку клауду і фронта, тоді можна замахнутись на архітекторську личку, але це може зайняти роки і результат не гарантований. Хочеться швидше.

2) Панда С++ Кунфу
Стати супер-мега гуру в плюсах, одним з кращих в Україні і потім виступати на конференціях, бути контрактором, писати книжки-статті і монетизувати свої знання...
Теоретично, можна, практично ж займе також роки, а також те, що всієї складності технології ніхто не потребує. Дуже-дуже мало проектів пишуться з використанням всієї сили метапрограмування і супер-складних багатопотокових рішень з неблокуючими структурами даних.
Тому є небезпека витратити купу часу, ресурсів, здоров’я на прокачку, а в результаті лишитись рядовим сініором-лідом з нікому не потрібними знаннями і просто плюсиками на стековерфлов.

3) Псіна з Волл-стріт
Є варіант розвитку в напряму HFT, high frequency trading, чув, що там платять добре. Але знову ж таки, для тих позицій де дісно приємні рейти, треба знати алгоритми(ну це майже є), можливо, матан і теорвер, все це потрібно для написання торгових алгоритмів і хз якої ще дічі, за допомогою якої капіталісти на біржах за секунди примножують свої статки.
Варіант цікавий, але матеріалу по ньому в інтернеті мінімум і хз де цьому взагалі навчатись. Окрім того, таких вакансій в Україні не зустрічав, в основному, це США і Лондон, а туди не так просто виїхати, та ще й із сім’єю, та ще й в епідемію.

4) Офісний планктон
І лишається, по суті чи не єдиний шлях це менеджерський трек.
Тех/Тім Лід — Проджект/Продукт менеджер — Програм/Аккаунт/Сайт менеджер — Делівері директор — СТО.
Позитив такого росту в тому, що відкриваються можливості для прийняття рішень, отримання бонусів і якщо казати про рівень делівері директора і СТО, то це суттєво вищі зарплати ніж просто наймані кодерки.
Негатив у тому, що це роки росту, відмова від кодингу, необхідність в «політичних іграх» і у світчингу на Манагера це просідання в зарплаті.
ХЗ чи це все того вартує.

Також цікавим моментом для мене є те, що описані варіанти майже не залежать від місцеперебування. Що на Борщазі, що у Женеві написаний текст буде актуальним.
Інші причини лишатись/валити вже давно обговорені і не є темою цього топіку, пропоную зосередитись лише на кар’єрному треку.

Що мислить спільнота?

👍НравитсяПонравилось4
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

в світлі проблеми 8К
dou.ua/...​ums/topic/33483/#comments
маю уточнення іде мова про розвиток щоб пробити стелю, чи як?

То обычным веб макакам 8к платят, на C++ фиговые ЗП, так как позиций мало(В Украине).

Та навіть не в Україні плюси дуже просідають порівняно з вебом. Хіба фінтех норм башляє, решта робіт на плюсах суттєво нижче вебу по оплаті.

96k$ nett annual(8к міс.) в українських реаліях по теперішньому курсу і з теперішніми цінами це досить добре, я б навіть сказав, це схоже на те, на чому можна сидіти до условної пенсії і мати повноцінну фінансову свободу.
Само собою, що завжди буде хотітись більшого, але мені видається, що я б на цьому зупинився, як найманий працівник.

нєа,
завжди хочеться більшого,
а за штахетником трава зеленіша...

Що мислить спільнота?

Надеюсь, «плюсы» скатятся в маргин. Где их ниша в современной разработке?

Десктоп — нет. Там браузерные веб-зоопарки и .NET.
Сервер — тоже нет. Там либо всякие пхп-пайтоны/asp/jsp, либо cи.
Мобайл? Пока ещё немного да (благодаря Qt) — но скоро тоже нет.
В эмбеде — «плюсы» даже не появлялись.

А где ещё?

В общем, тупик.

П.С. А Страуструп, тем временем, активно работает над запихиванием всего «буста» (очень посредственный фреймворк, как по мне) в «плюсы» и превращением «плюсов» в недо-шарпы.
Скоро, говорят, рефлекшн встроят. А там и гэрбeдж-коллектор...

фантазер

Это не ответ на простой вопрос: «Где ниша плюсов в современной разработке?»

любой более-менее сложный и перформанс критикал проект пишут на плюсах

Если речь о десктопе — все такие «сложные и перформанс критикал проекты» уже 10 лет переписывают с «плюсов» на C#. Что не критикал — уходит в веб.

Но остался пока автомотив, где Qt.

такое ощущение, что в мире остался только автомотив и десктоп. кстати, на десктопе полно Qt

В тому embedded, що wireless, частіше пишу на C, але доволі часто доводиться працювати і з ПЗ, написаним на C+. Згадане ПЗ функціонує як в операційних системах, базованих на linux (на таких зустрічається також ПЗ, в якому використано сучасний C++), так і в операційних системах реального часу, де C++ використовується без винятків та без стандартної бібліотеки шаблонів.

де C++ використовується без винятків та без стандартної бібліотеки шаблонів.

О! И без наследования/виртуальных функций/полиморфизма. И без всей ахинеи, привнесённой в «плюсовый» стандарт после 2000-го года...

В связи с этим, возникает вопрос — называть ли этот код «плюсовым»? Или это просто «си» (хоть и с классами, вместо структур)?

Так, частенько буває, що в embedded пишуть у стилі «C з класами» навіть там, де система не має жорстких обмежень по пам’яті, які змушують так писати. Але сучасний embedded — це і доволі потужні пристрої, на яких спілкуватися з залізом все-таки зручніше з використанням C++. От там зустрічається і ідейно плюсовий код, з властивостями, які внесені в стандарт не лише після 2000-го року, а й після 2011-го, і після 2017-го.

проблема в тому, що хоча тре С з класами, на собесі тобі будуть виносити мозок новими стандартами, і всякою всячиною, аж до ромбічного наслідування

Наслідування інтерфейсів, як traits в Scala, досить кошерне.

Головне розуміти, що робиш, і для чого. І коли цього робити не треба. Це просто інструмент.

Наслідування інтерфейсів, як traits в Scala, досить кошерне.

Ромбовидное наследование в «плюсах» (т.н. «виртуальный базовый класс») — это не об интерфейсах.

О! И без наследования/виртуальных функций/полиморфизма. И без всей ахинеи, привнесённой в «плюсовый» стандарт после 2000-го года...

Чтобы очередной сишник переизобретал свой очередной уникальный и несовместимый API/ABI в очередной который раз?

несовместимый API/ABI в очередной который раз?

Вроде, у «си» проблем с несовместимостью ABI нет. А «плюсов» — в полный рост.

Вроде, у «си» проблем с несовместимостью ABI нет.

А вы вообще в курсе что такое ABI? Смешно такое читать.

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

тіпа ООП, це щось таке що дуже потрібно і без нього ніяк,
Гошка і Растішка якось без ОПП цвітуть і пахнуть

тіпа ООП, це щось таке що дуже потрібно і без нього ніяк

Никак, 99% софта пишется в ООП парадигме, хачкелисты не в счет.

Гошка і Растішка якось без ОПП цвітуть і пахнуть

В расте ООП есть, а го скоро смутирует в новую джаву и вымрет

там не тру ООП, без ромбічного наслідування,
думаю, Го буде довго мутувати, його фішка в простоті (джава для чайників)
Я би сказав, що Го, це Руст без боров чекера, але з гарбідж колєктором

там не тру ООП, без ромбічного наслідування,

Это просто больше писанины-костылей-багов чтобы его сделать, когда оно потребуется

думаю, Го буде довго мутувати, його фішка в простоті (джава для чайників)

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

libc? Ні, не чув.
msvcrt? Ні, не чув.

Які сішники, така і зрілість.

libc? Ні, не чув.
msvcrt? Ні, не чув.

Які сішники, така і зрілість.

extern «C» ? Не, не слыхал.

А между тем, чтобы обеспечитъ хоть какую-то возможность экспортировать функции из шаред библиотек — «плюсовикам» приходится прибегать к старым-добрым сишным конвенциям, со всеми ихними ограничениям. Т.е. прощайте вируальные вызовы, исключения, RAII, темплиты, итп «плюснутая» хрень — которую даже не смогли экспортировать за пределы библиотек (о какой уж там «бинарной совместимости» этого кода говорить).

И это я ещё не касался вопросов выхода статической «плюсовой» библиотеки (в бинарном виде), за пределы сделавшего библиотеку компилятора/линкера и тулсета.

extern «C» ? Не, не слыхал.

Не позорься. Это названия разных реализаций стандартной сишной библиотеки.

хоть какую-то возможность экспортировать функции из шаред библиотек

Плюсовых в библиотек в жизни не видел, не слышал, не знаешь? Смешно.

И это я ещё не касался вопросов выхода статической «плюсовой» библиотеки (в бинарном виде), за пределы сделавшего библиотеку компилятора/линкера и тулсета.

А в сях как-то иначе?

Плюсовых в библиотек в жизни не видел, не слышал, не знаешь?

Видел. Говнецо, в бинарном виде не совместимое ни с чем — кроме самой себя.

А для того, чтобы хоть как-то экспортировать «плюснутое» из шаред библиотеки — приходится пользовать extern «C». При этом, полностью кастрировав все «плюсовые» фичи.

Такая вот «бинарная совместимость». :)

Не чувак, у терминов есть определения и не стоит придумывать свои новые.

чтобы хоть как-то экспортировать «плюснутое» из шаред библиотеки — приходится пользовать extern «C». При этом, полностью кастрировав все «плюсовые» фичи.

Поясни детальніше плз.

Мопед не мой:

www.open-std.org/...​ocs/papers/2014/n4028.pdf

Problem
A C++ developer cannot compile C++ code and share the object file with other C++ developers on the same platform and know that the result will compile and link correctly. Our status quo is that two source files a.cpp and b.cpp can only be linked together if they are compiled with both:
* the same version of the same compiler, or another compiler with a compatibility mode; and
* compatible switch settings, since most C++ compilers offer incompatible switch settings where even compiling two files with the same version of the same compiler will not link successfully.

This is a longstanding source of problems, including but not limited to:
* It creates common FAQs, such as: „Why can’t I link object files created using two compilers?” „Why can’t I link object files created using different versions of the same compiler?” „Why can’t I use std::string in my public function signature?” „Why can’t I link two object files compiled with identical switch settings but different versions of the same compiler, just because both use
(different versions of) the compiler vendor’s own in-the-box std:: library?”
* It makes sharing binary C++ libraries more difficult: To ship a C++ library in binary form for a given platform requires building it with possibly dozens of popular combinations of switch settings for the popular compiler(s) on that platform, and then may not cover all combinations. Alternatively, one can wrap the library in that platform’s stable C ABI, which brings us to...
* It is a valid reason to use C: This is (the) one area where C is superior to C++. Among programs and programmers who would otherwise use C++, the top reason to use C appears to be the inability to publish an API with a stable binary ABI, including that it can be linked to from C, C++, and other languages’ foreign function interfaces (FFIs) such as Java JNI and .NET PInvoke. In particular...
* It therefore creates ongoing security problems: The fact that C is the only de facto ABI-stable lingua franca continues to encourage type- and memory-unsafe C APIs that traffick in things like errorprone pointer/length pairs instead of more strongly typed and still highly efficient abstractions, including but not limited to std::string or the new string_view.
* It is a perennial area for vendor-specific workarounds: The development of technologies like COM and CORBA were largely motivated by the desire to use abstractions like classes and virtual functions in an ABI-stable API.

Finally, it is deeply ironic that C++ actually has always supported a way to publish an API with a stable binary ABI—by resorting to the C subset of C++ via extern „C”. We can and must do better.

Как я понимаю, более менее надежный работающий способ шарить C++ код в виде библиотеки, не даунгрейдя API до уровня совместимости с C, — распространять исходные коды библиотеки и ее потребители буду собирать свои приложения вместе с этой библиотекой.

Це зрозуміло, я не второпав як до цього shared libraries та extern «C» ліпляться.

более менее надежный работающий способ шарить C++ код в виде библиотеки, не даунгрейдя API до уровня совместимости с C, — распространять исходные коды библиотеки

Можна так, але зараз вже є різні пакетні менеджери... Хоча це проблему вирішує лише частково.

Тут ще проблеми додає різний набір фіч компіляторів (оптимізації, вирівнювання, asm/__asm__/you-name-it). Це з одного боку плата за можливість оптимізувати що завгодно і як завгодно, а з іншого — необхідність підтримувати сумісність зі старими версіями С++ та С.

Тут проблема в том, что плюсатики любят код в хедерах писать. И когда ты используешь либу, скомпилённую с одними опциями и хедеры с другим — можешь выгрести кучу проблем. Например, aligned alloc, когда либа возвращает поинтер, а ты её в основном коде (в деструкторе в хедерах) убиваешь и по факту вызываешь delete[] для другого хипа.

любят код в хедерах писать

Це іноді єдиний можливий спосіб (шаблони чи інлайни).

используешь либу, скомпилённую с одними опциями и хедеры с другим

Тут знову все зводиться до не сумісності результатів між компіляторами чи навіть одним і тим же компіляторам, але з різними ключами. ІМО це проблема, але вона за межами мови.

Как я понимаю, более менее надежный работающий способ шарить C++ код в виде библиотеки, не даунгрейдя API до уровня совместимости с C, — распространять исходные коды библиотеки и ее потребители буду собирать свои приложения вместе с этой библиотекой.

Да, оборачиваешь либу в pure С интерфейс и все проблемы исчезают.

Да, оборачиваешь либу в pure С интерфейс и все проблемы исчезают.

А пробовал ли ты гэстример на винде? Не фига они не пропадают

Свят, свят, свят. Эти оригиналы с их закатыванием солнышка ручками в стиле создания ООП с полноценной виртуальностью идут лесом.
Моя расценка за прикосновение в гэстримеру — от 10000$ в месяц чистыми (половина уйдет после на лечение психики).

В нас використовується одна комерційна бібліотека в бінарнику.

Над її API на С у вихідних текстах постачається обгортка з класами на С++, які вже компілюються під кожну клієнтську платформу.

Ну и пример, при использовании extern «C» у вас перестают работать исключения С++, более того, нужно убедиться что вы не бросаете исключения, иначе будет undefined behavior

yosefk.com/...​ fqa/mixing.html#fqa-32.6

Это пример «фичи», которую прийдется «кастрировать».

Було б дивно очікувати, що С+±код використовується в С-стилі, але все ще має усі С++ фічі. Точно так само коли імпортуєш С-код в ньому С+±фічі не працюють.

І я не сперечаюся, я лише говорю про те, що мені не дуже проблема зрозуміла. В С++ не було цілі мати бінарну сумісність для усіх компіляторів, платформ та їх комбінацій. І С+±проекти не збираються різними компіляторами як правило. Тому проблема дещо надумана ІМО.

Якщо ж таки є необхідність робити cross-language сумісніть між бінарниками в межах платформи то треба або все до С зводити, або використовувати якийсь механізм як посередник (той же СОМ у вінді).

В С++ не було цілі мати бінарну сумісність для усіх компіляторів, платформ та їх комбінацій.

И это очень плохо. Достаточно было добавить в стандарт с++ раздел по бинарной совместимости.

І С+±проекти не збираються різними компіляторами як правило.

Какие ж вы тут молодые все. Не пришлось скрещивать cl и bcc. А я когда-то скрещивал, причем проект юзался на всех фабах в мире. Ох и танцы там с бубном были.

Достаточно было добавить в стандарт с++ раздел по бинарной совместимости.

Вот так просто. :)

И почему не добавили, как думаешь?

Достаточно было добавить в стандарт с++ раздел по бинарной совместимости.

Це пропозиція рівня «достатньо було додати в С++ стандарт вимогу, щоб у програмах не було багів».

xlC_R

А мені тут вище про сумісність розказують.

char signed чи unsigned? ;)

І це ще про long ми не починали.

Добре що про __far і __near вже всі забули.

Добре що про __far і __near вже всі забули.

Моделі памʼяті відродились у 64-бітних середовищах, погугліть по -mcmodel= в GCC для x86-64(!), AArch64, RISC-V, SPARC...
Але використовувати їх приходиться тим 0.001% у яких код не влізає в 2GB.

І це ще про long ми не починали.

Проблеми Microsoft зараз шерифа не хвилюють (у них самих long = 64 bit в .NET).

Моделі памʼяті відродились у 64-бітних середовищах

Но было же.

Проблеми Microsoft зараз шерифа не хвилюють (у них самих long = 64 bit в .NET).

Навряд чи це можна назвати проблемами. Тим більше, якогось конкретного компілятора. Звичайний implementation-defined behavior.
Про розміри вбудованих цілочисельних типів стандарт гарантує лише їх співвідношення: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). Ну і що sizeof(char) == sizeof(unsigned char) == sizeof(signed char) == 1.
На все інше розраховувати просто не можна, якщо пишеш код, який планується переносити між великою кількістю «екзотичних» платформ.

Ну й тип long потрібно забанити, якщо планується портабельність між віндою та лінухом, навіть коли йде мова про звичайний x64.

Ну и пример, при использовании extern «C» у вас перестают работать исключения С++, более того, нужно убедиться что вы не бросаете исключения, иначе будет undefined behavior

Во-первых, extern «C» нужен в плюсовом коде для связывания с сишным, а не наоборот.
Во-вторых, сфигали там будет UB?

yosefk.com

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

Во-первых, extern «C» нужен в плюсовом коде для связывания с сишным, а не наоборот.

Местные «спецы» просто не в курсе манглинга и передачи параметров в функции. Логично, ни жабаскрипт, ни питон, ни гоу, ни раст подобных знаний не требуют.

Местные «спецы» просто не в курсе манглинга и передачи параметров в функции. Логично, ни жабаскрипт, ни питон, ни гоу, ни раст подобных знаний не требуют.

extern «C» это больше, чем просто манглинг или очерёдность параметров. Но жабаскриптерам то неведомо. :)

Ну и пример, при использовании extern «C» у вас перестают работать исключения С++,

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

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

Бросить-то ты можешь. «плюсовый» компилятор такое не запретит.

Но бросок этот из шаред библиотеки — не закончится ничем хорошим. :)

Просто твой аппка упокоится, насколько сможет ее упокоить ось.

Просто твой аппка упокоится, насколько сможет ее упокоить ось.

Это да. Но ты-то хочешъ обработать этот эксепшн в своей программе — и сделать что-то разумное, чистое, светлое?

А вместо этого, твою программу успокоит ОС. :)

Как ты можешь обработать то, чего у тебя нет???

Как ты можешь обработать то, чего у тебя нет???

В смысле? Ты кидаешь эксепшн из шаред либы — пытаешься его ловить в пользовательском коде.

Но вместо этого, всю твою программу успокаивает ОС. :)

Вот тебе аналогия. Ты кидаешь кусок говна из форточки и пытаешься его ловить в другой квартире, закрыв окна и фоточки.
Результат — разбитое или грязное окно, если долетит и с большой вероятность придут к тебе менты и успокоят, чтобы говном не кидался.
Эта аналогии идеально описывает твою проблему.

Но вместо этого, всю твою программу успокаивает ОС. :)

Чтобы говном не кидалась.

З.Ы. Впечатляет то, насколько ты не понимаешь, что пишешь.

Эта аналогии идеально описывает твою проблему.

У меня нет никаких проблем. Я минимизирую использование «плюсов» и не использую их при написании библиотек вовсе.
А уж эксепшены — свят-свят-свят. :)

Но я вижу явные проблемы у тебя, с непониманием применимости «плюсовых» фич в принципе, и в библиотеках в частности.

Ловиш сигнал і обробляєш. Воно ж все закінчується в abort().

На віндах SEH.

Но бросок этот из шаред библиотеки — не закончится ничем хорошим

У ниасиляторов все всегда плохо почему-то

У ниасиляторов все всегда плохо почему-то

В твоих комментах — массовое присутствие Даннинга-Крюгера.

Даннинга-Крюгера

Тебя опять в википедию отправить просвящаться?

Ну и пример, при использовании extern «C» у вас перестают работать исключения С++

Исключения перестают работать, если либа собрана Intel C/C++ а ты ещё подлинковываешь в gcc :D

есть четкие правила нейм манглинга для плюсов, не надо пороть чушь

есть четкие правила нейм манглинга для плюсов, не надо пороть чушь

Различный нэйм-манглинг при экспорте — есть и для сишного кода. Я вообще не об этом.

А еще правила передачи параметров в функции — а вот тут еще тот зоопарк.
Ой помню, cl и bcc согласовал по манглингу и передаче параметров, но оказалось, что vtbl у них немного разные.

для динамичеких библиотек вроде есть правила использовать определенный calling convention

Ну-ну, главное верить. Это было в конце 90-х, больше с такими извращениями я не сталкивался.

Ну-ну, главное верить. Это было в конце 90-х, больше с такими извращениями я не сталкивался.

Ты с 90-х не сталкивался с «extern „C“ » ? :)

calling convention прописан в хидере. кстати,как с этим в модулях, не очень понятно

Но вот у bcc когда совпадал calling convention с cl, то не совпадал манглинг. Нужно было еще задать манглинг.

Там, далеко или в котле или на облачке.

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

Получается, что этот сишник незрелый )

Да какой-нибудь тестер вычитывает в инете сложности Си С++ и сюда копипастит, не понимая, что копипастит.

Получается, что этот сишник незрелый )

Скорее, аудитория собраласъ недозрелая, ни в «сях», ни в «плюсах.» Я ведь пишу элементарные общеизвестные вещи — а это для людей откровения и вызывает полыхания. :)

Ок, разжую совсем мелко. Что предусматривает АБИ-стандарт? Компилируешь код в бинарный вид — и используешь его везде, где этот стандарт поддерживается. И тут оказывается, что с «сишным» кодом такое неплохо работает даже в виде статических библиотек (херь, скомпилированная на древнем gcc под тот же Линукс 15-тилетней давности — будет вполне себе работоспособная на последней Убунте). А для «плюсового кода» — такое не работает даже в виде шаред библиотек.

Такая вот разница в АБИ.

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

В рамках стандарта gcc поддерживается. В рамках стандарта icc поддерживается. В рамках стандарта cl — у мелкомягких всегда было всё, как бох на душу положит.

В рамках стандарта gcc поддерживается.

Для сишного кода — да. Для «плюсового» — нет.

И с прочими компиляторами, примерно то же (для мелкомягких компиляторов тоже).

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

«Зрелый сишник» не знает, что исключения C++ работают и в C (мы успешно пробрасываем их из C++ библиотек в C++ main-и-вокруг через C прослойку и даже делаем зачистки).

выхода статической «плюсовой» библиотеки (в бинарном виде), за пределы сделавшего библиотеку компилятора/линкера и тулсета.

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

мы успешно пробрасываем их из C++ библиотек в C++ main-и-вокруг

Эта «успешностъ» — до поры до времени. Пока не разойдутся версии компилятора/тулсета, которым билдилась библиотека и то что вокруг. Или пока не придётся портировать это под другую платформу с другим копилятором — где всему концепту настанут вилы.

Пока не разойдутся версии компилятора/тулсета, которым билдилась библиотека и то что вокруг.

Конкретные факторы, которые будут меняться — на бочку.

Пока что с 2000 года было два таких изменения, одно крупное, другое не очень, и оба анонсировались буквами 99-го размера.

Или пока не придётся портировать это под другую платформу с другим копилятором — где всему концепту настанут вилы.

Винда не планируется, а с разумными людьми обычно проблем нет.

Cross-platform + embedded

В кросс-платформе — портабельностъ «плюсов» невелика. В эмбеде — отстутствует.

А вот здесь ты полностью ошибаешься.

А вот здесь ты полностью ошибаешься.

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

А в эмбедде, редко где вообще «плюсовый» компилятор встретишь. Или если yж встретишь — это будут совсем иные «плюсы» чем те, к которым ты привык.

какую-нибудь реализацию

Так не надо «какую-нибудь», нужно брать версию из компилятора

А в эмбедде, редко где вообще «плюсовый» компилятор встретишь

Эмбеддед — это не только AVR, лол

Так у мобильщиков главное вкорячить. Со всеми компиляторами с и с++ идут стандартные либы. Зачем они туда что-то еще вкорячивают я хз.

Со всеми компиляторами с и с++ идут стандартные либы.

стл часто не идёт.

Где не идет?

На мобайле. Андроид, Айос — там есть плюсовый компилятор, но СТЛ приходится тянуть и компайлить отдельно.

А зачем СТЛ отдельно, если всё хорошее от туда в libc++ ?

Ржунимагу, обычно когда говорят STL подразумевают C++ Standard Library, а не ту самую STL (она еще жива кстати?)

Этот комментарий выглядел как отсылочка на мою джуновскую тему с глупым вопросом «не считается ли называние стандартной библиотеки плюсов ’STL’ безграмотным?», созданную здесь на ДОУ 6 лет назад, которая вызвала кучу полыханий и где я в том числе с Майком срался :)

Этот комментарий выглядел как отсылочка на мою джуновскую тему с глупым вопросом «не считается ли называние стандартной библиотеки плюсов ’STL’ безграмотным?», созданную здесь на ДОУ 6 лет назад, которая вызвала кучу полыханий и где я в том числе с Майком срался :)

Похоже, STL уже действительно поглотили и практически полностью включили в C++ Standard Library. Так что сейчас отдельный STL, вероятно, неактуален.

6 лет назад ситуация была иной.

6 лет назад было практически то же самое. В 99% случаев, когда говорили «STL», подразумевали именно стандартную библиотеку плюсов.
Тот самый STL Степанова практически перестал быть актуальным после первой стандартизации C++ в 98 году. За исключением отдельных типов вроде хеш-таблиц, которых, действительно, в стандартную библиотеку C++ изначально не завезли и добавили только в 11 году.

Наркоман штоле: developer.android.com/...​k/guides/cpp-support#libc ???

Эээ, стоооп, т.е. для тебя STL и C++ Standard Library — это две абсолютно независимые вещи?

не идет по разным причинам. одна из основных — эксепшены, которые очень дорого обходятся на ембеддед

Дорого, но не очень. У нас проектик ASIL-B и все на ексепшенах, и даже мягкий реалтайм соблюден. Правда наши ексепшены выбрасываются один раз — поймано исключение — safe state сразу же.

не идет по разным причинам. одна из основных — эксепшены, которые очень дорого обходятся на ембеддед

Есть куча разных реализаций СТЛ — и даже примитивную мелкомягкую реализацию можно скомпилировать, с полным вырезанием эксепшенов (для этого есть флажок).

Но не идёт, т.к. нафига? Для «плюсов» формально есть стандарты (которые каждые 2-3 года «апгрэйдит» неуёмный Страуструп) — но производители компиляторов не заморачиваются тем, чтобы все эти финдиплюшки из новейших стандартов реализовывать. По многим разным причинам.

Поэтому, в мобайле «плюсовые» компиляторы/тулсеты идут без стл (несмотря на то, что она в стандарте уже хрен знает сколько лет) . А в эмбеде идут без эксепшенов и наследования. Если вообще идут...

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

А в реальности MSVC забил на апдейты сишного стандарта и держит его где-то на уровне C89 (не бойсь еще до рождения нашего сишника)

А в реальности MSVC забил на апдейты сишного стандарта и держит его где-то на уровне C89 (не бойсь еще до рождения нашего сишника)

devblogs.microsoft.com/...​support-arriving-in-msvc

«C11 and C17 Standard Support Arriving in MSVC»

Как переводится слово «Arriving»? Как переводится слово «Preview»?

Как переводится слово «Arriving»? Как переводится слово «Preview»?

Вижуал Студио 2019 — уже вполне себе зарелизен.

Если твой производитель платформы позаботился, то при использовании опции компиляции -fno-exceptions будет подлинкована либа без эксепшенов.

А в эмбеде идут без ... наследования.

до слез

до слез

Зачем в эмбеде наследование, если нет виртуальных вызовов/полиморфизма?

зачем плюсы, если нет наследования?

зачем плюсы, если нет наследования?

В основном, ради инкапсуляции переменных/методов в виде классов. Всё же это удобнее, чем структуры + указатели на функции.

В остальном да, незачем. От того же наследования — больше проблем, чем пользы. Особенно в «умелых ручонках» 23-хлетних архитектов.

От того же наследования — больше проблем, чем пользы. Особенно в «умелых ручонках» 23-хлетних архитектов.

Для цього цілий Go запиляли.

Для «плюсов» формально есть стандарты (которые каждые 2-3 года «апгрэйдит» неуёмный Страуструп)

Не Страуструп, а комітет. Пропозиції може подавати хто завгодно, їх розглядають, допрацьовують та голосують.

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

en.cppreference.com/...​w/cpp/compiler_support/20

На STM32 плюси давно, і все працює.

На чомусь 8- чи 16-бітному може ні.

плюси є, але приплюснуті так пишуть, як на десктопі з 4ГБ ОЗУ, плавали, знаєм.... а ще кастрований uclib++
а ще білдери строк через стріми,

гагага

А в чем проблема, если влазит и по скорости и по потреблению электричества в требования вкладывается?

так справа в тому, що «не лізе» і простіше переписати з нуля на С, чим рихтувати С++ «подєліє», а потім ще полюбити і подружити із «стандартною ++ бібліотекою, яка не STL»

вопшем, учісь, студєнт:
indrekis2.blogspot.com/...​-arm-gcc-stm32-coide.html

И почему у меня всегда всё лезло.

Які стрінги на контролері?

Правовірні CAN і SPI, і трохи матану різного

це допотопний ембедед,
зараз protobuf, std::stringstream + екзепшени

вошпшем концеп такий, шоп передати MTU байт пакетуєм протобафом стрінги, закриптовані приватним ключем, ще сіль та нонс, і куяк-куяк, і в продакшен для такого одного об"єкта тре 60К RAM на кучі

і без ООП \ ООД код цей не їде

Правовірні CAN і SPI, і трохи матану різного

висновок такий, що ти десь застряв на лов-левел рівні, і не шариш в тємі нових бест-веб-практик в імбідед зістемз

з.і.
Учи webasm ^_^

Якщо не вийде з ІРО, то в тюрмі буду вчити Rust + WASM.

Головне, щоб був доступ до DOU.

std::stringstream + екзепшени

В этом ничего плохого нет. если программист еще помнит, как головой по назначению пользоваться.

protobuf

А это модная молодежная фича у смузихлебов — согласен, еще то убожество.

А это модная молодежная фича у смузихлебов — согласен, еще то убожество

на самом деле самый эффективный сериалайзер. хоть и геморный местами

С вечными глюками и багами с нарушениями обратной совместимости и подобным. Но это же модно и молодежно нынче пользоваться таким, тем более сам ГУГОЛ его лепит.

И вот не расскажешь про его самую эффективность. В чем она заключается хоть эта самая?

З.Ы. Тянуть его в эмбедед, не пофиксив сначала — ну да, модно и молодежно. Лично я его избегаю по возможности, посталкивавшись с ним несколько раз.

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

И вот не расскажешь про его самую эффективность. В чем она заключается хоть эта самая?

минимальный оверхед

Минимальный оверхед — это послать просто набор байтов одной сишной функцией, что есть в С или С++ уже.

ну так протобуф по твоему что? синтаксический сахар над

послать просто набор байтов

вот это сахар на поверку оказывается совсем не сахаром.

Але все починається з людей, з цим згідний.

Людина, яка нормально пише на Verilog i VHDL, і на C, буде нормально писати і на плюсах.

писати то буде, тільки в якій С++ парадигмі (їх там 5, а може і більше)?

В парадигмі STM32 Software Development Kit.

Нульова заповідь — не робити хуйні.

С учетом, что почти все переехали на армы, и GCC используют в куче мест, если не в большинстве. То да, конечно, совсем иные.

В Objective C тоже когда-то коллектора не было.

. Где их ниша в современной разработке?

Аутозар аутомотіу,
геймдев,
HFT (швидкобототрейдінг)

В автомотиве, лишь по инерции и благодаря Qt.

В геймдеве весь openGL/движок — как правило на «ванилла си». На «плюсах» может обвязка к джойстику/мышке/клаве/музыке — коей менее 5% кода.

та нє, там Аутозар Аудаптів, сказав, що усьо, С це старьой для Аутозар клазік,
і написали свій Аутоазар С++14 с блекджеком і промісами

і написали свій Аутоазар С++14 с блекджеком і промісами

Ок, это безумные немцы-нищеброды, выделили своих корпоративных «эксперов 60к/год» и посадили их писать спецификацию. Хорошо хоть, не на Джаве соорудили.:)

написати «свій» месидж брокер, це тобі не козульки в носі колупати

Похоже, им на это понадобилось почти 20 лет. :)

Два-три місяці одного програміста, і три роки на вилизування.

Написали таких два з половиною, досі живуть в продакшині.

Про наш самопал на різних проєктах у різні роки.

Варіації pub/sub.

В геймдеве весь openGL/движок — как правило на «ванилла си».

Абсолютная неправда, без ООП в геймдеве как без рук.

Абсолютная неправда, без ООП в геймдеве как без рук.

ООП отлично реализуется на «си». Собственно, «this» в плюсах — это лишь скрытый сишный инстанц (обычно, структура), для указателя на функцию (из сишной реализации ООП).

А если ты под «ООП» имеешь в виду наследование — то это уже лет 15 как, своего рода антипаттерн (после окончания дискуссий на тему композиция, вместо наследования).

ООП отлично реализуется на «си».

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

А если ты под «ООП» имеешь в виду наследование — то это уже лет 15 как, своего рода антипаттерн

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

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

glib2 (gobject)

/me заплакал

Linux Kernel

Хороший пример, кстати. И в смысле наличия АБИ тоже.

И в смысле наличия АБИ тоже.

А оно может отсутствовать? Так все таки, что такое ABI?

Так все таки, что такое ABI?

en.wikipedia.org/...​lication_binary_interface

В мире «си» подобное существует, в том же линукс-кернеле.

В мире «плюсов» существование, подозреваю, нереально в принципе. Т.к. нет совместимости «плюсовых» бинарников, даже одного кода — после обработки разными версиями одного «плюсового» компилятора.

Ну ты прочитал статью на википедии, просвятился? Зачем глупости писать продолжаешь?

Зачем глупости писать продолжаешь?

„Specific software implementations like the C library may impose additional limitations to form more concrete ABIs; one example is the GNU OABI and EABI for ARM, both of which are subsets of the ARM EABI .”

Найди здеь упоминание „плюсов”.

Впрочем, в статье есть ссылка на попытку формализации „плюсового” АБИ для Итаниума — так и оставшаяся в виде драфтов...

В ABI проблема только в том, что интел, мелкомягкие, багланд, watcom, gcc, clang, oracle, ibm так и не захотели о ней договориться.

так и не захотели о ней договориться

В сишке все тоже самое

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

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

С разными компиляторами тоже всё плохо. Скомпилированная под gcc статическая библиотека — будет неюсабельна в силанге или в вижуалс.

Найди здеь упоминание «плюсов».

«Здесь» это где? В ARM EABI, который например описывает обработку плюсовых исключений? Или парой параграфов выше от этой выдранной цитаты? (И знаешь ли ты кстати как переводится слово «like»?)

Впрочем, в статье есть ссылка на попытку формализации «плюсового» АБИ для Итаниума — так и оставшаяся в виде драфтов...

Itanium ABI — это дефакто стандарт на невиндовых системах

Itanium ABI — это дефакто стандарт на невиндовых системах

Так нет его. Он существует лишь в виде драфтов недоделанных спецификаций.

ABI есть

Лишь в виде недоделанных спецификаций.

Чувак, ABI есть всегда.

Ок, уговорил. Переформулирую: в мире «плюсов» АБИ-совместимость ограничивается одной конкретной версией конкретного компилятора — которым был скомпилирован код. :)

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

Для распространения «плюсового» — существуют либо шаред библиотеки (из которых выкинуто всё плюсовое, а интерфейс полностью сведен к С)

разбил лицо фейспалмом
ну расскажи, как же я использую тот же кьют, где остался только си, или стд либы или сотни других библиотек типа буста и тд

ну расскажи, как же я использую тот же кьют, где остался только си, или стд либы или сотни других библиотек типа буста и тд

Qt распространяется в исходниках. Буст тоже.

А по «qt static libraries» — находится, к примеру, такое: doc.qt.io/...​t-5/linux-deployment.html
«Building Qt Statically»...

Так и используешь...

Qt распространяется в исходниках

нет. я качаю сбилженый фреймворк и использую его

Буст тоже.

тоже нет. только хедеры

Так и используешь...

нет

я качаю сбилженый фреймворк и использую его

Скорее всего, в виде шаред библиотек...

ну ессно. зачем мне статические кьютешные либы?

Статические библиотеки не распространены по совсем другим причинам, вообще-то. Линкеру пофиг, что линковатть, лишь бы оно было.

Статические библиотеки не распространены по совсем другим причинам, вообще-то.

По этим. Если бы не эти причины, распространяли бы код в них — это удобнее, чем шаред-библиотеки.

Нет. Но лекцию читать я не буду. В инете полно объяснений от писателей осей, почему динамические либы лучше.

Нет. Но лекцию читать я не буду. В инете полно объяснений от писателей осей, почему динамические либы лучше.

Да. Просто, ты пытаешься спорить в теме, в которой ни бум-бyм. :)

удобнее, чем шаред-библиотеки.

Так, а как переводится слово «shared»? И кстати, они не библиотеки («libraries»), они «shared objects».

Алсо, ты знаешь что такое «LGPL», и в чем отличие от «GPL»? Просвятись, почитай хотя бы википедию (можно даже на русском-украинском, если у тебя с англ проблемы)

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

Так, а как переводится слово «shared»? И кстати, они не библиотеки («libraries»), они «shared objects».

en.wikipedia.org/...​mputing)#Shared_libraries

Ну и гугли по «shared library»

P.S. При чём тут LGPL и GPL, к чисто техническим ограничениям?

Молодец, открыл википедию и даже нашел нужный раздел, осталось прочитать текст.

P.S. Я же не прошу включить мозги и подумать почему сишные либы тоже как динамические либы распространяют

P.S. Я же не прошу включить мозги и подумать почему сишные либы тоже как динамические либы распространяют

Их не тоже как шаред библиотеки распространяют — а в основном, так распространяют.
Но есть опция распространения и в виде статических библиотек, под конкретный компилятор (и даже часто, без привязки к версии компилятора).

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

Их не тоже как шаред библиотеки распространяют — а в основном, так распространяют.

Перестань нести бред

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

В плюсах тоже, прикинь

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

Перестань нести глупость

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

Что там в них ковыряться? Максимум оциллографом, тестером потыкать и проводок отвалившийся припаять. Максимум, что знать нужно — не суй 2 пальца в розетку с 220 вольтами.

Или ты про схемотехнику и разработку собственно электрических схем? Но каким концом к оному программирование. так и прочистку унитазов можно к программированию причислить. когда сантехник его на програмерской конторе прочищает.

Максимум оциллографом, тестером потыкать и проводок отвалившийся припаять. Максимум, что знать нужно — не суй 2 пальца в розетку с 220 вольтами.

Как минимум нужно знать, что нельзя осцилографом напрямую в розетке синусоиду смотреть ))

Можно, но щупы и вход осциллографа должны быть рассчитаны на 220В. Уверен, что такие осциллографы тоже существуют.
А так просто из осциллографа дымок пойдет.

Впрочем из пальцев в розетке тоже дымок может пойти, если постараться.

Фишка не в этом.

Можно, но щупы и вход осциллографа должны быть рассчитаны на 220В.

С такими щупами все равно имеешь все шансы сжечь осцилограф. Потому что у осцилографа земля щупа соединена с заземлением, а нейтраль в розетке != земля. Класическое решение для таких измерений — это развязывающий трансформатор 1:1 перед щупом. Ну или два идентичных трансформатора, подключенных друг к другу низковольтными обмотками 220В->12В->12В->220В.
Если интересно, то детали в статье.

Так вот же смысл сего действа: «Как одним движением сжечь 10000$».

Viktor Chyzhdzenka прав.
Что в статической что в динамической либе сигнатуры методов т.е. ABI будут одинаковые.
Сделав objdump можно легко проверить.
А значит и нет разницы с чем линковаться.

Но, справедливости ради, действительно есть проблемы в совместимости ABI кода, сгенерированного разными компиляторами.
Потому распространяя С++ библиотеку с закрытым кодом под разные платформы надо компилировать ее компилятором целевой платформы (и с окружением целевой платформы, если ваша динамическая либа в свою очередь линкуется с другими динамическими либами).

Но в принципе это не кажется мне большой проблемой, если действительно стоит такая довольно специфическая задача — распространять С++ библиотеку с закрытым кодом под разные платформы.
Запустите виртуалки под каждую поддерживаемую платформу и соберите там продукт.
Всё равно это делать придется если вы собираешься поддерживать несколько платформ — вы ж будете хоть проверять что оно работает на поддерживаемой вами платформе — или куяк-куяк и к пользователям?

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

Мало того, ещё и с разным набором опций компилятора, которые влияют на стековые фреймы. Например, когда ты отдаёшь функцию в такую либу для вызова колбека, 100% можешь ожидать проблем. Например, для Vulkan ICD и их механизма аллокаторов они просто переписали все точки входа на асме: github.com/...​r/unknown_ext_chain_gas.S

Мало того, ещё и с разным набором опций компилятора, которые влияют на стековые фреймы.

а вот это наверно таки и к С относится, а не только к С++.

Мало того, ещё и с разным набором опций компилятора

Именно так. Подобные проблемы (зависимость не только от компилятора, но и от версии версии/тулсета, опций) есть и с «сишными» библиотеками — но в куда меньшем количестве и с возможностями их избегать.

линукс кернел по сравнению с гстримером чистый и прозрачный как слеза младенца

И не смотря на это, его все равно нужно было портировать на clang в свое время.

И не смотря на это, его все равно нужно было портировать на clang в свое время.

Нафига?

Похоже, ты ещё и не понимаешь, в чём именно разница между gcc и clang. :)

Нафига?

Потому что ядро не собиралось через clang

Похоже, ты ещё и не понимаешь, в чём именно разница между gcc и clang.

Кернел девелоперы тоже наверное:
www.phoronix.com/...​page=news_item&px=MTM1NDY

Кернел девелоперы тоже наверное:
www.phoronix.com/...​page=news_item&px=MTM1NDY

Сбилдили cлангом кернел для Андроида? Хм... Похоже, пора переходитъ на ios.

Впрочем, как раз в этом никакой технической нужны не было — т.к. силанг худший компилятор, чем gcc. Но вероятно, хотят уйти из под GPL лицeнзии (как и FreeBSD ранее).

Опять не читаешь все слова-буквы-предложения?

ООП отлично реализуется на «си».

И за примером далеко ходить не надо. Открываем исходники, например, гэстримера и наслаждаемся.

ОпенГл был куда более приятен в использовании, пока был компактным апи, а директ3д наоборот, был очень громоздким. Потом как-то всё перевернулось.

В геймдеве весь openGL/движок — как правило на «ванилла си». На «плюсах» может обвязка к джойстику/мышке/клаве/музыке — коей менее 5% кода.

UnrealEngine, Unity (рантайм), CryEngine (або Amazon Lumberyard), Source — найпопсовіші двигуни, на яких роблять як і AAA, так і інді, написані на плюсах (код легко гуглиться). На «ванілла сі» писали хіба діди в дев’яностих, розбавляючи код асемблерними вставками. Зараз таким ніхто займатись не стане.

Десктоп — нет

Цілком собі так. І навіть кросплатформені рішення (Qt та інше).

Сервер — тоже нет

Переважно С++ з мого досвіду.

Мобайл?

Ні.

В эмбеде — «плюсы» даже не появлялись.

Што?

Страуструп, тем временем, активно работает над запихиванием всего «буста»

Вся суть буста в тому, що він не є частиною std.

очень посредственный фреймворк, как по мне

Не фреймворк.

и превращением «плюсов» в недо-шарпы

Скоріше в Python.

Скоро, говорят, рефлекшн встроят.

Хто каже?

Хто каже?

Про рефлексію справді є пропоузали до C++23. Але ніасілятори-плюсофоби як завжди чують дзвін, та не знають де він. Рефлексія, яка пропонується для плюсів, не має нічого спільного з рантаймовою рефлексією джави чи пітона (хоча таку, ймовірно, при бажанні теж можна зробити за допомогою плюсової). Тут вона в основному для компайл-тайм інтроспекції і кодогенерації.

Ну не знаю, поработав пару лет на Python, вернутся на С++ мне было очень приятно.
В С++ компилятор делает большую часть работы, что незаменимо в задачах типа поменять сигнатуру метода в проекте на много тысяч строк и проверить что всё работает.
На С++ надо просто скомпилировать, а на Python надо предварительно покрыть всё unit-test-ами и ничего не пропустить, что приводит к необходимости писать юнит-тесты которые тестируют тривиальные вещи и то не факт что не ошибёшся.
Потому интерпретируемые языки с динамической типизацией для сложных проектов как по мне очень неудобны.

Остаются конкуренты — компилируемые языки типа Java/C#.
Но от них по синтаксическим возможностям С++ последних редакций не сильно отличается.
На С++ можно кодить как на Java без прямого управления памятью, пользуясь умными указателями.

Интересно конечно куда дальше заведет эволюция.
Если пофантазировать, то может случится так, что всё что нужно было наговнодить быстро — уже наговнокодят, и между компаниями начнется конкуренция по производительности и экономичности — как одну и ту же задачу выполнить быстрее, используя минимальное кол-во физических ресурсов и энергии, а значит сэкономить деньги.
И тут вроде кажется логичным переписать на С++.
Так что для плюсовиков работа думаю будет всегда.

И что в питоне от интерпретаторах?

Всё вообще-то. Он сам интерпретатор.

Чушь.
Питон честный компилятор в байт-код.

Питон честный компилятор в байт-код.

Ну да, байт-код для интерптерации пайтоновским интерпретeром.

Да нет, там извращаются, чтобы не совсем уж тормозило. Типа жабы делают.

Пока питон юзали, как интерпретатор, что-то по быстрому наваять и посмотреть, что получится мне питон вполне себе нравился (удобнее баша того же). Но лично я для математики в качестве интерпретатора по-быстрому наваять предпочитаю матлаб (помимо того, что он сам числодробилка, так к нему на С или С++ что-то дописать элементарно в отличие от питона). Но питон массово юзают потому как за него платить не нужно (да программистам нужно платить, но кто же думает хоть на день вперед — ***к-хуяк и в прод нынче основное правило программазма).
Но как сейчас питон юзают, а потом годами воют с тормозами (впрочем почему не пилить инвесторские бабки), то питон я стал сильно не любить. Во все дырки его суют, особенно меня впечатляет. когда его засовывают во всякие однокристалки.

Да нет, там извращаются, чтобы не совсем уж тормозило. Типа жабы делают.

Жаба тоже интерпретатор. То, что компайлит по итогу даже не в байт-код, а в машинный код, пользует жит, хапает память на старте (в качестве пула) — помогает мало.
Т.к. код всё одно интерпретируемый — просто, интерпретатор закомпайлен прямо в тот же машинный код.

Соответственно, всё то же тормознутое и выжирающее память г. (в сравнении с нативными решениями).

Жаба тоже интерпретатор.

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

Соответственно, всё то же тормознутое и выжирающее память г. (в сравнении с нативными решениями).

А потому что иначе не сделаешь.

Нет. Она именно дабл компилятор.

Виртуальная машина жаба, понятно — интерпретер. Жаба это не интерпретер, а язык. :)

А так, виртуальная машина просто вшивается в исполняемый код. И в нём занимается тем самым переводом байт-кода в машинный.

Да плевать. В игру слов я долго не люблю.

Но питон массово юзают потому как за него платить не нужно (да программистам нужно платить, но кто же думает хоть на день вперед — ***к-хуяк и в прод нынче основное правило программазма).

Пайтон, в основном, юзают в академической среде (всякий дата-сайнс относится туда же). Юзают, т.к. юзеры слишком тупорылы, для освоения «си» или тем более «плюсов».

А в итоге, тупорылось эта академическая — выливается во всемирные локдауны из-за гриппа + неуёмную баблопечать, чтобы устроить всем социализм.
Закончится, как обычно такое заканчивается — очередным большим бадабумом (как 100 лет назад), лет через 20...

Пайтон, в основном, юзают в академической среде

Нет. Точнее стали юзать последние 10 лет, как крутые ребята numpy (либа для питона) отличную сделали.

И не называй местных или не местных нищебродов академиками.

Пайтон, в основном, юзают в академической среде (всякий дата-сайнс относится туда же). Юзают, т.к. юзеры слишком тупорылы, для освоения «си» или тем более «плюсов».

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

Виртуальной машиной.
То же, что и джава. Разве что нормального джита нет, и не будет.

Виртуальной машиной.

Виртуальная машина — это и есть интерпретер.

Собственно, процессор это тоже интерпретер (машинного кода). Но после интерпретации байт-кода виртуальной машиной — этап интерпретации получаемого машинного кода процессором никуда не девается. И кода после виртуальной машины, становится не меньше, а больше.
И это даёт большую разницу...

Не стоит придумывать свои термины или устоявшимся терминам придавать свои значения.

Не стоит придумывать свои термины или устоявшимся терминам придавать свои значения.

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

Виртуалее ная машина джава — всегда была «интерпретером байткода».

Кроме случаев, когда она его компилирует (99% реальных использований для кода, который используется более чем K раз).

Странно, что для т.н. «софтваре архитекта» это новость.

Ну продолжай дальше рассказывать про C...

что такое нативный код на андроиде?

Если бы он был компилятором, программа бы поставлялась в виде pyc-файлов. Сейчас же main-модуль вообще не «компилируется», а остальным это максимум добавляет пару процентов скорости на старте за счёт отказа от парсинга.

Почему то как поставляется программа, говорит о том как она выполняется. Разве эти исходные файлы не компилируются при загрузке модуля в байт код?

Разве эти исходные файлы не компилируются при загрузке модуля в байт код?

В общем случае — нет. «Байткод» это особенность одного из текущих интерпретаторов (хоть и самого канонического), которая может быть устранена как только окажется, что какая-то другая форма — например, AST дерево или IL стиля LLVM с явными «значениями» — выгоднее. Язык стандартизован исключительно в виде исходного кода. Этим Python принципиально отличается от Java, где свойства JVM и компилированного в виде *.class кода заданы стандартом.
Вторым существенным моментом является наличие парсера исходного кода в AST и затем в байткод стековой машины в стандартной библиотеке, поэтому исполнение из того же байткода совершенно не обязательно. Для Java, C#, Erlang и прочих, где уже честный промежуточный код, компилятор отделён и это достаточно увесистая машина.

Спасибо за подробный ответ.
Можно ли тогда считать канонический cpython компилятором?

Можно ли тогда считать канонический cpython компилятором?

В понятие компилятора, по сравнению с интерпретатором, обычно (согласно всем классикам) входит генерация кода, заметно переработанного по сравнению с исходным, под некоторого промежуточного исполнителя, с возможностью произвольного преобразования программы, в любых пределах, когда она делает то же, что исходная. CPython не делает это даже для случаев, которые были очевидны для какого-нибудь GCC лет 30 назад. Исходный код парсится и переводится в промежуточную форму. Генерация и исполнение этой формы принципиально не предполагает наличия высокого интеллекта участвующих средств по оптимизации расходов на процессор и на память; основной вклад в это обеспечивается спецификацией языка, которая допускает изменение на ходу чуть ли не всех аспектов работы (например, нормально заменить метод объекта на другой, не трогая другой объект того же класса).

Граница между компиляцией, интерпретацией и промежуточными подходами (как с байткодом, который на ходу компилируется в машинный код) нежёсткая, да. Но я бы сказал, что CPython это интерпретатор на 99.99%. Ну может, на 99.9% :)

На С++ можно кодить как на Java без прямого управления памятью, пользуясь умными указателями.

Осталось проверить чтобы везде были эти умные указатели и чтобы с ними ещё умно обращались.
Я как-то налажал — передал в лямбду, пробрасываемую в другой тред, _ссылку_ на shared_ptr, переданный как аргумент функции. Хоть бы одна собака сказала из компиляторов, что я был не прав...

Анализаторы совершенствуются понемногу.
ЕМНИП раньше не ругались на несоответсвие в порядке инициализации членов класса в декларации класса и в реализации, а теперь ругаются.
Возможно статические анализаторы типа clang-tidy вашу проблему уже в состоянии выловить, либо будут в состоянии это сделать в обозримом будущем.

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

Ну и понимание lifetime объекта — это ключевое понятие в C++, отчасти благодаря которому и достигается производительность, а также многие уникальные фишки типа того же RAII.
Без этого понимания далеко не уедешь.
Но как по мне, это сводится к довольно простому списку правил, как создавать и передавать объекты в зависимости от контекста решаемой задачи — намного проще чем на литкоде задачки решать или пытаться сделать RAII на Яве или Питоне и не налажать.

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

Ну а мне кажется наоборот — что усилия программистов по нарушению всего, что только можно, испортят все достижения анализаторов — пока вообще выстрелить себе в ногу будет принципиально возможно. Единственный метод избежать этого — жёсткое автоматизированное разделение между тем языком, где ещё можно совершать диверсии, и тем, где это уже не допустимо (пусть и дороже).

Остальные проблемы... неравномерный и непредвиденный GC давно решён (пусть и потерей 10-20% производительности). Память — примерно аналогично. Производительность в отдельных случаях может быть даже лучше, чем у чисто компилируемого C++, в среднем же просадка не превышает пары раз. Времена анекдотов про увеличение потребности памяти в десятки раз давно прошли. Как по мне, это всё ничтожная цена за избавление от тяжёлой головной боли у всех.

Остальные проблемы... неравномерный и непредвиденный GC давно решён (пусть и потерей 10-20% производительности).

10-20% при любом кол-ве созданных объектов в сек?

Что-то у меня в голове не складывается как это можно решить малыми потерями.
Пусть у вас есть объект А, внутри него агрегировано 10 других объектов, внутри тех объектов еще по 10.
В Java вызовете new A() и это приведет к вызову 100 new для суб-объектов, что само по себе уже не очень т.к. потребует аллокатору хорошо потрудится, чтоб найти и выделить блоки нужных размеров.
Потом всю эту свору нужно когда-то GC обработать и освободить.

В С++ new A() одним махом создаст объект и все агрегированные под-объекты, если в самом простом случае. А если объект на стеке, то в каких-то случаях вообще может не обратится к аллокатору.

10-20% при любом кол-ве созданных объектов в сек?

В среднем по больнице, включая морг и крематорий ©.

«При любом», конечно, не будет. Можно легко придумать такие шаблоны поведения, которые будет неэффективно реализовывать на выбранном конкретном языке.

В Java вызовете new A() и это приведет к вызову 100 new для суб-объектов, что само по себе уже не очень т.к. потребует аллокатору хорошо потрудится, чтоб найти и выделить блоки нужных размеров.
Потом всю эту свору нужно когда-то GC обработать и освободить.

Вы как-то заметно отстали тут от жизни. Слова про «найти и выделить блоки» показывают полное незнание современных подходов.

Типовые аллокаторы Java, C#, аналогов работают так:

1) Есть большой последовательный кусок адресного пространства. (С учётом специфики многонитевости, таких кусков может быть несколько, но они большие — например, десятки мегабайт — чтобы переход между ними не мешал эффективности общей идеи.) В нём заведена «куча» (heap).

2) new() это просто сдвинуть на нужное количество байт указатель правого конца области кучи и записать в начало блока указатель на структуру определения класса (для C++ аналогом будет virtual method table, указатель на который пишется в любой объект с вирт. методами).

(Объекты размером больше 2-8 страниц виртуальной памяти аллоцируются независимо.)

3) Схема поколений оптимизируется на то, что >95% объектов короткоживущие и не переживают ближайшую сборку. Сборка производится по событиям типа «с момента последней сборки 0-го поколения аллоцировано 4MB», «с момента последней сборки 1-го поколения прошло 100 сборок 0-го поколения» и т.п.
Сборка поколения обычно сводится к сжатию хвоста аллокации с передвижением всего выжившего в начало расчищенной области. Редкие варианты со ссылками из старших поколений в младшие отрабатываются отдельно и не портят существенно этот процесс.

В результате (разумеется, при ещё 100500 частных оптимизаций этого процесса) оказывается, что есть шаблоны, и нередкие, на которых аллокация такого рода с последующей сборкой работает _быстрее_, чем управление памятью в описанном вами виде. На скорость этого процесс работает и тривиальность аллокации, и пространственная локальность участвующих блоков кучи (кэши процессора это оптимизируют), и пространственная локальность кода сборки.
Разумеется, это далеко не всегда помогает, но представление о том, что GC это страшно дорого, возникло во времена очень ранних подходов. С тех пор уже дети родились, закончили школу и вуз и работают в IT :)

В С++ new A() одним махом создаст объект и все агрегированные под-объекты, если в самом простом случае. А если объект на стеке, то в каких-то случаях вообще может не обратится к аллокатору.

Выделение под-объектов отдельно — да, свойство AMM-рантаймов, но 1) за счёт метода аллокации — см. выше — они находятся рядом и повышается вероятность попасть в ту же кэш-строку; 2) value types выделяются структурами в родительском объекте; в .NET работает изначально; в Java застряли, но сейчас наконец вводится в язык. Кроме того, все «взрослые» средства подобного рода предоставляют работу с буферами памяти.

Оптимизация «если объект можно просто разместить на стеке, не заводить его в куче» присутствует во всех движках JVM, .NET, JavaScript уровня более чем студенческая поделка, и в большинстве других JIT. Гуглить по словам «escape analysis» и его применении в реальных средствах. Упоминая это в качестве аргумента для C++, вы снова показываете полное незнание современной обстановки. Рекомендую продолжать дискуссию после ознакомления с ней хотя бы в базе.

Спасибо за подробный ответ.
Действительно, чем больше я работаю, тем больше я понимаю что знаю я очень мало.
На Java последний раз писал больше лет 10 назад и не очень следил за изменениями.
Видно, что есть пробелы в понимании современных подходов.

Но в общем тенденция понятна.
Java постепенно улучшает свои узкие места, а С++ — свои.

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

На Java последний раз писал больше лет 10 назад и не очень следил за изменениями.

Ну описанное было уже в основном справедливо где-то на 2005, а совсем платно и на 2000 (хотя качество в деталях было, естественно, сильно хуже).
Сейчас за счёт конкуренции (в первую очередь с дотнетом) подобные фишки предоставляются в основном бесплатно. Хотя и сейчас есть исключения — например, виртуальные машины от Azul, гарантирующие прерывание на GC не более чем на порядок 1 мс, платные (и заметно), похоже для GraalVM. Но и их лет через 10 подвинут.

Но в общем тенденция понятна.
Java постепенно улучшает свои узкие места.
С++ — свои.
В итоге выйдут на какую-то точку сингулярности, наверно.

Общей сингулярности безусловно не будет, она будет разная :) но близко к тому.

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

Ну я к этому только одну собачью лапу съел, а есть люди, которые уже стаями закусили :)
Но, в общем, есть давно документированные характерные проблемы каждого, и >90% просто решается обходом их вовремя. Дальше уже хитрые частности.

Возможно, у меня субъективное мнение сложилось.

Но вот не могу вспомнить ни одно приложение на Java, которое б подтверждало тезис о том что оно работает не медленнее плюсов.
Eclipse, NetBeans, Lotus Notes, да даже Jedit.... Ну вот ни одно не могу назвать.
Все как-то подтормаживает, глючит, ну вот реально открыл-попробовал-выбросил.
Lotus Notes на одном проекте заставляли пользоваться для корпоративной почты и это был Ад и Израиль.

С другой стороны есть Firefox, Chrome, Thunderbird, Gimp, Inkscape, Libreoffice, сотни их, которыми приятно пользоваться.

Я думал что это связано с особенностями Явы что я назвал выше.
Но оказывается их уже с 2005 оптимизировали и должно было все летать.

Тогда как такое получается, если теоретически всё должно летать и 90% проблем можно просто вовремя обойти?
Неужто дилетанты пилят вышеописанные продукты на Java?

Неужто дилетанты пилят вышеописанные продукты на Java?

И не только на ней. Причина в особенностях найма в ИТ (в деталях о ней Пение тут постоянно пишет).

Возможно, у меня субъективное мнение сложилось.

Точно-точно.

Все как-то подтормаживает, глючит, ну вот реально открыл-попробовал-выбросил.

Подтормаживает — это одно, а глючит — совсем другое. AMM устраняет баги, вызванные некорректной работой с памятью. Целый ряд багов появляется при MMM (manual memory management), и это как раз будет относиться к продуктам на C++.
Включая тут к продуктам на Java вопрос глючения, вы уже подменяете тезис.

Я из перечисленного работал только с Netbeans. Выглядит достаточно неплохо.

С другой стороны есть Firefox, Chrome, Thunderbird, Gimp, Inkscape, Libreoffice, сотни их, которыми приятно пользоваться.

Шутите? Может, в случае браузеров все их супер-разбухания в памяти и связаны с том, какой код во всяких фейсбуках в страницах, но постепенный перевод Firefox на Rust говорит, что не всё так гладко. Ну а про вечно проблемный — и глючащий таки! — Libreoffice только ленивый не пишет. Проект такого размера, не связанный с системным слоем, писать на C++ это уже диверсия. Он и падает, и регулярно рисует что-то не так (особенно когда работает с документами от MS Office)... и 20 лет развития это до конца и не выкосили.
И что, у вас никогда например Firefox не писал «ой, таб крэшнулся»? Зачем было бы выделять процессы работы со страницами (а Chrome это делал, заметьте, с самого начала)?

Неужто дилетанты пилят вышеописанные продукты на Java?

Дилетанты пилят _всё_. Ну, точнее, 95% всего. Все мы дилетанты и регулярно лажаем. Если вы считаете про себя иначе, смотрите в зеркало и повторяйте «я не буду должен считать себя гением» каждое утро 1000 раз.

Проблема в том, что у менеджмента слишком часто возникает over-reaction — если средство позволяет занизить качество программистов, грубо говоря, на ε условных попугаев, то они сходу идут занижать на 2ε. Да что я там скромничаю — сразу на 5ε.
Это позволяет продукту взлететь, да. На C++ с такими авторами он бы просто не взлетел. Но для взлёта 2ε бы хватило, остальные идут в карман ворам от IT.

Sun, потом Oracle, очень удачно паразитируют на этом. «Nobody fired for buying IBM» => «Nobody fired for buying Intel» => «Nobody fired for choosing Java». И это таки проблема. Но решать её надо не устранением Java/etc., а обеспечением таким ворам неба в клеточку.

Firefox, Gimp та Libreoffice як приклад надійного та швидкого софту — це було несподівано :D

Да, не лишены недостатков.
Но каких-то проблем, мешающих пользоваться, я не находил.

Firefox лет 5 назад стал сливать Хрому по скорости, потому сейчас я больше Хромом пользуюсь.

С Gimp вообще никаких проблем никогда не было, но я и не профессионально им пользуюсь.

Libreoffice — вообще нет конкурентов, кроме как MS Office.

Но, с другой стороны, я вот подумал и осознал, что продуктами написанными на Java, я вот вообще не пользуюсь.
И это не из-за какой-то принципиальной позиции.
Мне не пофиг на чем рзрбатывать, но пофиг на чем написан продукт, которым пользуюсь, если он выигрывает у конкурентов.

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

Firefox лет 5 назад стал сливать Хрому по скорости, потому сейчас я больше Хромом пользуюсь.

WAT?
Хром періодично підвисає так на хвилину-дві.
Мабуть GC на ++

Подтормаживает — это одно, а глючит — совсем другое. AMM устраняет баги, вызванные некорректной работой с памятью. Целый ряд багов появляется при MMM (manual memory management), и это как раз будет относиться к продуктам на C++.
Включая тут к продуктам на Java вопрос глючения, вы уже подменяете тезис.

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

Дилетанты пилят _всё_. Ну, точнее, 95% всего. Все мы дилетанты и регулярно лажаем. Если вы считаете про себя иначе, смотрите в зеркало и повторяйте «я не буду должен считать себя гением» каждое утро 1000 раз.

«Чем больше я работаю, тем больше я понимаю, что знаю я очень мало» ©.
Мой вопрос был подводкой к тому, что раз средний уровень разрабов С++ и Java примерно одинаковый (а я действительно считаю, что это так), то перевес кол-ва быстро работающих живых сложных продуктов на С/C++ как бы говорит о том, что эта технология лучше работает в этой нише.

но постепенный перевод Firefox на Rust говорит, что не всё так гладко

Вот это кстати интересный вопрос.
Много лет назад у Firefox была достойная доля рынка.
Потом появился Chrome и вытеснил его, т.к. работал быстрее и стабильнее.
Firefox пробует решить свои проблемы и заполучить рынок обратно за счет новой технологии.
Я запасся попкорном и наблюдаю, чем это закончится.
Будет либо рассвет Раста либо гибель Firefox.
Если будет вариант 1, то этот use case могут начать пользовать другие и возможно Rust начнет теснить C/C++.
Если будет вариант 2, то в анналы истории запишут, что переход на раст был неудачным инженерным решением который окончательно загубил проект.
Но FF кстати пробует конкурировать с Chrome, который таки написан на C++ а не на java, т.е. тут идет баттл в доменах Rust vs C++, и Java на горизонте нету.
Chome пилят толковые инженеры из Гугла, которые решают именно корень проблемы, а в FF пошли путем не разобраться в проблеме а переписать на языке N заново.
FF очень рискует, выбрав тот вариант развития что они выбрали.

Ну а про вечно проблемный — и глючащий таки! — Libreoffice только ленивый не пишет. и регулярно рисует что-то не так (особенно когда работает с документами от MS Office)

Дайте мне плиз достойный аналог на Java, буду с удовольствием пользоваться.
Самому очень не хватает 100% совместимости с MS Office.
Но нету почему-то аналогов... Отчего ж это?

Это позволяет продукту взлететь, да. На C++ с такими авторами он бы просто не взлетел.

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

Sun, потом Oracle, очень удачно паразитируют на этом. «Nobody fired for buying IBM» => «Nobody fired for buying Intel» => «Nobody fired for choosing Java». И это таки проблема. Но решать её надо не устранением Java/etc., а обеспечением таким ворам неба в клеточку.

Вот это, простите, я вообще не понял.
Кто и что у кого украл?

LOL, ниасилил штоле? Про boost отделное га-га-га.

Где их ниша в современной разработке?

Computer Vision как вариант

Я так понимаю что это троллинг. Мне сложно представить использование другого языка там (кроме С), где разница скорости исполнения 2-3 мс является критической, а таких задач овердохера от медицины до атомных станций.

И не надо так далеко ходить. Везде, где нужна достаточно быстрая реакция компа на возбудители без С (С++) не обойдешься. Или где нужно от железа получить максимум быстродействия, минимум потребления ресурсов.
А это даже бытовые вещи, типа «умной стиральной машинки».

для чого, щоб по вебсокету прислати пушнотифікацію на вєдроід?

Я бы смотрел в направлении вол-стрит.
1. Теорвер и статистику действительно надо будет подтянуть, но там нет ничего особо сложного.
2. Если хочешь выйти на 150-200 долларов в час как контрактор, со временем, то надо получить FRM или CFA, лучше FRM. Без них реально будет до 80-100 долларов, но можешь потерятся в индусовом потоке. Единственный нюанс, с вероятностью 99% надо будет находится в офисе клиента постоянно из-за требований безопасности. Основной город для тебя — Лондон. Хотя есть несколько крупных хфт в Нидерландах.
3. Обязательно получить CUDA сертификацию и вообще изучить HPC. Половина сидит на Амазоне поэтому и оркестрацию всей этой хрени тоже лучше знать.

Для среднего ума вся подготовка займет где-то 1-2 года. Других вариантов заработать бабок на принципиально другом уровне нет.

На рідкість таргетований і толковий коментар

Дякую, саме такий коментар і чекав. Дай тобі Боже здоров’я.

А можеш, бажано з лінками, підказати більш детальну роадмапу по підготовці.

1. Сначала берешь учебник вузов по статистике, теорверу, матанализу (больше на всякий случай), можно еще теорию игр.
2. Записываешься сюда: www.garp.org/#!/frm
3. Записываешься сюда: developer.nvidia.com/cuda-education-training
3.5. Подучи R или Питон если есть время и силы
4. ...
5. Профит!

Большой совет: заходишь на вот этот сайт www.efinancialcareers.co.uk после сдачи первого экзамена по FRM и начинаешь откликиваться на вакансии. Соглашаешься даже на 20-25 фунтов в час, потому что тебе самое главное получить навыки общения с трейдерами и портфолио менеджерами. В целом твой результат будет зависить от твоих способностей, но если разранжировать, то приблизительно так по деньгам:
1. Способен сам разрабатывать модели, готовить гипотезы и стратегии (ты практически трейдер) — 800-1000 фунтов в час
2. Разработка моделей под гипотезы ПМа или трейдеров без ТЗ — 500-600 фунтов в час
3. Разработка и оптимизация моделей под любой портфель без ТЗ — 300-400
4. Кодинг по ТЗ и оптимизация по ТЗ — 100-200 фунтов

Ты только на цифры не облизуйся :) Тут надо правильно понимать, что оплачиваемых рабочих часов у тебя будет до 100-110 и 3-4 месяца могут прерваться на такой же срок без работы так что исходя для подсчета годового заработка дели все на 3 или на 4.

А нафига разработчику FRM? Это же явно к разработке не относитьтся.

Вангую, для отримання експертизи в доменній області.

CFA (в сенсі Charterholder’а) так просто не вийде — це точно не рік, але поки здасте 3 рівні, креденшиалс можна зібрати. Цілитись треба в 3-4 роки реалістично. Інше питання, що навіть перший рік вже зроблений як хороший вступ до предметної області. По curriculum FRM не підкажу, не в курсі

як варіант

Should we, the experienced C++ programmers, discourage C++ usage among less experienced programmers like long time smokers discourage smoking among the younger generation?

okaleniuk.medium.com/...​rong-about-c-77c11ff011ed

тупая манипуляция

flyman здесь другого и не пишет.

Хотя сама статья вообще не об этом. Там автор рассуждает, задаёт вопросы, и в конце сам говорит, что однозначного ответа на них не знает.

Как вам плюсы в универе не надоели?! Вот РУСТ это да!!!

Не было их еще тогда, когда я там училсяв универе.

Може трохи не по темі але все ж таки цікавить як спільнота IT ставиться до наступного твердження. «Розвиток технологій сповільнюється, отже акцент буде зміщено на оптимізацію виконання коду, а не заліза» тож з відси питання. Можливо як раз c++ буде найактуальнішою мовою 21го сторічча?

ні

Да. Но возврат будет не к «плюсам», а к «сям».

К сям — точно нет. Почти любой сишный код можно скомпилить плюсовым компилятором (а если разрешить легкую доработку напильником — то вообще любой).

і тут в кустах знаходиться внєзапно Rust

Вот не надо загаживать кусты.

Досі не розумію, чому вони не зробили підмножину С++ чи С, як Ada SPARK

Навряд, акценти якраз зміщуються в сторону спрощення і пришвидшення процеса розробки.
Хоча є опція, що 0.001% дуже смартових девелоперів на плюсах будуть писати супер-оптимізовані ліби та інтерфейси до них, які решта 99.999% розробників буде використовувати.
Якщо буде так, то плюси, по факту, будуть в кожному проекті, а по суті, 99% девелоперів будуть писати код рівня:
 import TheWholeLogic; 
 Create system; 
 system.makeCustomerHappy; 

import TheWholeLogic;

це в якому стандарті С++?

невже пакетний менеджер запиляли і не тре всяких Смаке ?

при чем тут смаке к пакетному менеджеру?

тобто ще один варіант include :(

о госспаде. не хочу я с тобой спорить, думай шо хочешь

я думав, що за 30 років нарешті появився пакетний менеджер в С++, а тут просто нове слово втулили «імпорт»

Пакетний менеджер і модулі в С++20 — це перпендикулярні речі. Можна юзати пакетні менеджери без модулів, можна модулі без пакетних менеджерів, можна те і друге разом. import — не просто нове слово, а нова концепція. Схоже на using в шарпі — використання якогось модуля без включення його *.h-файлів, а лише з використанням мета-даних про експортовані ним функції та класи.

Можна юзати пакетні менеджери без модулів

— можна, але для чого завдавати собі подібний біль?!

Це питання можна задати стосовно майже будь-якої сучасної фічі C++, яку з тих чи інших причин відмовляються використовувати на проекті.
Причини можуть бути абсолютно різними, від цілком об’єктивних (наприклад, бізнес вимагає спеціальної «сертифікації» від компілятора, а «сертифікованим» є тільки якийсь древній борланд) до просто нераціональної законсервованості техліда.

Стосовно пакетного менеджера і модулів Володимир абсолютно правий. Пакетний менеджер — це про зручне підключення інших бібліотек, про зв’язування проектів одне з одним. Модулі — про зв’язки між сутностями всередині одного проекту (людська альтернатива костильним інклюдам, до яких вже всі настільки звикли, що перестали помічати їх безглузду суть «а давайте скомпілимо один і той самий код 1000 разів, щоб потім 999 його копій викинути і залишити тільки одну»).
Речі повністю ортогональні.

Как хорошо, что ты и подобные тебе сваливают на расты и гоу.

звичайно ліпше, чим кожні 3 роки вивчати новий С++ і пам"ятати старіші його варіанти

Учиться всегда полезно для мозга.
Но приплюснутые консервативны и всякую новизну раьнше времени в код не тянут.

Та пусть валят.
А я себе еще раз попрошу добавки к зп. Попутно ознакомившись с разной хипстерщиной и взяв из неё какие то интересные парадигмы и подходы.

Ось це непогано себе показало на одному з попередніх проектів — docs.microsoft.com/...​build/vcpkg?view=msvc-160

Ось це непогано себе показало на одному з попередніх проектів — docs.microsoft.com/...​build/vcpkg?view=msvc-160

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

Навряд чи «найактуальнішою», бо С++ не дуже легко «продавати» замовникам. Їм треба, щоб гарний фронтенд, щоб модні слова в стеку технологій, щось про клауд і машін льорнінг. І їм це продають. А от уже тим, хто всі ці речі робить — от їм справді часто будуть потрібні швидкі компоненти на плюсах. Тому, з одного боку, плюсовики без роботи не залишаться, але з іншого — в якихось топах «найхайповіших мов 21 сторіччя» їх не буде.

заказчикам продают решения, а не языки

Як коли. В продукті — продають продукт. В аутстафі — продають виключно вузьких спеців саме по певним технологіям. В аутсорсі буває і так, і так.

Pre-sale команда продає замовникам презентації, обіцянки, цифри в костах і гарні картинки. Технології тут відходять на 2-3 план.
Досить мало замовників наполягають на конкретній технології. Виключення — коли продають легасі проекти на саппорт, тоді від пропонованого стеку не відкрутишся.

Виключення — коли продають легасі проекти на саппорт

Що складає приблизно 95% українського ринку аутсорсинга-аутстафінга :)

(я автор питання, пишу зі свого акк)ну ураховуючи, що майже все підряд переходить від згорання на електрику то низькорівневе програмування аж ніяк не може не бути в топі, той факт що звісно попит на сайти буде завжди величезний ніхто не сумнівається...але трохи малось на увазі інше. Малось на увазі, що ера зменшення деталей в два рази за цикл пару років добігла кінця, а потреби\попит в удосконаленні додатків(графіка, швидкість, об’єми даних) ростуть в геометричній прогресії. Може дійсно до свого арсеналу .NET Developer почати розвиватись в напрямку C/C++

Ваші слова мають сенс, але я, як дев який 10 років подорожує по галерам, скажу вам, що таких проектів, де вимагається швидкодія, оптимізація і просто де міряють перфоманс між релізами катастрофічно мало.
Зазвичай, проекти на плюсах це просто низькорівнева бізнес-логіка і використання низькорівневих API для якихось бізнес-задач.
Сучасні проекти на плюсах МОЖУТЬ бути швидшими ніж їх аналоги на джаві і дотнеті, наприклад, але це не досягається тим, що програмісти розумніші, а тим, що компілятор оптимізує левову частку коду( наприклад, розвертає цикли у лінійну простиню коду ) і особливістю самої технології( відсутність витрат на garbage collector, платформозалежність ).

наприклад, розвертає цикли у лінійну простиню коду

Плохой какой-то пример, антипаттерн.

А за счёт чего можно получить выгоду?
Branch prediction отработает, поэтому выгоду от unrolling из-за меньшего количества переходов и соответсвенно из-за отсутствия pipeline bubbles не будет.
Из-за отсутствия операции декремента и перехода? Ну может, если в теле цикла почти ничего не делается кроме этого, тогда может и будет видно. Но есть архитектуры где есть поддержка циклов и там оверхеда нет.
Процессор может параллельно выполнять инструкции? Так ему ничего не мешает и в цикле это делать, branch prediction то работает.
А вот что точно будет плохо — это разбухание кода, хуже с кешем. Запросто может перекрыть все выгоды. Походы в память очень дороги.

Я наверное не прав насчёт антипаттерн. Просто это, скажем так, очень неоднозначная оптимизация. Может улучшить, а может здорово ухудшить. Надо включать, профилировать, и как правило выключать.

И кстати, ничего не мешает делать то же самое в джава и дотнете.

Моя початкова думка була про оптимізацію коду компілятором, а як саме він оптимізує, розвертає щось чи взагалі видаляє шматки коду, якщо на етапі компіляції виявиться, що в цей бранч ніколи не зайде, це вже питання інше. Само собою, що розвертати завжди всі цикли може бути не найкращим рішенням.

Ты просто не в курсе. Почитай для чего, когда и почему разворачиваются циклы.
en.wikipedia.org/wiki/Loop_unrolling

Это ты просто не в курсе.

Перша частина — так. Друга — мабуть ні, бо винайдуть щось раціональніше ніж C++, без тисяч легасі-правил, при збереженні такої ж гнучкости.

«Розвиток технологій сповільнюється, отже акцент буде зміщено на оптимізацію виконання коду, а не заліза»

А почему именно C++? Вы можете с большей эффективность писать программы на C#, так как там с версии 4.0 легко встраивать параллелизм в свои задачи. Оптимизация кода в .Net 5.0 (это .Net Core, но все равно) не особо хуже на С++ с полной оптимизацией, а каждое ядро ускоряет ваш код линейно при правильных алгоритмах.

Если вам и этого не хватает, то C# + OpenCL и векторно-матричный процессор к вашим услугам, хоть GPU, хоть AVX512.

Плюси дозволяють напряму маніпулювати памяттю, що, дуже теоретично теоретично, мало б допомогти оптимізувати окремі ділянки окремих алгоритмів. Здається, в дотнеті такого нема.

Плюси дозволяють напряму маніпулювати памяттю, що, дуже теоретично теоретично, мало б допомогти оптимізувати окремі ділянки окремих алгоритмів. Здається, в дотнеті такого нема.

raw pointers есть в C#

docs.microsoft.com/...​age-reference/unsafe-code

unsafe-code

Ну и нафиг для этого C# нужен. Основной его плюс — это именно safe-code. Без него он превращается, превращается — в ответвление С, С++.

Помню когда-то давно я так скрешивал С# и С++. Простенькую гуйню я на С# слепил, а вся обработка звука была на С++ в либах. Qt тогда был еще в первых своих зародышевых версиях, MFC раздражал, а борланд уже приказал долго жить.

Ох... Згадав буремну молодість)
Теж колись на одному проекті схрещували UI від дотнету і плюси, схрестили за допомогою СОМ.

Таки вы были еще теми извращенцками. СОМ для оного не нужен был, просто не нужен. СОМ — это вообще безумное изобретение извращенного ума кого-то у мелкомягких.
Я программлю с 1992 и таки пропетлял без проблем мимо СОМа и CORBA.

Не варто було. C++/CLI — ось потрібна технологія їх схрещування. З одного боку — це дотнетна мова, повна взаємодія з шарпом по всім ключовим моментам. З іншого боку — це все ще плюси, можна підключити будь-яку лібу і ганяти дані на повній швидкості.

Ми схрещували пітон, С№ і С++.

Досі працює, вже 11-й рік.

Qt тогда был еще в первых своих зародышевых версиях, MFC раздражал, а борланд уже приказал долго жить.

Это когда же? Борланд окончательно того где-то в 2010м

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

Не будет, даже буст запустится. И экзешники маленькими будут.

Так зомби по определению ходить может, только воняет сильно.

В нас досі на Дельфі живе 18-річний монстрик. І почувається прекрасно, бо переписати це ніхто не може викреслено викреслено не хоче фінансувати, бо кеш і VAR — це різні речі.

Зато C# позволяет такую штуку как дефрагментация памяти, это когда объекты до 80 Кб могут перемещаться сборщиком мусора в один блок из разрозненной памяти с правкой ссылок. При динамическом программировании программа на C# за счет этого может быть намного быстрее супероптимизированной на С++.

Если в C# добавить OpenCL то это вообще превращается в супербронированный танк с возможностью взлета в ближний космос. В результате прямая манипуляция c памятью и MIMD — кодом на OpenCL (который чистый С и только с версии 2.0 C++) и надежность C# во всем остальном.

объекты до 80 Кб могут перемещаться сборщиком мусора в один блок из разрозненной памяти с правкой ссылок

І порахуйте складність такого алгоритму, в кращому випадку ви збільшуєте початкову складність у N-разів. Це ніразу не оптимізація і точно не буде працювати швидше.
Проблему дефрагментації пам’яті вирішить, але працюватиме точно не швидше.

Ну і в плюсах є теж набір інструментів та практик як для уникнення дефрагментації так і по уникненню надлишкових копій і ще купа всього.
Але це все на 95% буде залежати від написаного алгоритму і рівності рук розробника.

рівності рук розробника.

95% разработчиков — рукожопы и им нужен инструмент для перманентного выравнивания рук. В C++, в отличие от C#, базового встроенного инструмента по выпрямлению рук нет. Можно конечно нанимать топов, но команду из топовых сеньоров потянет не любой заказчик.

95% разработчиков — рукожопы и
В C++

нє такіє

Зато C# позволяет такую штуку как дефрагментация памяти, это когда объекты до 80 Кб могут перемещаться сборщиком мусора в один блок из разрозненной памяти с правкой ссылок. При динамическом программировании программа на C# за счет этого может быть намного быстрее супероптимизированной на С++.

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

Хотя, в серьезных игровых движках для ААА игр это все давно уже есть ))

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

Так C# - это уже такой движок

Тюнинговать надо

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

Нужно просто найти вменяемых разрабов

Так C# - это уже такой движок.

Опоздавший лет на 10-15

Так что если у вас не завалялось лишнего миллиарда долларов капитализации на который вы можете взять кредит и запилить свой движок с блекджеком и этими девушками на C++

Чуваки с PhD, литкодщики и те кто много писал код. Миллиард не надо, ну 20-30млн можно выделить что деньги уже не такие и большие.

то C# подходит для любого применения в том числе и для высоконагруженных вычислений.

:D

C# подходит для любого применения

Ох, ну нарешті в нас є мова для будь-якого застосування! Залишилося це пояснити плюсовикам (а також джавістам, джаваскриптистам, пітоністам і всім іншим), а то ж люди не розібралися :)

хоть GPU, хоть AVX512

И там только С, С++ и асм.

OpenCL конвертит код в промежуточный формат нечто типа LLVM и затем уже на конкретной архитектуре этот промежуточный код в код архитектуры.

Так что LLVM круче чем «С, С++ и асм» вместе взятые.

Мда. Что-то обьяснять тебе мне лень. Продолжай верить в Бога.

цікаво, на прекрасному іт буде стаття про кризу середнього віку цепепешника?

Так кризи, як такової, нема.
Є бажання рухатись далі, досягати більшого, працювати цікавіше, отримувати краще.
А з наявною українською ІТ екосистемою я не бачу як цього досягти, от і виніс свої думки назагал.
Історія з фаангами була ситуативною кризою яка вже минулася.

Так кризи, як такової, нема.

буде :)

Є бажання рухатись далі, досягати більшого, працювати цікавіше, отримувати краще.

От з цим от сфейлишся і буде :)

А з наявною українською ІТ екосистемою я не бачу як цього досягти,

Кажу ж буде :)

нє, ну в чувака все є, входить в топ 1% багатих, і йому «щось не те», в дупі шило муляє

може таки сплав по Дніпру, хоча б до Польщі, там і пошуковик, і бізнес машини і мало ще хто

нє, ну в чувака все є, входить в топ 1% багатих, і йому «щось не те», в дупі шило муляє

ІМХО це нормально.

Є бажання рухатись далі, досягати більшого, працювати цікавіше, отримувати краще.
нє, ну в чувака все є, входить в топ 1% багатих

Класика, чим більше є, тим більше хочеться ;)

этот кризис называется руст

Седина в бороду — руст в ребро.

30+ : трактор і сплав по Дніпру

якщо заржавів, і не встає на стару С++ кошолку,
то тре спробувати з Rust молодухою

Сплав по Днепру на тракторе

главное — не забыть баржУ с арбузами

«архітект», «техлід», «СТО» — от навіщо людям ті лички? Кен Томпсон в 60-их був просто програмістом і в 2010 був просто програмістом. При цьому його рівень, безумовно, в сотню разів перевищує всіх тих, хто навішав на себе лейби архітектів та техлідів з якимись смішними десятьма роками досвіду. В С++ середовищі 10 років досвіду — то, фактично, «тільки-тільки скінчилось дитинство».

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

Нема кращих :) Rust, можливо, колись стане, але йому ще потрібно підрости.

Сама по собі личка мало чого варта, варті можливості, які відкриваються за нею.
Я хз як це працює в продуктових конторах, але в українському аутсорсі у тебе в рази більше цікавих активностей якщо ти архітект, порівняно зі звичайним сіньйором. Ти можеш і прототипи накидувати і до замовника частіше покататись і реально приймати архітектурні рішення, а не просто вибирати між вектором і масивом.
Ну і я ще не бачив архітектора, якого б напрягали гавнотасками по типу колупання днями в простинях логів для пошуку і фіксу мінорних плаваючих багів. А от сіньйорів які таким займаються майже постійно бачив предостатньо.

Якщо хочеш просто сидіти і цілодобово генерувати простині коду, то дійсно личка значення не має.

Не хочеш сидіти в лайні і прагнеш кращого — Галя балувана. Кек, ну ок))

я так і не зрозумів, що було зроблено (крім задрочування літкода), щоб «не сидіти в лайні» (я так розумію, це про С++)?

Лайно поняття суб’єктивне.
Для британських лордів вся Україна включно з пшонка-стайл олігархами одне тотальне лайно.
А для пацанчика з райцентру, що вибився в сіньйори з майже топовою ЗП по своєму наряму в Києві, лайно вже давно позаду.

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

вже декілька разів писали: чемодан, вокзал, трактор

зміна місця перебування нічого не вирішує

та як, тут оутсорс лайна, а там няшні проекти

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

Так не буває. Ніде. Постійно доганяє ж.

Якщо хочеш просто сидіти і цілодобово генерувати простині коду, то дійсно личка значення не має.

О, це мрія просто — сидіти і генерувати цілодобово простині коду. І плаваючі баги ловити. Куди більше користі від цього всього, аніж від теревеньок з замовником та накидування прототипів. Бачили ми ці прототипи — «я тут накидав пруф оф консепт на 100 рядків, візьміть і зробіть щоб це масштабувалося на мільйон вузлів з бекапами та аналітикою». Дякую, пане архітекте, дуже допомогло.
А от Ваш браузер, ОС чи прошивка пристрою працює саме тому, що хтось сидів, генерував простині коду та ловив плаваючі баги.

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

То правда, от тільки презентації в паверпоінті — то такий собі «розвиток С++ девелопера» (див. тему топіку).
Я не хейчу архітектів. Зрозуміло, що там бувають круті специ і вони цінні для компанії. Але можна бути просто хорошим програмістом, писати складні речі, отримувати добрі гроші. І таких потрібно десятки на кожного одного архітекта з поверпоінтом і пруф оф концептом.

Це так, але можливості росту вище сіньйора в Україні по тому напрямку дуже обмежені. Особливо в «нішевих» спеціалізаціях. Про то як на мене і весь топік.

Або іди в ліди і потім в менеджери, або бороздити інші технології, все інше — радше виключення.

Це правда, але йти в менеджери не обов’язково. Можно бути гарним сеньйором чи лідом. І розвиватися, вирішувати складніші задачі, вчити молодь, тощо. Просто треба перевизначити для себе поняття розвитку. Це не обов’язково наступна «личка» через пару років. Це може бути такий проєкт, куди б тебе пару років назад не взяли, чи статус мейнтейнера ліби з кількома тисячами зірок на гітхабі, запрошення виступити на CppCon. Та багато чого, крім переходу в менеджери.

Можно бути гарним сеньйором чи лідом.

Можна, але ІМХО там десь і є стеля по досягненню якої не ясно що робити.

І розвиватися

Ну от моя проблема була в тому, що не ясно було куди саме розвиватись, і то не тому що я все-все-все на світі взнав

вирішувати складніші задачі

А вони точно є? От я свого часу якраз і не знайшов.

вчити молодь

то яке має відношення до розвитку? Хіба як для самозадоволення чи як хобі.

Це може бути такий проєкт, куди б тебе пару років назад не взяли,

От на тому я і сфейлився. Брали всюди, тільки я туди не хотів, воно все було гірше за то, чим я займався.

чи статус мейнтейнера ліби з кількома тисячами зірок на гітхабі

Отого нажаль не спробував.

запрошення виступити на CppCon

Пробував в якійсь мірі робити кроки на ту тему, але зіштовхнувся з ти, що того тупо не було треба. Ну може з конторою мені не повезло, може сам «слабкий духом».

3) але не HFT, а простий Fintech / DeFy на Golang / Rust

надо валить! (к) (тм)

* На мою суб’єктивну думку, посередні програмерські скіли, які тим не менш дозволили пройти всі інтерв’ю у ФБ і Пошуковику, фейлився на архітектурі.

Лайфхак: потрать несколько месяцев и пару штук баксов и заботай System Design Interview. Пройдешь в свою ФБ/Поисковик и дальше будет ясно как естественно развивать карьеру.

Алсо, людей, которые фейлят на System Design часто даунгрейдят на левел пониже и все равно дают офер (типа в дизайне он не дуб ногой, но кодить умеет, наймем как SDE1 и научим дизайну). У тебя вообще никакого офера не было? Откуда мысли что с кодингом было все нормально при таком раскладе?

Лайфхак: потрать несколько месяцев и пару штук баксов и заботай System Design Interview.

А можно подробнее, это как?

Тут в деталях в коментах расписывали как готовиться: dou.ua/forums/topic/28593
В двух словах
1) Читаешь книги по System Design типа www.amazon.com/...​_asin_title?ie=UTF8&psc=1
2) Читаешь github.com/...​rtin/system-design-primer
3) Проходишь курсы по System Design и Object Oriented Design типа www.educative.io/...​e-system-design-interview
4) Практика
5) Проходишь mock interview с реальынми интервьюверами
6) Еще практика
7) Идешь на собеседование

З пошуковиком історія була декілька років тому, це була моя перша спроба з фаангом і там, об’єктивно, було слабувато пройдено весь кодинг + завалено архітектура, тому вони, очевидно, не стали ризикувати і я усвідомлюючи свої слабкі позиції не став наполягати ні на чому.
З ФБ була історія рівно рік тому і там сталась реально дика ситуація, здається, описував її тут в темі про тореадора.
Я реально добре пройшов всі етапи і рекрутер пост-фактум це підтвердив, що я всім сподобався і по кодингу та поведінковим інтерв’ю питань не було, але архітектура фейл. Це не мої суб’єктивні домисли, а те, що сказав рекрутер, шкода, що не листом, бо міг би процитувати.
Рекрутер сказав, що вони розглянули мою кондидатуру і вважають, що з моїм досвідом є сенс подаватись не менше як на L5, а по результатам архітектурного блоку я до цього недотягував. Тому комітет не буде пропонувати офер на позицію нижче, хоча це саме те, що я попросив відразу, як отримав відмову.
Саме цікаве, що у мене є хороший друг джавіст теж з Києва, який декілька місяців тому також потрапив в аналогічну ситуацію. Майже 10 досвіду, успішно пройдено кодинг, завалено архітектуру і відмова розглядатись нижче як на L5, бо вже є немаленький досвід.

Випадок із ФБ мені реально тоді дуже сильно дав по мозгам, місяць жостко депресував і довго думав.
Окрім всього іншого, думав про таке: У мене в голові до того моменту була така картина: Якщо захочу терміново валити, попрошусь у якийсь фаанг джуном, джуном влаштуватись відносно легко.
За рахунок досвіду буду перформити, кожен рік рости на +1 рівень і за 5-7 років, якраз під сороковнік, вийду на L5-L6, а на цьому рівні можна сидіти до самої пенсії, якщо будеш норм працювати, то не звільнять.
А виходить ніфіга. Якщо вже працював, то не можеш претендувати на джуна чи навіть мідла. Тільки гра на підвищення ставок.

Суто субэктивно — то може бути не всюди так. І можливо ще залежить від того, як ти продаєш свій досвід і своє резюме.

Ну і нема чого комплексувати через одне єдине інтервю. То може бути навіть не підхід цілого фейсбука а одного єдиного хайрінг менеджера. От тут по сусідству є тема де чувак, і досить досвідчений, і підготований роботу в долині пів-року шукав і ледь знайшов. Там з 20+ провалених інтервю було. :)

Взагалі в отих ваших ФААНГАХ ще та конкуренція і відбір, особливо в порівнянні з українським ринком. Але то не означає що там є щось неможливе-непосильне.

Что мешает подаваться в остальные компании и пере-подаваться в FB/Google? Как я писал, если считаешь, что валишь System Design, это легко испралвяется подготовкой к собеседованию.

Та нічого не заважає, вангую, що до цього врешті-решт і прийду.
Рік тому спрацювали часта психологія, я дуже інтенсивно і довго готувався, дуже сильно хотів отримати офер саме від фб, нехай і на L3-L4, але все ж офер. І коли я пройшов успішно перші чотири етапи кодингу + поведінки, дуже сильно зрадів. Потім був 5 етап і архітектура, яка все обламала.
Після такого жорсткого облому не хотілося не те що нові співбесіди проходити, з ліжка було важко вставати, усвідомлюючи, скільки сил вкладено і що, по суті, технічна частина пройдена добре.

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

Також через рік дуже багато чого починає забуватись з літкоду. Це як із олімпійськими іграми: спортсмен приводить себе в форму, активно тренується, досягає піку своєї форми в момент змагання і потім «здувається». Абсолютно та ж фігня з твоєю інтелектуальною формою.
Одна справа щодня вирішувати якісь технічні та бізнесові проблеми, інша справа тримати в кешах твого мозку найбільш оптимальні рішення найрозповсюдженіших алгоритмічних задач і на таймер задротити ТОП 100 задач по вибраній галєрі.
Само собою, що по другому-третьому кругу згадувати це набагато легше ніж вчити з нуля, але все ж це не так просто.

Також через рік дуже багато чого починає забуватись з літкоду. Це як із олімпійськими іграми: спортсмен приводить себе в форму, активно тренується, досягає піку своєї форми в момент змагання і потім «здувається». Абсолютно та ж фігня з твоєю інтелектуальною формою.

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

Букай 10 собеседований втечение месяца, тебя эти рандомы вообще волновать не будут. Завалил одно собеседование — пох, потому что у тебя уже на руках 2 офера, и впереди еще 5 собеседований.

Букай 10 собеседований втечение месяца, тебя эти рандомы вообще волновать не будут. Завалил одно собеседование — пох, потому что у тебя уже на руках 2 офера, и впереди еще 5 собеседований.

А как быть если забукал 10 собеседований, 5 выиграл и в итоге выбрал только 1? Что делать с остальными 4 если 1 выбор не выгорел и надо опять собеседоваться? Они ж за отказ могут в чс внести =/

Они ж за отказ могут в чс внести

Жодного разу про таке не чув. Занесуть в список якщо твориш дичину якусь на співбесідах, або тупо морозишся і не відповідаєш на листи та дзвінки.

дивні люди, готуватися у ФБ, знаючи що шансів 1:100, отримати відкоша і через це стратади...

з.і.
думаю, що тобі вже рекрутери з FAANG мали б присилати листи щастя, а не ти за ними бігати

До минулого року не мав багато досвіду з фаангами і наївно думав, що маючи десятку не самого фігового досвіду + профільного магістра + інгліш + півроку задротства і об’єктивно добре вирішені задачі, що все це дозволить хоча б weak middle офер отримати.
А воно он як Міхалич виявляється...

це називається «високо літати — низько падати»
або «занадто високо думати про себе»
«ожидания vs реальность»
і т.п.

А воно он як Міхалич виявляється...

А далі ще цікавіше виявляється, бо після того, як ти отримав отой офер в ФААНГ тобі потім ще й в тому фангу всередині карєру будувати і доводит що ти не повне лайно.... А тобі могло здаватись, що ти то вже 10 років як зробив :)

5) Забить на пункты 1,2,4, изучить рынок.Запилить приложение которое «возможно» будет тебя немного подкармливать. Или/И развиваться по 3. IMHO.

Та ладно, що може прогодувати?
Що може зробити один програміст? Написати файловий менеджер?
Єдине, що бачу тут як шанс, це написати якусь апку, яка б вирішувала якусь реальну проблему і оформити це як стартап, залучити фінансування, розвивати і потім з цього заробляти або продати, але це та ж сама фулл-тайм робота, хоча й значно цікавіша, як на мене.

Що може зробити один програміст?

При должном стремлении и усидчивости много чего.

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

Если это не B2B «проблема», то спешить задействовать внешнее финансирование я бы не спешил. Потому как для раскрутки вам и так прийдется отдавать более половины с продаж всякого рода посредникам а тут еще и кредиторы будут забирать остаток.

Схоже питання але в іншому формулюванні задавав на Quora, там колеги зі штатів і європки майже єдиноголосно радили йти в стартапи.

Класна порада. От тілки в Україні то трохи проблематично, хоча, можливо в Києві... :)

Так, в Україні наразі екосистема для стартапів геть не пристосована.

так що заважає віддалено?
як на мене ринок гарячий, як ніколи, HRи в милі, як загнані коні

Йти просто в стартап найманим кодерком не прикольно, в стартап йдуть за долею, бажано, аби ця доля була суттєва. Дуже бажано, якщо в стартапі 3-5 людей і тебе беруть на одну з ключових технічних ролей, то отримати хоча б 10%.

А каліфорнійські пацани ноунейму з України ніколи не запропонують такої великої долі, навіть якщо його візьмуть на позицію СТО і він буде тащити.

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

Йти просто в стартап найманим кодерком не прикольно,

кому прикольно, а кому не прикольно
тільки тре розуміти, що в тебе буде 2Х з.п. але недовго,
або йти розгрібати імно мамонта за Х, в надії що це «стабільно»

в результаті, навіть із «нестабільно з простоями» ти в рік маєш більше чим «стабільно», маєш кучу досвіду в різних нішах,

в другому випадку, ти спеціаліст по закручуванні гайки М5, із шансами бути взятим на вакансію на закручування гайки М4 або М6

Якраз більшість стартапів пропонують 0.5Х ЗП від ринкової з перспективою мати декілька % від продукту, які потенційно можуть конвертнутися в багато сотень тисяч вічнозелених, якщо всі будуть працювати на максимум і в один прекрасний момент вас купить багатий папік.

0.5х ринкової там,
але ти йдеш напряму, без прокладки, і виходить 2Х від того, що з прокладкою тут

якщо є все крім матана, то найпростіше виглядає

3) Псіна з Волл-стріт

ну а скільки там тої математики треба? ну трохи теорії імовірності, лінійного програмування, статистики... найскладніше, що там могло б вилізти, мабуть, — стохастичні дифури для обрахунку опціонів. чесно кажучи, я без поняття, що таке опціони (тільки назву чув), а от зі стохастичними дифурами справу мав — користуватись достатньо просто.

там достатньо знати CS та техніки оптимізації\багатопоточність,
але чому тре темо зводити до торгових ботів, це тільки мала частина фінтеха

так и есть, математика такая себе, кстати нелинейки в финансах тоже дофига, там где деривативы 3-го порядка или всякие сидио сидиошек. за год-два вполне можно осилить

Що мислить спільнота?

Чудовий аналіз, згоден практично з усіма висновками. Сам відчув на своїй шкурі практично те саме один в один.

Ще таки є варіант с ФААНГАМИ. Ну вивчи ти той системний дизайн і таки попробуй.

Ну і щодо Фінтека — там кажуть є і протсто кодерські позиції, де трошки меньше треба математики ніж для отих «квантів». Але дорбе за то платять переважно лише в Лондонах-Амстердамах. Хоча в Україні подекуди теж якісь такі позиції проскакують.

ML/Computer Vision, трейдинг, бекенд є. Кріпта різна. Мені от у медицині платять непогано. У GPGPU домені як на мене є цікаве і де платять.
По трейдингу я мав декілька співбесід на Україну і декілька за кордон. Хедж фонди таки дуже винаймають, там система десь як фаангах.
Ну і якби не С++ єдиним, на хайпі Расту можна позбирати, та й інше.

Нажаль, архітекторів які б спеціалізувались на плюсах я не бачив.

Превед, узри меня.

Алсо, тебе не язык нужен, а технологии; и даже не технологии, а специализации.

Дуже-дуже мало проектів пишуться з використанням всієї сили метапрограмування і супер-складних багатопотокових рішень з неблокуючими структурами даних.

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

Псіна з Волл-стріт

Бред. Ты не экономист/трейдер.

Тех/Тім Лід — Проджект/Продукт менеджер — Програм/Аккаунт/Сайт менеджер — Делівері директор — СТО.

Кроме техлида и СТО, все перечисленные являются дауншифтингом в начало другой ветки развития персонажа.

Що мислить спільнота?

—>

* Дуже мінімальний досвід з іншими технологіями, окрім плюсів.

Критический недостаток. Учи Qt, Boost, GStreamer, нетворк стек, вайфай стек, жосткий риалтайм...

Критический недостаток. Учи Qt, Boost, GStreamer, нетворк стек, вайфай стек, жосткий риалтайм...

А смысл вот так брать и учить? Ты чуть выше правильно написал что

и даже не технологии, а специализации.

Определяешься со специализацией — разбираешься с теоретическими знаниями, фреймворкаим и тулсетом (итд) под эту специализацию.

Определяешься со специализацией — разбираешься с теоретическими знаниями, фреймворкаим и тулсетом (итд) под эту специализацию.

А потом лет через пять выясни, что под твою специализацию была аж одна вакансия во всем городе :) Знаем, плавали.

А смысл вот так брать и учить?

Ты не поверишь, сколько раз я был в ситуации «вот только тот чувак что-то знает про технологию X»

«вот только тот чувак что-то знает про технологию X»

и специализация это разные вещи. В том же твоем списке

Учи Qt, Boost, GStreamer, нетворк стек, вайфай стек, жосткий риалтайм...

— Qt — Кросплатформенный фреймворк, С++.
— GStreamer. Чистый С, плюсов там и близко нет. Может как пересекаться с Qt (входит с состав сборки для линукса) так и быть отдельной сущностью.
— нетворк стек — define it. До какого уровня учить. Знать/уметь работать с сокетами + свои протоколы выше L4 OSI? Или уметь реализовывать свои сокеты и протоколы в ядре? Как нетворк стек и экспертные знания в нем связаны с Qt и GStreamer? Понятное дело что оба используют сетевые API в глубине либ, но мы то говорим о специализации, то есть знаниях о потрохах чуть более широких, чем умение вызвать socket(), bind() и select()
— вайфай стек — define it. Имеешь в виду IEEE 802.11? Если да, то стандарт описывает только MAC и физику (PHY) и является частью network stack (предыдущий пункт). Писать прийдется на уровне ядра и/или прошивки для MCU or FPGA. Не пересекается с Qt и GStreamer.
— жесткий реалтайм — это вообще что за зверь? Чем жесткость определяется? Рилтайм системы всего-то должны гарантировать реакцию системы на внешнее событие или воздействовать на внешнюю среду в заданных временных рамках. То есть если задано время реакции 1 сек., это уже жесткий рилтайм или еще не очень? Как оно соотнисится с тем же Qt и Gstreamer?

P.S. : из приведенного тобой списка, я не работал только с Boost и вайфай стек. Правда вместо вайфая приходилось писать драйвера модемов (L1/L2) для децентрализованных радиосетей, так что релевантный опыт имеется. Из всего тобой вышеперечисленнго хоть какую-то связанность имеют Qt и GStreamer. Далее по списку, нетворк стек включает в себя wifi стек и очень-очень слабо (на уровне POSIX API) пересекается с Qt и GStreamer. За жесткий рилтайм пока не пишу, не понятно что ты имел в виду.
P.P.S: надеюсь мне удалось донести, что я пытался сказать фразой

А смысл вот так брать и учить?

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

GStreamer. Чистый С, плюсов там и близко нет.

Есть биндинги.

— нетворк стек — define it. До какого уровня учить. Знать/уметь работать с сокетами + свои протоколы выше L4 OSI? Или уметь реализовывать свои сокеты и протоколы в ядре?

Понимать как работают современные сети в первую очередь. Какие есть подводные камни и т.д. Грубо говоря, есть вакансии на разработку сетевой аппаратуры.

— вайфай стек — define it. Имеешь в виду IEEE 802.11? Если да, то стандарт описывает только MAC и физику (PHY)

Нет, лол, не только. И да, в 802.11 куча разных подстандартов (буковки после номера).

— жесткий реалтайм — это вообще что за зверь?

stackoverflow.com/...​l-time-and-firm-real-time

P.P.S: надеюсь мне удалось донести, что я пытался сказать фразой

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

Нет, лол, не только.

А что еще?

И да, в 802.11 куча разных подстандартов (буковки после номера).

Те буковки описывают подстандарты реализации МАС и PHY. Но 802.11 вне зависимости от буковок — он весь про МАС и PHY.

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

Тут согласен, T-shape как по мне, нормальный подход.

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

Класный план. Я как-то так и думал, но
1. насколько широкий кругозор надо иметь то? Джаваскрипт и веб програмирование в него к примеру включать?
2. А как выбрать специализацию? Ну по хорошему надо смотреть на то на что есть работа, сейчас и в будующем. Ну и на то, что наравится. Но как — х.з.

— жесткий реалтайм — это вообще что за зверь? Чем жесткость определяется? Рилтайм системы всего-то должны гарантировать реакцию системы на внешнее событие или воздействовать на внешнюю среду в заданных временных рамках. То есть если задано время реакции 1 сек., это уже жесткий рилтайм или еще не очень? Как оно соотнисится с тем же Qt и Gstreamer?

Real time не имеет отношения к времени. Это характеристика системы — «предсказуемость». Например, доставка результата не более чем за 5 секунд — это уже система реального времени. Далее есть разделение по ценности результата — есть жесткие real time, когда промедление недопустимо (управление АЭС — при задержке сигнала управления необходимо принять другие меры гарантирующие безопасность), либо мягкие, когда промедление лишь снижает ценность результата (предсказание погоды для гражданских, компьютерная игра, ...)

Это характеристика системы — «предсказуемость».

Я в курсе ))Там следующим предложением

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

Интересовало что вкладывает в это понятие уставший архитектор.

— GStreamer. Чистый С, плюсов там и близко нет. Может как пересекаться с Qt (входит с состав сборки для линукса) так и быть отдельной сущностью.

Если ТС познает его в деталях и запросто научится плагины к нему разные писать, то от 8-10 кусков денег в месяц ему гарантировано.
Пока даже у разрабов говностримера очень туго с написанием плагинов для него.

Если ТС познает его в деталях и запросто научится плагины к нему разные писать

Тянет на специализацию )) Только чтоб не получилась ситуация как эльф описал: потратит кучу времени а потом выяснит что на рынке пара-тройка заказчиков.

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

Там вся сложность в том, что на С разрабы реализовали ООП (закатывают солнце ручками с виртуальность, реализованной на С) и в качестве документации его исходники (жуткие).

Нормальные люди обычно юзают ffmpeg — он много приличнее гстримера и тоже на С. Но у гстремера юзание чуть интереснее — графы строятся удобнее.

Например, для Джетсонов нвидия просто переписала гстример для питонистов. Причем ты можешь на питоне достаточно просто встроить свою нейронку в пайплайн. Это удобно для питонистов — проблема в том, что кроме десятка плагинов гстримера остальные разной степени глючности.

Это удобно для питонистов — проблема в том, что кроме десятка плагинов гстримера остальные разной степени глючности.

Good, bad and ugly деление они неспроста ввели ))

Именно, только оно пошире чуть уже.

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

Ну и сам сейчас мендиа стриминг сижу ковыряю

В каком направлении, если не секрет?

Да как бы что на работе есть то и ковыряю. WebRtc, его совместимость с нашим собственным поделием и всякие там компатибилити фичи между ними.

Ну ок, припустимо, абстрактний погроміст із Мухосранска опанував в деталях GStreamer і навчився писати плагіни до нього, що далі?
Чи дійсно на ринку є така величезна необхідність в плагінах, що контори готові платити десятку? Чи є десятки і сотні таких вакансій?

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

Ну ок, припустимо, абстрактний погроміст із Мухосранска опанував в деталях GStreamer і навчився писати плагіни до нього, що далі?

Это неправильный подход. Правильный подход: сначала смотришь рынок и потребность в плагинах, потом решаешь стоит тебе тратить время на это или нет.

Определяешься со специализацией — разбираешься с теоретическими знаниями, фреймворкаим и тулсетом (итд) под эту специализацию.

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

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

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

Изучение чего-то «вширь» облегчает твое положение на рынке — предложений море, но ты не можешь стать специалистом.
Изучение чего «вглубь» усложняет твое положение на рынке — предложений мало, но ты можешь стать специалистом.

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

З.Ы. И еще момент психологического плана. Тратить свою жизнь на то, что не интересно мне не нравится. У меня есть всего около 65-70 лет пока я живу. А если прикинуть время полноценной жизни, а не овощем, то это вообще около 30 лет всего.

що далі?

Пойти в сильпо. Взять 2 литра Оболони и удовлетвориться.

и удовлетвориться.

само

Пчолы или виндсерфинг воть тру выбор

То есть если задано время реакции 1 сек., это уже жесткий рилтайм или еще не очень?

Если заданно жестко то жесткий :)

Как оно соотнисится с тем же Qt и Gstreamer?

С QT не очень, а Gstreamer «мягкий».

Чувак просто перечислил все то с чем сам работал, это его «путь к успеху» который должен повторить каждый. Не знаеш QT-не синьёр :)

Превед, узри меня.

А де працюєш? Є ще такі як ти? Є вакансії)?

На самом деле — достаточно.

З того всього кровавого ентерпрайзу що бачив, майже завжди можна обійтись простішим рішенням без втрати перфомансу.

Бред. Ты не экономист/трейдер.

Тут вже ти не правий.
Економісти і трейдери торгують і створюють теорію, програмісти пишуть платформи і засоби, де трейдери торгують.

Критический недостаток.

Так, з цим згоден.
Трохи працював з Qt але давно і ще до 5 версії, Буст нафіг не потрібен після 11, а тим більше 17 стандарту, з нетворком трохи працював.
Ріалтайм теж мав досвід, автомотів у епамо-люксофтах кодив, там QNX був, тому уявлення маю.
Також було декілька простеньких проектів з ембеддедом.

В цьому питанні я досить критично ставлюся, не згадую всі базворди які колись зустрічались в проектах, а пишу лише те, по чому можу повноцінно пройти сівбесіду і зробити проект прямо вже.
Бо якщо писати все, що колись раз-два доводилось трогати руками, то список абревіатур буде на А4 листок і охоплюватиме всі існуючі напрями в ІТ, хіба може окрім квантових обчислень.

А де працюєш?

Деанона не будет

Є ще такі як ти? Є вакансії)?

Есть, все есть.

З того всього кровавого ентерпрайзу що бачив, майже завжди можна обійтись простішим рішенням без втрати перфомансу.

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

Економісти і трейдери торгують і створюють теорію, програмісти пишуть платформи і засоби, де трейдери торгують.

С т.з. программиста — это еще лишь одна специализация

Трохи працював з Qt але давно і ще до 5 версії, Буст нафіг не потрібен після 11, а тим більше 17 стандарту, з нетворком трохи працював.

Так, ваш уровень — миддл, вам еще расти и расти.

Так, ваш уровень — миддл, вам еще расти и расти.

Дайте визначення сіньйора тоді.

знаешь плюсы лучше страуструпа

Просто знать язык — этого очень мало. Не знать что в бусте очень важен асио — очень плохо. «Трогал куте4» практически означает что были заюзаны только QtWidget, а не QML (алсо сейчас уже куте6 вышла если что)

Якраз qml активно «трогав»)) Але віджетів там дійсно було багато.
В мене був тоді досить великий проект, просто використовувалася 4.Х версія, що є вже застарілою. Майже 2 роки писали.
Просто знати синтаксис цього дійсно замало, варто знати де і як його варто застосовувати, ось це і є сіньйорність.

Якраз qml активно «трогав»)) Але віджетів там дійсно було багато.
Трохи працював з Qt але давно

Так давно и немного, или активно трогал?

використовувалася 4.Х версія, що є вже застарілою

Различия есть, но не критичные.

Просто знати синтаксис цього дійсно замало, варто знати де і як його варто застосовувати, ось це і є сіньйорність.

Нет, синьорность — это знание подводных камней и способность их избегать заранее.

Нет, синьорность — это знание подводных камней и способность их избегать заранее.

Нет, это всего лишь знание и опыть с конкретными тулзами. Синьёрность — возможно то же самое но в предметной области, в отрыве от тулзов.

Майже 2 роки писали

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

куте6 вышла если что

обгрызенная покашо. ждем 6.2

якщо маєш більше 4Куе в місяць — вітаю, ти сенйор

Тільки якщо не девопс чи фронтовик)) Там зараз вже мідлів на 4 беруть.

Цепешника можна куди завгодно кинути, зміг з плюсами розбратись, зможе і з іншим дєрьмом))))

Мене якось так і найняли, була вакансія з купою непов’язаних між собою баззвордів технологій, серед яких були і плюси.
На мій аргумент, що я працював тільки з плюсами, мені так і сказали: «Зміг з плюсами, зможеш і з рештою».

Ще й паралельно полагодити стільця, бо він комп’ютерний.

Подписаться на комментарии