×Закрыть

Как покорить C++?

В общем такое дело, решил пойти на программиста. Учусь уже 2 год на компьютерной инженерии (немного промахнулся со специальностью, но не суть), заинтересовался с++, такой вот вопрос для тех, кто испытывал на своей шкуре этот язык. Какие можете дать советы в осваивании языка? Как быстро можно будет попасть на работу, сколько времени придется потратить...
В общем хотелось бы услышать советов от компетентных людей.

LinkedIn

Лучшие комментарии пропустить

1) Английский (American English Centre, к примеру). Походить на разговорные группы. Нужно свободно читать тех литературу.
2) Не брезговать С при поиске работы.
3) ООП, архитектура, хотя бы банду четырех.
4) Многопоточность (pthread), межпроцессное взаимодействие, сети.
5) Линух.
6) Если новые стандарты не влазят — выучить старый С++03.
7) Начинать с Питона — на нем раз в 5-10 быстрее тренироваться. Научившись програмить на Питоне — переходить в С++.
8) Свой проект (мини-игрушка вроде арканоида или танчиков).
9) Я читал C++ in Action: Industrial Strength Programming, Stroustrup C++, C++ FAQ Lite.
10) Современные операционные системы Таненбаума.
11) Алгоритмы Седжвика.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Совсем забыл, есть же простой способ выучить С++ за 21 день:
i.redd.it/nlwn31r0yg021.png

основные проблемы в с ++ - не очень хорошо с удаленной работой и с обьемами рынка , так что либо готовиться к релокейту (english тут в помощь, да), либо к довольно скромной, хотя и интересной жизни.
с другой стороны после с++ можно переходить в любые другие языки без вопросов (хоть с фигурными скобочками, хоть нет) , а умение успешно нырнуть в код мускуля или там php extension иногда очень полезно , да и просто подправить что-то в Makefile
в общем я бы рекомендовал так — если мозги позволяют — изучать с++ (и даже асм) — эти знания будут полезны и через много лет, но как язык для зарабатывания на жизнь он так себе, особенно если вы не гений виртуоз.
п.с. сам работал лет семь на с++, потом свалил в highload php

не знаю — вроде свои 3-4К у синьора будут

ну я про это. при том что удаленно работающие мидлы на php делают больше

ДОУ калькулятор об этом знает?

только догадываюсь что такое доу калькулятор, так что врядли.
когда-то кто-то делал альтернативный «калькулятор», выгребая инфу из апворка

на апворке PHP дороже, чем С++?

бывает. но очень редко и довольное мутные заказы

проблема в том что на апворке с++ почти нет

Все верное, но до С++ синьора еще на «джуниорских харчах» работать и работать , и на каждый осилит.

Думаю, 600-900 баков у номального джуна будут, если рынок за 10 лет не сильно просел.

Бачив 1.5К вакансії С++ джуна в Києві, так що 600 це більш ніж реально навіть в регіонах

фігасє
а що вони хочуть щоб знав?

jobs.dou.ua/...​bit-labs/vacancies/81331

Вже неактивна
Хоча я бачив ще десь іншу, теж трохи отетерів

1) 800 дадуть)
2) хочуть C + PHP + HTML. Досить дивний стек для джуна.

cgi + бекенд +фронденд, тобто фулстек С++

фулстек джун?
фулстек С++?

www.quora.com/...​d-why/answer/Ian-Joyner-1
C++. It is an awful language that took the archaic C syntax with the semantic flaws in C and multiplied them. C syntax is not a regular context-free grammar. The semantics gets worse.

On top of that C++ adds heaps more accidental complexity. It obscures object-oriented programming.

Dijkstra said “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.”

Well actually, the use of C++ cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

Programming should aim to be simple — take a small set of sufficient constructs, but C++ aims to put everything in by the kitchen-sink approach. Its supporters say this is because it is multi paradigm.

Забыл о том, что С++ — это пришили 8 ног к собаке, чтобы быстрее бегала, а в С++11 число 11 обозначает дополнительные ноги в новом стандарте

:)
нє, 11, це два костиля, а не ноги,
це я канал «1+1» називають «ГеплюсГе»

Для выучивания разговорного английского появилась очень злая идея:
Комментировать постоянно себе под нос на английском языке все-все-все что ты делаешь за компьютером. Ибо нужна практика постоянная разговорного английского + в случае неуверенности в произношении или толковании или переводе слова проверять себя по гугло переводчику.

открой любой курс по си++ на ютубе даже индусский и просто повторяй за ним

Или так

Когда-то в Киеве было полно бесплатных разговорных групп. Искались по объявлениям в газете KyivPost. Вот начинаешь ходить в 3-4 таких в неделю, потом вечером едешь в трамвае — и кажется, что все вокруг разговаривают на английском. Думаю, это — самый реальный вариант пробить языковой барьер без финансовых инвестиций.

Мне ходить долго трудно — ноги болеть начинают почти сразу.

Я в игры ММО играю ... вступаю в «европейские» гильдии, чтоб русского не знали..
Теперь свободно разговариваю ...хотя, как оказалось, обсуждать брексит с бритами все-же трудно )) не хватает слов.

Щоб реально вивчити мову на високому рівні-треба закінчити іняз,і не заочно.Все інше досить приблизно)Така правда,на жаль.

Очень советую для начинающих книгу Дейтелов, отличный самоучитель, то что надо для студента

Начни с простого. Там выше и ниже тебе советуют книги. Это очень правильные и полезные книги, но сначала тебе нужна минимальная база. Вот тебе ссылка. Лично мне этот курс для новичков очень зашел, заодно поймешь по душе ли тебе этот язык.
stepik.org/course/363/syllabus
И скажу сразу, С++ очень универсальный и быстрый язык, который я люблю всем сердцем. Но разбираться в его тонкостях весьма долго. За то, ты получаешь высокую вычислительную производительность. Да и вообще тотальный контроль над всем, что происходит в твоей программе. Как по мне, то это офигенный опыт — писать программы на плюсах. Плюс ( мда, тавтология ) это единственный путь в нормальный геймдев.

якщо не передумав — то ось це от
dou.ua/...​rums/topic/27658/#1615437
а якщо ще є сумніви — то дивися в сторону Python чи Go

Є великий шанс «промахнутися» вдруге... ;)))

Якщо підкорювати — Assembly
Якщо знати — С
Якщо писати «код» — С++ books
Для кожного підходу буде різний план.

У плюсов только два плюса — в названии.
Шучу, это мой любимый язык.

Из ресурсов хочу посоветовать More C++ Idioms: en.m.wikibooks.org/wiki/More_C++_Idioms
Весьма помог в своё время понять приёмы плюсов.

Ну и конечно же C++ Core Guideline: github.com/isocpp/CppCoreGuidelines
Тут собраны, наверное, все best practices и советы, как не стоит делать.

Я обычно начинающим советую не браться за плюсы, жизнь боль. Их невозможно выучить, только изучить в какой-то мере, да и то, если тратить на них чуть ли не всё своё свободное время. Плюсы не для слабых духом. Я предупредил.

З приводу що вивчати для плюсів.

Головне правило — обов’язково треба і читати літературу, і писати код. Окремо воно нормально не працює, тільки разом. Перша книжка, певно, може бути будь-якою (в мене от Шилдт був), але далі варто перечитати класику: Дизайн та еволюція C++ від Страуструпа — допоможе зрозуміти чому C++ такий, саме який він є, Мова C++ від нього ж, не раджу як першу книгу, заскладна як на мене, але прочитати варто. Мейерс: Ефективний C++, Ефективніший C++, Ефективний STL. Читається дуже легко. Обов’язково треба почитати щось по контейнерах-алгоритмах-ітераторах. Для шаблонів існує чудова книга Шаблони C++ Вандервуда й Джосаттіса. Для практики — дивитися код Boost.

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

З не-плюсового варто перечитати Clean code Макконела й Банду чотирьох.

Підтримую. Майєрс — мастхев. Саме завдяки його книгам я почав насправді розуміти плюси.
Після старих книжок також варто почитати «Effective modern C++» — там такі ж поради, тільки стосовно використання фіч C++11/14.
Я б також до цього списку додав «C++ Coding Standards» Саттера і Александреску. Теж дуже корисна книга і легко читається.

І ще варто послухати лекції тих же Майєрса і Саттера, записані на різних конференціях (якщо можеш сприймати англійську на слух; якщо не можеш — займайся англійською паралельно з програмуванням).
Вони не тільки хороші автори книг, а ще й чудові доповідачі.

обов’язково треба і читати літературу, і писати код

І читати код. Саме це доведеться врешті решт робити найчастіше

Какие можете дать советы в осваивании языка?

Вчити Java і забути про плюси.

Если бы ты работал продавцом в магазине и покупатель спросил, свежий ли у вас хлеб, — ты бы тоже ответил «покупай мясо и забудь про хлеб»? :)

ты бы тоже ответил «покупай мясо и забудь про хлеб»?

Аналогія некоректна.

Надаю коректну аналогію:
Якби я працював продавцем в м’ясному магазині і покупець у мене запитав би «а у вас є капібари?» то я би йому відповів «капібари дорогі, та в південній америці, нашо воно тобі треба якщо у нас є норм свинина? купи свинини, вона простіша в приготуванні, дешевша та більш популярна у кулінарів. Повар зі скілами приготування свинини ніколи не пропаде. А от з капібарами є звичайно екзотичні ресторани, але нашо воно тобі треба?».

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

норм свинина

свинина не кошерна

Повар зі скілами приготування свинини ніколи не пропаде

будет делать отбивные в забегаловке «у тети светы»

свинина не кошерна

та шо ви мінє говорітє? в нас повна країна шабесгоїв, їм ж треба шось їсти?

будет делать отбивные в забегаловке «у тети светы»

Швидше працювати в макдаку або кфц.

В капібарщиків теж своя ніша, ресторан єшак, але там платять майже так само як в макдаку, і мережа маленька.

та шо ви мінє говорітє? в нас повна країна шабесгоїв, їм ж треба шось їсти?

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

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

А может и подходить, вдруг человек в детстве на петровке увидел книжку «Готовка капибар за 21 день с нуля» и теперь ему капибары прочно засели в голову, а о свинках с коровками он даже не помышляет.
Наше дело — проинформировать.

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

Прекрасный язык и почти весь кор в приложениях как писался на нем, так и будет создаваться дальше.
В нем много артефактов, многие вещи, которые в нем есть не приедтся использовать в жизни.
Соответсвенно, чтобы начать писать на нем достаточно инвестировать небольшое количество времени, не больше, чем в других языках.
Чтобы стать профессионалом придется инвестировать в него пол жизни.
Важна также предметная область — это кор алгоритмы с особыми требованиями к производительности и скорости. Соответсвенно в этом надо плавать, чтобы эффективно использовать его.
Работы на рынке вакансий на плюсах много даже в Украине, посему считаю отличным выбором.
Моя первая работа была как С+±разработчик, но потом перешел в .net, потому что как любой молодой человек тяготел к новому, а тогда .net 1.x только появился, но С++ как первая любовь)

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

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

И потом отстрелить себе пол-лица при первой попытке менеджерить память. :)

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

После перехода с питона на С++

Ну может в кофе машинках для которых ембедщики пишут код время жизни ресурсов и легко определить, то в чём-то сложнее боюсь не все так «однозначно».

Это «первая попытка» должна быть с распределением владения ресурсом между несколькими потоками или по сети??
Кстати, от такого попахивает.

С++, но зачем?
Язык достаточно устарелый, с огромным багажом легаси (из-за теперь архаической «совместимости» с С), и кучей так и не решенных проблем (пример: compile time, memory safety, undefined behaviour)
Да, на нем можно много чего написать, но все тоже самое можно гораздо быстрее, и качественнее написать на чем-то другом.

Посмотрите, лучше на Rust, Go, D, Kotlin-native, если хочется чего-то без VM, и со сравнимой скоростью.

Вы наверно не в курсе, но С++ уже давно не совместим с С. Примерно сразу после того как ключевое auto нашло свое применение.

Почти любой С код С++ компилятор скомпилирует и часто получше С++ кода.

int try = −2;
foo( a, b )
int a;
int b;
{
return a+b+try;
}
int main()
{
return foo(1,2,3);
}
/*продолжать некомпилируемый с из с++ код можно бесконечно, а еще есть разное поведение одинаковых конструкций и стандартной библиотеки*/

Последние стандарты С такое еще поддерживают?

Должны:
onlinegdb.com/ByEo7KOgB
Ведь еще много кода осталось в этом стиле.
а какой из 4х непортируемых моментов смутил?

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

3й аргумент в вызове функции. Даже для древнего С это очень некрасивый трюк.

Остальные постольку поскольку. Просто читать не очень удобно такое нынче.

ну потому что это говнокод когда ещё он был актуальным ))

ЗЫ: насколько я помню эти ранние диалекти си там аргументы в сопоставлении имени функции вообще не участвовали только само имя. но это кажется было ещё до ansi c. т.е. вероятность встретить такой код на этом уровне развития программиста крайне пренебрежительно мала ))

Я тоже уже не помню, это очень древнее.

но всегда можно потыкать палочкой ))

... и я добавил

foo(a, b, c)
int a;
int b;
int c;
{
return a + b + try;
}

... и ты не поверишь ))

1>\test1.c(9): error C2084: function ’int foo()’ already has a body

Синоним

Так С99 такого уже вероятно не позволяет

И на смартфоне очень геморно с С. Я я сейчас на отдыхе.

Под Варной, в Болгарии?

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

В С++ еще тот зоопарк с манглинггом и стеком и регистрами при вызове функций. И его полезно знать.

Но я писал об андроеде и С.

Потому мне плюсы и нравятся :) Столько всего нового и всё полезно знать.

Ошибка потому что в С в отличии от С++ никогда не было задумано перегрузки функций. И аргументы даже не входят в сигнатуру. От того всякие подобные глупости были возможны и более того на них основаны семейства функций с переменным числом аргументом типа printf, scanf етц.

керниган и ричи же ...
название_ф
{
переменные;
действия
}

параметры при вызове сопоставлялись переменным по порядку объявления.
До сих пор такой код в опенсорсах есть ... точнее, параметры у ф. уже есть, но сразу в начале тела — весь блок объявления локалок.

скорее всего поддерживают у сей суровая обратная совместимость. по крайне мере vc2017 это компилит линкует запускает и дебажит ))

О біже мой! І скажіт, добрії люде, і чим це краще від джава-скріпт?

еще задолго до auto не совместим. например sizeof(’a’), рекурсивный вызов main, обязательные прототипы функций в с++

И че интел сво либы не пишет на расте и подобных

Потому что у них овердофига С++ спецов и С++ кода, и перепрыгивать на молодую технологию не только стрёмно, но и крайне дорого?

Нет. Просто тонкую оптимизацию под железо ты сможешь сделать только на С,С++ и асме.

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

Гугл вот говорит, что Rust и С крайне близки по своим возможностям. А мой опыт с С и ASM говорит, что в плане

тонкую оптимизацию под железо

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

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

Сколько занимает места рантайм Раста? Он портирован под все архитектуры?

а для чого «всi архiтектури», а С++ портований на всi, точно-точно на всi?

Він зараз майже усюди, де є С. А С — усюди.
А Раст схоче кілобайти (чи мегабайти?) флеша та оперативи.

де є С

про плюсовый рантайм не забудь, он тоже есть.

Вроде, можно порезать до десятков килобайт. Для С, конечно, еще меньше.

На поочти все, но часто обрезанный

compile time, memory safety, undefined behaviour

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

со сравнимой скоростью

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

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

Это реальные проблемы, из-за которых C++ из языка общего назначения стал нишевым. Ну и причина появления кучи новых языков, где описанных проблем нет by-design

И когда упоминаете «переиспользование С++» библиотек, не забывайте упоминать, что из-за отсутствия abi, переиспользовать можно только то, что имеет «С интерфейс». И переиспользовать его можно хоть из python

Ну и причина появления кучи новых языков, где описанных проблем нет by-design

ага, в реализациях банальной сортировки везде unsafe торчит

Это не проблемы. Это фича.
Это способо получить переносимые программы на не переносимом языке. Типа, как «виртуальная машина ява», а в С++ это «undefined behaviour». Для той же цели.

Устарелый язык это Фортран с Коболом, а С++ бодрячком держится. Во многом благодаря Qt конечно, особенно для UI на десктопе и в embedded, но тем не менее — это часть эко-системы, которая обеспечивает и скорость разработки, и качество. Оно еще и портабельно, ко всему.

Qt став платним, так що одна з причин, чому вiдмовляються вiд нього.
А так таки так, Qt — саме краще що було з С++

Qt став платним, так що одна з причин, чому вiдмовляються вiд нього

Это, скажем так, не соответствует действительности. Большая часть Qt доступна по лицензии LGPL. Платить надо за киты под embedded платформы, а также за некоторые тулзы и части фреймворка, в основном тоже актуальные для embedded-применений. Под десктоп практически всегда хватает того, что есть под LGPL. Подробнее здесь: www.qt.io/download (там сравнение фич по коммерческой/опенсорс лицензии).

tnx, я в embedded, тому про Qt в embedded, а на десктоп писати на С++, то взагалi дивно

Ну кому как. Вот глянул у себя — uTorrent, Skype, Chrome с FireFox конечно же, Far, LibreOffice, да и MS Office не сомневаюсь — на плюсах написаны, кроме этого MiniTool Partition Wizard, VirtualBox UI, Telegram с Viber, 2Gis — к тому же на Qt.

в Skype на C++ только ядро, вся оболочка, начиная с 8й версии, написана на Electron.

В LibreOffice, насколько помню, бОльшая часть написана на Java.

Viber — опять же, ядро, возможно, и на C++ (ибо видеозвонки), но оболочка явно попахивает Электроном или чем-то подобным.

FireFox по крайней мере частично переписывается на Rust.

Viber — опять же, ядро, возможно, и на C++ (ибо видеозвонки), но оболочка явно попахивает Электроном или чем-то подобным.

«Чем-то подобным» это QML :-) И кстати, LibreOffice, если там действительно UI на Java, как и SmartGit хорошо иллюстрируют, почему не надо UI делать на Java — бо тупит и память жрет шо капец. Не будь как SmartGit. Будь как QtCreator )

Viber десктопный это тот же электрон только в исполнении на Qt. QWebEngine или как оно там называется. Тот же хромиум движок в общем

почему не надо UI делать на Java — бо тупит и память жрет шо капец

XMind 8 — не тупит и память жрёт в разумных пределах ;)

Но, соглашусь, что делать UI на Java не стоит. Правда, совсем по другой причине — JavaFX хоть и отдали в комьюнити и продолжают развивать, но технология особой популярности не получила. Хотя энтузиастам и удаётся «выжать» из неё весьма пристойные результаты: XR3Player

Правда, был когда-то ещё Swing... но ИМХО его удел — это GUI типа таких: i.imgur.com/TJahnkV.png

Только вот мода на такой GUI прошла эдак в середине 2000х :)

Будь как QtCreator

Поздно, батенька :) JavaScript и Electron уже скушали изрядный кусок рынка desktop-приложений. За ними подъедает WPF в корпоративном и банковском секторе. Теперь вот ещё кросс-платформенная Avalonia подтягивается.

И всё это на языках с автоматической сборкой мусора, гораздо более низким, чем в C++, порогом входа, и очень богатым выбором сторонних библиотек. Что этому может противопоставить Qt — мне пока не очень понятно.

Что этому может противопоставить Qt — мне пока не очень понятно.

У Qt давно есть QML — декларативный язык на основе Javascript и рендерингом через OpenGL (или DirectX через Angle). Архитектура MVC подобная, где View это QML код, а Model-Controller могут быть как QML (JS), так и C++. Работает везде, и если бы не JS, было бы даже приятно писать))

если бы не JS

Так а какой же тогда смысл в QML? :) Мой поинт, как раз, в том, что на JS пилить GUI сильно быстрее и проще, чем на «плюсах»

А, если JS, то чем QML лучше / удобнее Электрона? В последнем-то стандартный HTML5, а для QML нужно свой язык разметки учить.

Qml лучше оптимизирован, и имеет существенно более скромные требования к железу. Где-то у них на сайте был white paper, где анализировался реальный кейс «Компания А» против «Компании Б», производителей бытовой техники, и где выигрыш QML по сравнению с HTML5/JS был в 4-5 раз, по скорости запуска приложения и требованиям к CPU/RAM. Ну и доступность фреймворка Qt, тоже добавляет плюшек — он же как дотнет по функционалу.

Qml лучше оптимизирован, и имеет существенно более скромные требования к железу.

Это хороший аргумент, и, всё же — в 2019 году, он имеет значение, разве что, для каких-нибудь информационных киосков или прочих встроенных систем. Возможно, ещё для какого-то очень специализированного ПО с жёсткими требованиями по отзывчивости UI.

Если же говорить о личных и рабочих ПК и ноутбуках и приложениях для массового рынка, то дорогая цена за найм и работу C++ / Qt специалиста, скорее всего, не оправдает экономического эффекта от оптимизации. Достаточно мощное железо вполне доступно по цене, и никто не будет заморачиваться, чтобы выпущенное в 2019 году приложение без тормозов работало на железках десятилетней давности.

Производительность всегда важна, если она позволяет сэкономить. Сколько будет в деньгах, если на железо можно потратить на пару долларов меньше, на партии из миллиона штук? Может все же, в Qt «что-то знают», если вполне успешно развивают свой продукт уже -надцать лет, поддерживают два релиза LTS и еще и на этом зарабатывают?

партии из миллиона штук

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

Может все же, в Qt «что-то знают», если вполне успешно развивают свой продукт уже -надцать лет, поддерживают два релиза LTS и еще и на этом зарабатывают?

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

Но вот называть Qt технологией выбор для нового массового десктопного софта в 2019м я бы точно не стал.

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

Во-первых, таких, как вы — единицы. А, во-вторых, это только при условии, что «старый, но рабочий» софт вообще существует в природе.

Для моих задач существует.

Разумеется. Более того, насколько я представляю себе ваши задачи, под них в принципе никто в здравом уме не будет писать софт полностью на Electron или чём-то подобном.

Вот только мы изначально говорили про софт для массового рынка, а вы в качестве контр-аргумента приводите софт специализированный.

Линух массовый. Простые (без электрона) текстоввые редакторы массовые. QtCReator еще юзаю и матлаб.

Для бамажек LibreOffice.

Вот, кстати, практический вопрос по Qt, если позволите. Есть необходимость написать некую кросс-платформенную утилиту, которая постоянно работает в фоне и имеет UI для взаимодействия с ней.

Нюанс — утилита должна поддерживать аутентификацию через OpenID Connect.

Согласен с предыдущими ораторами, что писать такое на Electron может быть нецелесообразно из-за объёма потребляемой памяти — но и то, только в том случае, если Qt позволяет после того, как завершен процесс аутентификации, принудительно выгрузить из памяти Chromium, который поднимает под собой QtWebEngine.

Но тут возникает другой прагматичный вопрос — а что могут предложить Qt (при условии бесплатной лицензии) и сторонние C++ библиотеки в плане поддержки OpenID Connect?

Если использовать Python, то pyside2 + pyoidc, вероятно, спасут «отца русской демократии» (и то, придётся прикостыливать обработку кастомных URI schemes к QtWebEngine).

А вот на чистом «труъ» C++ я не вижу вариантов, кроме как или писать с нуля свой OIDC клиент, или платить за коммерческую Qt лицензию, где это есть из коробки.

... ну если сервер аутентификации не имеет никакого нечеловеческого API кроме непосредственно OAuth тогда наверное таки да хотя дай подумать...

... ну судя по общему описанию этот самый

OpenID Connect

для того и задуман ))

OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.

в общем если у конкретного сервера аутентификации есть REST JSON и другой внятные _не_человеческий API чтобы ввести логин-пароль то всё ок вообще без проблем запускать браузер там не нужен достаточно только HTTP(S) клиента а в QT он есть нормальный.

А вот на чистом «труъ» C++ я не вижу вариантов, кроме как или писать с нуля свой OIDC клиент

что там собственно «писать»? у себя в UI логин/пароль у юзера спросил по http(s) + json на сервер аутентификации логин/пароль отправил в ответ получил либо сессионный ключ либо спробуйтэ щэ собственно всё ))

но и то, только в том случае, если Qt позволяет после того, как завершен процесс аутентификации, принудительно выгрузить из памяти Chromium, который поднимает под собой QtWebEngine.

Но тут возникает другой прагматичный вопрос — а что могут предложить Qt (при условии бесплатной лицензии) и сторонние C++ библиотеки в плане поддержки OpenID Connect?

ага тут смотри какая штука получается чуть хитрее но всё равно всё уже придумано до нас схема используется на дивайсах на которых браузера и прочего GUI вообще нет в принципе но которые умеют только ходить в интернет фишка в том что процесс аутентификации разбивается на 2 этапа

1. дивайс или в нашем случае программа выдаёт URL куда пойти чтобы сделать аутентификацию OpenId и этот URL либо вбить руками (например в телефоне) либо в нашем случае программа просто запустит браузер по-дефолту с этим URL piece of cake

2. далее всё происходит в браузере а наша программа просто выдаёт окошко (об чём дальше) и ждёт а в браузере соотв. юзвер вводит логин пароль в общем делает все нужные пассы и далее в браузере же ж всё это перенаправляется на URL2 который мы передали как часть OpenId Connect и соотв. браузер делает GET со всем этим уже на наш сервер

3. далее наш сервер делает нужные пассы в общении с сервером OpenId и передаёт всякие секреты и в этом месте надо бы б чтобы он вернул нам session id но фишка тут в том что он большой и толстый (JWT) и нам надо как-то передать его с браузера в нашу программу...

4. ... потому наш бекенд выдаёт в браузере чисто PIN вплоть до того что тупых 4 цифры которые и надо ввести в программе которая на п.п. 2 выдала окошко и ждёт ввода этого PIN

5. и соотв. далее уже наша программа просто шлёт этот PIN на наш бекенд и получает от него всё что нужно т.е. аутентификацию

Вся фишка процесса что мы только открываем программно браузер а информацию PIN из него передаём вручную что соотв. можно сделать на чём угодно и сам браузер никуда встраивать не надо пользователь просто его закрыл и вопрос с ресурсами решён чистый профитЪ!

ЗЫ: но без своего бекенда не обойтись это да но тут а) без бекенда таки можно но это уже совсем другая история б) а собственно зачем вашей программе тогда вообще аутентификация если у вас своего бекенда нет?

1
2
3
4
5

Хто поламав Фоголя? Він інформацію структурує

розділові знаки і заголовніі літери!!!
учотку взламали

дивайс или в нашем случае программа выдаёт URL куда пойти чтобы сделать аутентификацию OpenId и этот URL либо вбить руками (например в телефоне) либо в нашем случае программа просто запустит браузер по-дефолту с этим URL piece of cake

2. далее всё происходит в браузере а наша программа просто выдаёт окошко (об чём дальше) и ждёт а в браузере соотв. юзвер вводит логин пароль в общем делает все нужные пассы и далее в браузере же ж всё это перенаправляется на URL2 который мы передали как часть OpenId Connect и соотв. браузер делает GET со всем этим уже на наш сервер

Спасибо! В целом, может быть рабочим подходом. И, всё же... все виденные мной «приличные» приложения, которые используют OIDC, таки показывают страницу ввода логина пароля аккуратно внутри своего интерфейса. Максимум — в отдельном окне, которое закрывается сразу же по завершению процесса аутентификации. Но такого, чтобы тупо открывался внешний браузер — не видел ни разу.

Затем, собственный сервер — это, порой, непозволительная роскошь. Часто делают так — в самом десктоп приложении регистрируют обработчик URL с кастомной схемой («протоколом»), и уже там «ловят» пришедший от identity provider’а код авторизации. В таком подходе, запуск внешнего браузера — это дополнительный источник проблем, так как ХЗ, какой именно браузер прописан у данного юзера по умолчанию, и умеет ли этот браузер корректно работать с custom URL scheme handlers.

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

проблема в том чтобы скрыть ваш api secret key. Если его прописать прямо в приложении он автоматически перестаёт быть secret

к.м.к. здесь уже нужно более детальное уточнение зачем именно вам вообще OIDC и как именно он у вас по схеме должен будет использоваться.

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

ЗЫ: в конце концов можно просто сэмулировать панель ввода open id provider или перехватить введённые пароль и логин на момент отправки пользователь никак не сможет в этом ни убедиться ни противостоять этому и соотв. всякий особый смысл open id теряется.

уточнение зачем именно вам вообще OIDC

Если вкратце, то кросс-платформенный single sign-on для любых внутрикорпоративных приложений. Увы, BYOD во все поля, приходится изобретать что-то работающее для Windows, Mac OS и Linux.

Теоретически, Kerberos под это требование тоже подходит, но — см. мой комментарий на абзац ниже.

в конце концов можно просто сэмулировать панель ввода open id provider или перехватить введённые пароль и логин на момент отправки

В том-то и дело — этого делать категорически нельзя. Код приложения по умолчанию считается untrusted, и, ни при каких обстоятельствах и никогда вообще не должен «видеть» пароли от доменных учётных записей.

В том-то и дело — этого делать категорически нельзя. Код приложения по умолчанию считается untrusted, и, ни при каких обстоятельствах и никогда вообще не должен «видеть» пароли от доменных учётных записей.

дык и я об том же ж и туда же ж идут api secret keys

т.е. вам же ж куда-то приложения ходят на какой-то web api? вот он и интересный. потому что если его нет — то в чём тогда sso? куда он собственно пускает?

т.е. чисто теоретически приложение может просто спрашивать и получать просто имя пользователя как «go no go» ну тогда по сути только первого ответа от oidc provider хватит + там можно запросить чтобы приехал username (опять же ж а зачем?) но опять же ж это как бы б получается пользователя «пустили» но куда? просто локально грант на запуск программы локально? никаких remote api и сервисов? ну тогда тоже можно.

В том-то и дело — этого делать категорически нельзя. Код приложения по умолчанию считается untrusted, и, ни при каких обстоятельствах и никогда вообще не должен «видеть» пароли от доменных учётных записей.

в этом же ж фишка ты же ж запускаешь панель доступа внутри себя самого как ты вообще хочешь сделать её «trusted» если ты же ж сам её и запускаешь? ну пусть через движок web но кто знает какой там у тебя движок? на него гарантированно нельзя key logger навесить? или там запустить в скрытом окне и ввести пароли программно? тот же ж selenium как-то это делает? ))

т.е. в таком контексте сама постановка задачи зациклена и соотв. бессмысленна вот в чём фишка и мораль

вам же ж куда-то приложения ходят на какой-то web api? вот он и интересный. потому что если его нет — то в чём тогда sso? куда он собственно пускает

Да, ходят на web API, которому для авторизации нужен JWT токен, подписанный цифровой подписью identity provider. Стандартная схема, и я бы точно постерёгся изобретать велосипеды в вопросах безопасности.

ты же ж запускаешь панель доступа внутри себя самого как ты вообще хочешь сделать её «trusted» если ты же ж сам её и запускаешь? ну пусть через движок web но кто знает какой там у тебя движок? на него гарантированно нельзя key logger навесить? или там запустить в скрытом окне и ввести пароли программно?

Nice catch. Да — теоретически, и при таком подходе, при желании, можно натворить делов. На практике — код приложений проходит code review, и любые телодвижения в сторону подобных пакостей будут сразу же заметны.

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

В поиске таких дык code review также помогают, но, увы, есть основания считать, что достаточной уверенности в их отсутствии после code review мы не получим.

имхо просто напишите «свой браузер» у которого единственная исключительная функция «запустить sso url и вернуть в зад url redirect auth» и который соотв. будет иметь свой какой-то IPC чтобы этот url redirect auth передать в зад.

соотв. у вас «единая точка входа» и соотв. её можно проанализировать и сертифицировать только однажды и далее все остальные приложения будут просто к ней обращаться уже как к закрытому ящику «вот вход вот выход» да по идее там может и «вход» не нужен а настраиваеться конфигурацией а вся функция этого сервиса по локальному IPC будет GetAuthResult => URL

а будет она там браузер внутри себя запускать или снаружи уже всё равно

Если же говорить о личных и рабочих ПК и ноутбуках и приложениях для массового рынка, то дорогая цена за найм и работу C++ / Qt специалиста, скорее всего, не оправдает экономического эффекта от оптимизации.

скупой платит дважды

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

а потом примерно из таких же соображений применяют «лучшие» инженерные практики как например давайте пихнем nodejs в премиальный продукт а на выходе получим УГ

например давайте пихнем nodejs в премиальный продукт а на выходе получим УГ

У вас какая-то личная травма, связанная с nodejs? :)

Да, есть задачи, для которых он плохо подходит, но из вашего комментария ну вот вообще непонятно, было ли «УГ» результатом применения nodejs там, где эта технология не может эффективно работать по определению.

И, да, если что — в сложных desktop продуктах ещё как может, VS Code и Slack тому пример.

Поделие слак — это нынче сложный продукт? А текстовые редакторы на электроне я попробовал и поудалял нафиг — убожество с нескучными обоями.

Вот посему на электроне на компе у меня только мессенджеры.

а зачем? месенджеры вполне норм живут во вкладках хрома

Лиса мне больше нравится. А веб варианты мессенджеров глючные.

Как сказать ...я заморочился и перевел свой 16Гб комп на Qt-Widgets (lxqt), удалив нафиг новомодный QML (KDE). Свои проги тож на виджетах оформляю. Даже «переизобрел» QML — можно простые формочки, типа настроек, описывать в виде массива макросов — вполне читабельно, а на выходе нормальный гуй на виджетах. Вобщем, из яваскрипт содержащих прог у меня только гугл-хром. Остальные лесом.

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

у QT есть для этого .ui файлы

Ну не совсем .. я хочу описывать настройку в виде «название» + умолчание. И я хочу, чтоб ета настройка умела сама себя гуем показать, и чтоб их там юзер перетаскивать мог — перестортировать (на экран 1024×600, как удобно)...

С++98 це найкраще що було з С++

не передьоргуй

Qt — саме краще що було з С++

из предложеного без слез можно смотреть только на Rust

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

Але ці домени занадто вузькі, тому не мають власних розвинених мов

бекенд, напр., аббо крипта\блокчейн...

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

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

До того трішки писав на Паскалі ще зі школи. Паскаль з його простою, красивою й логічною граматикою LL(1) дав розуміння того, як мають працювати прості програми, алгоритми, писатися простий код. (Для великих програм в мене є сумніви що воно підходить, але хтозна, я й не намагався на ньому чи Delphy писати великі).

Більш-менш великі програми на асемблері було писати занадто марудно, навіть як для гобі, тож вирішив спробувати чистий C, як «високорівневий асемблер». Річі-Керніган виявився нудним й застарілим, зате під рукою був Шилдт (Справочник C++) тож майже одразу перейшов на плюси, для початку — виключно як на покращену версію C (з нормальним const, типами, ізоляцією бібліотек в namespace тощо).

А далі вчитися набридло й пішов працювати. На все це пішло десь рік-два, за які я з відмінника дійшов до того, що з універу просто виперли, бо остаточно забив учитись (на фізика).

Щоб потрапити на першу роботу довелося (за підсумками першої співбесіди) трішки підтягнутися, з другої вже взяли.

Наразі працюю більше десяти років, в принципі все влаштовує. Працював багато де, найбільший кар’єрний стрибок був завдяки роботі в крихітному стартапі де доводилося робити тупо все від програмування до планування, на всіх платформах тощо. Коли шукав роботу в останній раз (років шість, здається, назад) вакансій було не те щоб дуже багато, але всі цікаві й різноманітні (софт по типу шизама, картографія, якісь дрова під кілька платформ, залізяки та ін.). В підсумку пішов в місцевий офіс невеликої продуктової, де затягнуло під Лінукс.

Багато хто нижче пише, мовляв, плюси застарілі й не модні — то все фігня. Мова активно розвивається в останнє десятиліття, на ній, а також на споріднених C, вже існує величезна кількість програм, тож нікуди вона не подінеться ще багато років. Може хіба проеволюціонувати кудись, але для досвідченого розробника немає проблеми проеволюціонувати разом із його основним інструментом. Плюс плюсів також в тому, що ця мова мультипарадигмена, немає проблеми перемкнутися з плюсів, якщо ти їх добре знаєш, на будь яку іншу мову в своїй предметній області. З іншими буде значно складніше. Це, зрозуміло, не стосується окремих галузей типу вебу чи мобілок, але з ними як у відомому анекдоті про байкерів: «чому ви не знайомитесь — та ви кожен місяць різні».

Пізніше напишу окремо що читати й вивчати, бо щось багато літер вийшло.

Ритчи и Керниган устарели? Забавно

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

Я бы начал не от языка а от предметной области. У C++ сейчас довольно узкое применение, интересно ли это вам?

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

Ничего в нем крутого. Безумно сложный яхык, но замены ему пока нет.

Безумно сложный яхык

бугога да уж конечно

Ну че, с 03 столько всего впихнули невпихуемого, что уже сложнsй

он еще и развивается,

агонiзуе

вводя в язык удобные фитчи и упрощая некоторые конструкции

синтаксiс шуга

С/С++ и где по другому ну вообще никак.

не путай С та С++

очень много всего написанного

COBOL

синтаксiс шуга
агонiзуе

Яка сучасна мова зараз не агонізує синтаксичними солодощами? Навіть в природних мовах є такі приклади.

А щодо плюсів, то вони нарешті почали значно розширювати стандартну бібліотеку. І це важливіше за цукор

почали значно розширювати стандартну бібліотеку

дальше зшивають Франкенштейна

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

Частково так, але boost усе ж не такий зважений і надійний, як stl (я не маю на увазі конкретні імплементації, а загалом). Та й ніхто не заважає користуватися ними одночасно. Зрозуміло, що shared_ptr чи variant і звідтіля, і звідтіля одночасно використовувати великого сенсу нема.

заинтересовался с++

Что сейчас сподвигает людей им интересоваться?

А что с ни не так? Язык как язык. В некоторых областях без него никак.

С ним всё так. Мне интересно, как информация о нём доходит сейчас до молодого поколения. Как его лучики пробиваются сквозь рекламные завесы модных-популярных брендов?

Ну так на брендах пилить можно. Но иногда нужны и продукты.

Кто сейчас доносит знание о С++ до масс я так и не понял

В университетах программистам ставят обязательный курс, минимум пол-года на 2-3 курсе, если очень современный курс, то на первом (но обычно там С, SQL, и прочая базовая фигня). Если препод от бога, то может чему и научит, а так... Обычно препод забивает, а потом приходишь на экзамен со списком вопросов и шпорами. Зависит от препода, но рассказываю про своего.

С++ изучается в рамках дисциплины «Системное программирование». В мое время мы клепали приложения на винапи от простеньких до сложных многопоточных и подобное. Там еще с десяток лабораторных и курсовая. Так что просто со шпорами не съедешь.

IoT, Automotive, GameDev, Embedded.
Все дуже актуальне, нове, вакансій в кожній категорії вистачає, в тому числі й в лідерах ринку, що дозволяє їм робити різні стажування, курси, інтернатури і т.д.
Окрім того, на плюсах можна робити майже весь спектр софта від UI на Qt, бекенду, ML\AI, високонагружені паралельні обчислення (CUDA і решта) ну і ще можна продовжувати цей список.
Може це просто я фанат плюсів, але менівидається, що політ ще буде досить довгим, скоріше за все, аж до масового впровадження квантових комп’ютерів.

можна робити майже весь спектр софта

але не нужна

Лично я учил по книжке Лажойе + видео курсы на udemy себе взял, потому что в книге как по мне маловато практики, да и информация на видео воспринимается быстрее. Книгу использовал как шлифовку знаний полученных после просмотра определенных тем. Времени занимает у всех по разному, например я учился по 2-4ч в день и вышло поднять плюсы до уровня устройства на Джуна за 3 месяца. Друг же фигачил по 6ч ежедневно и справился за 2 месяца. Но у обоих был бэкграунд в виде 2.5 курсов института. В целом мог бы посоветовать найти людей которые тоже начинают учить плюсы и собрать небольшую группу для обмена опытом. Мы с ребятами после собесов всегда собирались и обсуждали задаваемые вопросы, тем самым сумели восполнить пробелы в своих знаниях.

Начни с С, а затем по мере необходимости С++ добавляй

Раст задумувався як вбивця плюсів, а вбив джаву :) Судячи з того, що пару років назад в аналогічних топіках ти писав «C++ фтопку, вчи Java».

Чому в кожному треді на ДОУ про плюси ти вважаєш своїм святим обов’язком пополивати їх лайном? Це якась травма дитинства?

Раст задумувався як вбивця плюсів, а вбив джаву :

ти перепутав Rust з Go

в кожному треді на ДОУ про плюси ти вважаєш своїм святим обов’язком пополивати їх лайном?

тому що на ембедед приходять С++ люди (не ембеддед), які потім пишуть С++ код (в основному оверінжиніред і оверкомплікейдтед), який праціє на ПК, але не працює на ембеддед пристрої, в кінці кінців проект вмирає, так як в ембедед прийшли С++ (не ембеддед).

в кінці кінців проект вмирає

у вас просто проблема в найме и менеджменте, кресты тут причем?

не в мене,
при том, що С++ це приблизно такий же майнд сет, більше подібний до JAVA з ООП\ООД,
далі іде архітектура та розробка в С++ легаці стилі ... потім «не взітає»

до Rust не було варіантів заміни для С з певним рівнем абстракції та бібліотек і безпеки.
тобто можна було взяти С++ і це було би краще чим С.

Тепер в таких випадках можна брати Rust

Одне з двох:
* Або в проект треба закласти гнучкість, тоді він проживе 5 років постійних змін після релізу, і помре від костилів та жаби підвищувати зарплатню.
* Або робимо максимально ефективно, тоді він помре через 2 роки, бо конкуренти зроблять більш функціональну прошивку.
(С++ vs C mindset)

Або в проект треба закласти гнучкість, тоді він проживе 5 років

коли взлетить, тоді можна міняти на «гнучкість»,
а в більшості випадків «не взлітало», бо було занадто «багато гнучкості», а не було того «тре тупо працювати хоча б як РОС\прототип», і помирало скоріше чим за 2 роки

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

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

до чого тут

підеш в продакшн з багами. заробиш конторі славу.

та

працював слов’янський оберег „жаба”

en.wikipedia.org/wiki/Systemantics
A complex system cannot be „made” to work. It either works or it doesn’t.
A simple system, designed from scratch, sometimes works.
Some complex systems actually work.
A complex system that works is invariably found to have evolved from a simple system that works.
A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Расскажи в энтерпрайзе, или в операционках (микроядро так и не взлетело ни разу)

до чого тут мікро ядро та інтерпрайз, коли мова йде про те як розробляти (вбудовані) системи?

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

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

Ладно не ревьювить код синьоров, которые больше трёх месяцев на проекте и более-менее понимают, что там и к чему. Но не смотреть, что пишут новички (независимо от того, откуда они пришли), и потом обвинять в чём-то используемый язык программирования — это как-то несерьёзно. Вспоминается старая цитата с башорга про «виновата скамейка» (bash.im/quote/418579).

потому что проект маленький, короткий, и на нем один новичок?

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

патамушта я крутой ЦеПеПе а ти тупой ембедер

а че там конкретно не взлетело? вот у нас один код шо на роутере, шо на десктопе.

Полагаю, речь об устройствах на базе микроконтроллеров с совсем уж скромными возможностями. В роутере-то обычно вычислительная мощность достаточная, чтобы там некая разновидность Линукса крутилась.

так на скромных МК особо и не разгонишься: С++ рантайм сильно большой, если с исключениями, и STL тоже стремно, и даже new/delete нету...

у нас донгл на ARM Cortex M0+ будет (8KB RAM, 64KB ROM)

напр., код один, поведінка ОС різна, напр. при створенні та видаленні тредів: роутер на раздва лягає із за браку віртуальної пам"яті (ЦеПеПе прогер — ти іпись, у мене на ПК все працуэ)

Детализуй. А то хер тебя поймешь

ООП\ООД: шаблон «издателя и подписчика», пiдключається мережева камера, створюєтьс тред, при відключені «видаляється.

На ПК все ОК, на роутері, нікуя не удаляється — кілька реконетів — і роутер «давайдосвіданья».

То чувак не шарить про thread pool.
Яка в нього зарплатня? Хоча б $7K є?

Ну потоки и ресурсы — тут без спецов труДно. Если ручки крывы и ресурсы блокируются и зависают.

допишу проект — буду дивитись

Значить таки проблема найму, раз наймаєте відверто неадекватних людей з софт скілами на рівні 15-річного підлітка. Чомусь я на всіх своїх роботах (хіба що крім найпершої, поки ще був зовсім зеленим джуном і не розумів, що до чого) завжди адаптувався до прийнятого в команді код стайлу і прислухався до порад більш досвідчених колег. Хіба що міг поцікавитися, чому тут прийнято саме так, а не інакше, якщо причини для мене не були очевидними.

тому що наймають хто доступний на ринку в заданий бюджет, а не той хто підходить...ІМХО

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

ще раз, беруть С++ чувака, бо С (сабсет С++, а хуле),
С++ чувак робить дезайн енд девелопмент в кращих традиціях легаці біг сістем,
приходить час портувати на коробку: пук, пук — не взлітає.

Кирпичи тоже не летают, если не пнуть сильно.

Знакомая ситуёвина.
Но не стоет падать духом

А конкретнее?
Выпросить себе зарплату, чтобы ею аргументировать на код ревью кто тут главный?

пук, пук — не взлітає

Ще раз: хто винен? Конкретний девелопер, який не врахував особливості платформи, під яку ведеться розробка, чи мова програмування, яку він використовував?

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

Але якщо

наймають хто доступний на ринку в заданий бюджет, а не той хто підходить

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

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

А от не працює. Ми пів-року шукали, чому в 5% випадків наш софт в роутері падає чи висне при виході. Зробили хакераунд: не зупиняли нормально SIP стек, а виходили через exit(). Тестувальник гоняв під traceroute поки баг не вилазив.
Виявилось, що на роутері musl libc, котрий при видаленні залоченого мютекса портить список мютексів, який розмотується при завершенні процеса. А нормальний лінуховий libc — не портить, а повертає помилку.
І ніхто ніколи таких деталей не знає — бо усі ці приблуди під залізо на порядки менш популярні, ніж те саме під комп — багів більше, інфи — менше.

Виявилось, що на роутері musl libc, котрий при видаленні залоченого мютекса портить список мютексів, який розмотується при завершенні процеса. А нормальний лінуховий libc — не портить, а повертає помилку.
І ніхто ніколи таких деталей не знає — бо усі ці приблуди під залізо на порядки менш популярні, ніж те саме під комп — багів більше, інфи — менше.

Згоден, вимагати настільки специфічних знань від девелоперів — не дуже реалістично.
Але принаймні девелопер-плюсовик рівня мідла або вище повинен знати, що в стандартному С++ видалення залоченого м’ютекса — UB:
en.cppreference.com/...​w/cpp/thread/mutex/~mutex

The behavior is undefined if the mutex is owned by any thread or if any thread terminates while holding any ownership of the mutex.

А раз воно так позначено в стандарті (який так чи інакше намагається «об’єднати» всі платформи) — значить на різних конкретних платформах цей сценарій може приводити до різних наслідків.

Звісно, що коли вже написали код з UB, то можна очікувати будь-якої каки в будь-яких місцях. Неприємна бага, що сказати. Багатопоточні баги це взагалі весело, незалежно від напряму (будь то ембеддед, геймдев, десктоп чи ще щось).

А як вона взагалі виникла? Проект писався на чистих сях без використання RAII? Чи плюсова обгортка а ля std::unique_lock тут не могла б допомогти запобігти потрапляння такої баги в продакшен?

Видалення всередині pjsip (pthread_mutex_destroy()), на котрому базується добра половина софтфонів))) І сам стек, за нашим досвідом, дуууже стабільний та шустрий.

Виявилось, що на роутері musl libc, котрий при видаленні залоченого мютекса портить список мютексів, який розмотується при завершенні процеса. А нормальний лінуховий libc — не портить, а повертає помилку.
І ніхто ніколи таких деталей не знає — бо усі ці приблуди під залізо на порядки менш популярні, ніж те саме під комп — багів більше, інфи — менше.

так отож

Не нашел ембединга и почему-то обиделся на Страуструпа

Ты хоть жопу рви, найдут способ там тебя опустить, особенно на Украинском рынке.

Вот такой вот C++.

Для спортивного интереса ходил на сабесы на С++, так вот одни умудрили, умудрились предложили з/п ниже текущей на 1000$.

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

Хочешь С++ -> учи Java, а лучше Scala, а еще лучше JS. Не ведись на всякие глупости.

С++ и галеры — это садомазо с извращениями

но последние попытки с Люксофтом отбили желание в 0

а я люблю их собеседования в среднем раз в год участвую интересно же же что в мире делается ))

i як, «морський бой» на собесi на С забацав?

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

Щось в мене є великі сумніви, що в галєри взагалі варто ходити, і пофігу яка мова

На аутомотив проект ходил собеседоваться небось?

Ты хоть жопу рви, найдут способ там тебя опустить, особенно на Украинском рынке.
Вот такой вот C++.

Такой вот украинский рынок. Точнее, та его часть, с которой ты столкнулся на своём личном опыте.

У меня, например, опыт был противоположный: при последней смене работы запросил +500, а дали ещё больше, потому что собеседующие посчитали меня более прошаренным, чем я сам себя оценил на тот момент. Правда, это была не галера, а продуктовая компания.

Не стоит обобщать свой опыт на всех.

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

В Германии такая задача появилась: Монте-Карло симуляция — нашефсе, под нее не то что плюсы, CUDA на ура заходит.

для C++ остались специфические области применения — ембеддед системы и аутомотив, движки для игр и САПР систем, критичные части движков СУБД (MSSQL Server и Oracle), инженерные расчеты и математика. хотя там последнее время рулит Пайтон. но (!) - практически все математические либы и либы для машин лернинга для Пайтона написаны на C++ . и кто-то же их разрабатывает, значит работа есть :-)

И HFT же ещё и связанное

риалтайм трейдинг? ага, в UBS и ДойчеБанке было что-то на C++

У рейтера много и у сити.

я видел трейдинг на Джаве, но это жуткое извращение :-(( без GC. при этом теряется основная фишка джавы (нельзя использовать объекты управляемые GC и в том числе стандартные коллекции)

Совет: слушать поменьше советов. Учить мат.часть.

Идите на любой ресурс по кодингу, неважно codility это, hackerrank, или еще какой-то. Решайте предлагаемые задачи, а в качестве языка укажите С++. Решив задачу, посмотрите как её решали другие, если надо поучаствуйте в обсуждении.

Прочитать текст стандарта. Полностью.

Половина стандарта — вода, вторая половина — UB. Очень полезно джуну, ага.

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

і більше нікому

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

1) Английский (American English Centre, к примеру). Походить на разговорные группы. Нужно свободно читать тех литературу.
2) Не брезговать С при поиске работы.
3) ООП, архитектура, хотя бы банду четырех.
4) Многопоточность (pthread), межпроцессное взаимодействие, сети.
5) Линух.
6) Если новые стандарты не влазят — выучить старый С++03.
7) Начинать с Питона — на нем раз в 5-10 быстрее тренироваться. Научившись програмить на Питоне — переходить в С++.
8) Свой проект (мини-игрушка вроде арканоида или танчиков).
9) Я читал C++ in Action: Industrial Strength Programming, Stroustrup C++, C++ FAQ Lite.
10) Современные операционные системы Таненбаума.
11) Алгоритмы Седжвика.

Не брезговать С? Вы так говорите, будто С++ проектов днем с огнем не найти, а все пишут только на С. Как бы не наоборот!

Я так говорю, будто собеседование по С++ часто намного сложнее пройти, чем на С. Хотя бы потому, что там 100500 каких-то деталей и исключений из правил. И, извините, задротов, чешущих на собесах ЧСВ вопросами по знанию стандарта, на С++ полно.

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

Не знаю. Работал где-то по 5 лет на С и С++, и асм до сих пор не знаю. Вот недавно поднял без него USB+DMA+I2S+SPI на EFM32.
Может, у Вас там какая-то жесткая жесть.

и асм до сих пор не знаю. Вот недавно поднял без него USB+DMA+I2S+SPI на EFM32.

вот вот вот а потом «боинги» падают ))

вывести что-то на экран, потом cli; hlt; — когда-то так отлаживался)

когда-то так отлаживался)
вот вот вот а потом «боинги» падают ))

LIL ))

Нет, так они зависают в воздухе)

Где в Украине нешуточно собеседуют по асму ?

8) Свой проект (мини-игрушка вроде арканоида или танчиков).

Добавлю-перефразирую:
8а) Свой проект (игра) на готовом движке (Юнити например)
8б) Свой кросс-платформ проект (игра) на СВОЁМ движке написанном с нуля — вот тут ты технических проблем выхватишь сполна, и будет повод покопаться в чужих исходниках посмотреть «как же сделано у них»

8б) Свой кросс-платформ проект (игра) на СВОЁМ движке написанном с нуля — вот тут ты технических проблем выхватишь сполна, и будет повод покопаться в чужих исходниках посмотреть «как же сделано у них»

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

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

танчики можно напрямую на Qt писать или подобном

А можно написать на sdl+opengl+opengles и портануть это на linux+windows+android+ios

проблема в том, что надо выбрать 2 из трех: работа, учеба/творчество или жизнь.

Всё отлично выбирается. Знаю многих кто имеет не только 3 сразу, а даже 5: работа, учеба, жизнь, семья и спорт.

по сколько часов в неделю?

Достаточно что бы был прогресс и все дома были счастливы.

сколько детей?

Знаю многих кто имеет не только 3 сразу, а даже 5: работа, учеба, жизнь, семья и спорт

Отсутствие в этом списке сна — случайность или...? :)

Нiт
Так как большинство из high-tech — родом с другой планеты )

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

проблема в том что таких «пилильщиков высокой сложности» следует скорее избегать чем наоборот ну конечно если он не гений какой очень удачно подвернувшийся коньюктуре вроде Линуса Торвальдса и то даже в этом случае это скорее вопрос «а взяли ли бы вы Линуса Торвальдса себе в компанию?»

просто потому что там в «своих велосипедах» что технические решения что организационные скорее аховые чем наоборот.

а потом человек вместо того чтобы скажем прямо «знать своё место» будет уверенный что «он же ж знает он же ж пилил своё вот это всё» и сказать ему «пили как все и вообще как сказано» это таки чаще сложно чем наоборот.

я проверял ))

Конечно надо таких избегать. Ведь на проект нужен — послушный сотрудник с лычкой june/middle, а перепродадим его как senior.

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

www.bruceblinn.com/parable.html

Если честно, то я давно не видел вакансии где нету С++11 хотя бы. Видал С++14 и не меньше, было такое требование. Так же некоторые проекты, которые с 0 пишут, тоже уже вообще с С++17. Из своего опыта гуляния по собеседованиям я не видел чтобы где-то кто-то писал на С++03.

так кажуть, що С++ туйова хуча років як і легаці овнокода

Дуже гарно, але не погоджуюсь з пунктом #2 зовсім.
Потім приходять на співбесіди отакі Сі-шники, й вважають що раз вони на С писали N років, то й С++ вони знають. Зазвичай навіть оферів не отримують. Бо зовсім різні підходи.
Якщо є бажання колупатися в embedded — так, С краще знати. Можливо колись для низькорівневої оптимізації, коли стане досвідченнішим, також. Але якщо такого бажання немає, то не треба забивати знанням С мозок новачка від слова зовсім.
Авжеж розуміння архітектури й низького рівня має бути, але братися за роботу на С, замість С++ я б не рекомендував — це слизька доріжка, у зворотню сторону від С++.
Ну й стандарт краще все таки хоча б 11 вчити, а краще 14, 03 — вже як мамонта г... можливо знов таки десь у embedded використовується.

Тут вже кому куди)

вже як мамонта г... можливо знов таки десь у embedded використовується.

звичайно, а куда ще б гавно не закинути, тiльки тупим ембедерам, хай жруть ваше ЦеПеПе

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

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

кожен свіжий стандарт спрощує С++

 То є Ваша особиста думка. Легенди про складність С++, здається, мають коротшу історію, ніж сама мова.

Для новачків плюси складні. Авжеж завжди коли ми кажемо про складність,треба порівнювати з чимось, скажімо з Python.
Навіть самі розробники С++ стандарту кажуть про те що плюси треба спрощувати.

ага, тепер пiсля «спрощення» С+11 тре ще move конструктор та оператор :)
чи малось на увазі ванільний цукор типа foreach

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

для мув семантики з швидколдію придуманий Rust, з якого ЦеПеПе вкрало ідею та підставило черговий костиль, який тепер продається як #пакращеннявжесьогдні

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

Що до Rust який такий весь про швидкодію, то вибачайте —
С++ по перше були завжди про швидкодію, після чистенкого С (який після чистенького asm), й досить логічно що якісь речі які підвищують швидкодію будуть з’являтися й надалі.
По друге — щось трохи складніше ніж звичайні «задачі з підручника» на Rust робити не так легко, як дехто вважає. Й переходити з нашого вже закам’янівшого «г... мамонта» (C++) на ще тепле й гаряче «свіже г... мамонта» (Rust), щоб потім вовтузитися у тій калюжі? Нащо, якщо можна забрати звідти лише найкраще?
Навіть в багнюці можна іноді знайти діаманти..

Що до Rust який такий весь про швидкодію, то вибачайте

може ти щось перепутав, з Джавою наприклад?
research.mozilla.org/servo-engines
Servo is very fast. Many parts are much faster than existing browser components written in C++.
сідай, Вовочка, 2ка в щоденник

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

habr.com/ru/post/274815
ага, два рази на С++ не взлетіло...

коли С++ матиме людське ABI?

може ти щось перепутав, з Джавою наприклад?

Підіть розкажіть це розробникам комп’ютерних ігор. :)

habr.com/ru/post/274815
ага, два рази на С++ не взлетіло...

Цитування зі статті за посиланням:

Сложности

* Производительность. Параллельные алгоритмы, как правило, требуют идти на тяжелые компромиссы. Важно действительно быть быстрым. Мы должны убедиться, что Rust сам по себе имеет производительность, близкую к C++.

Чогось стало дуже смішно.

ти текст англійською не осилив?

Servo is very fast. Many parts are much faster than existing browser components written in C++.

лол просто лол

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

Це 16 рік. Треба щось новіше

для мув семантики з швидколдію придуманий Rust, з якого ЦеПеПе вкрало ідею

doc.rust-lang.org/...​reference/influences.html
тут есть соседний топик про чтение документации

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

І де суперечність? так, кожен стандарт в своїй меті має як спрощення вже існуючих механізмів, скажімо: той самий structured binding в С++17, або variadic templates, або вносить уточніючі й більш зрозумілі й інстинктині поведінки, як скажімо з ініціалізацією {}, та auto. А також кожен стандарт щось забирає з мови — це теж спрощення.
Але кожен стандарт додає щось новітне, а поява будь якого нового — це ускладнення, але використовувати це новітне не зобов’язаний кожен, й тому для нього ускладнення не відбувається одразу. Лише поступово.
Ніхто не заставляє джунів писати variadic templates. А ось сіньорам стало легше.

Суперечність в тому, що мова стає складнішою, а кожен новий стандарт її «спрощує».

Себто, з кожним роком жити стає «ліпше», а купити можемо дозволити собі менше)

Тут залежить просто від того, що розуміти під складністтю.
Вирішувати деякі задачі за допомогою нових «фіч» нового стандарту стає легшим. Викинуті та deprecated вчити так само не треба.
Об’єм стає більшим — так, стає складніше запихати усе це за 21 день в голову :)
Але синтаксис мови спрощується в цілому, а значить код стає простішим, його легше розуміти.
Адвансед топіки були як у старих так й у нових стандартах. В нових вони більш чітки зазвичай, більш strict, більш пророблені — тому я вважаю їх засвоєння теж переважно легшим в нових стандартах.
Якщо перевчатися — так, тут я згоден, це складніше.
Але якщо саме вчити той чи інший стандарт, я б вважав що останні (14-17) краще, бо хоча б с того самого боку що не треба буду перевчатися, це раз. По друге, зазвичай на нових стандартах пиляють НОВІ проекти, а це вже дуже краще, ніж потрапити на проект 15-25 річного монстра.

Щодо перевчатися, треба буде завжди, авжеж, але потім, й на 1 раз менше)

Коли шукаєш першу роботу — шанс потрапити на новий проект на новому стандарті, без досвіду... думаю, невисокий. А на старих проектах макроси та вказівники, та pthread + mmap + сокети. І якщо вмієш best practices, лишишся надворі.

І в результаті в нових стандартах:
* з’являються нові чи додаються значення старим кейвордам
* з’являються нові конструкції мови, на зразок мув конструкторів
* росте стандартна бібліотека, включаючи цілі області, як дивна багатопоточність та розумні вказівники
* з’являється якась функціональщина, котра ніяким боком не лізе в процедурну парадигму С та оригінального С++
Де тут спрощення?
Можна ще відслідкувати об’єм версій стандарту, якби він не був платним

Move це реалізація на рівні мови того, що раніше, починаючи з простого C, робили руками, кому треба було Їх можна не використовувати. Як і стандартну бібліотеку. Хіба хтось змушує когось користуватись, скажімо, std::thread? #ifdef _WIN32 / CreateThread #else pthread_create #endif можна продовжувати писати зараз як і двадцять років тому.

І так, все це є спрощення.

#ifdef _WIN32 / CreateThread #else pthread_create #endif

OS Abstraction Layer не чув ніколи?

Який ще треба написати, хоча wait... О! Воно ж є в новому стандарті в стандартній бібліотеці!

Там є message handlers / actors в новому стандарті? Чи все одно його писати, лише не на pthread, а на фютесках?
І сокети теж в новому стандарті є?
І таймера є?
Може ще роботу з мапінгом пам’яті додали та з USB?
А якщо всього того нема — то чим стандарт допоможе абстрагуватись від ОС?

То ви ще й за USB в наступному стандарті чи як?

Я відповідаю Вам на закид, що OAL не потрібен з новим стандартом.

Якби в С++ була нормальна бібліотека, мова могла б бути більш вживаною.

Яка це, нормальна? З USB чи без нього? З потоками чи без них?

типу як в пітоні, з батарейками. бо з тим, що в С++ бібліотеці, нічого реального не зробиш — все одно OAL писать доведеться. Усюди мережі чи віконця чи ще щось. Тому включення потоків в бібліотеку абстрагуванню від ОС не допоможе.

(boost -> std) thread + boost::asio і всього вистачає

Для чого вистачає? Що зараз можна зробити без мереж, периферії, UI та SIMD чи відяхи?

* з’являються нові чи додаються значення старим кейвордам

так, або зовсім викидаються (наприклад register з С++17), мова еволюціонує й розвивається — це звичайний процесс

* з’являються нові конструкції мови, на зразок мув конструкторів

щодо move семантики — вже відписав нижче, це для оптимізації та швидкодії, використовувати Вас ніхто її не зобов’язує

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

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

* з’являється якась функціональщина, котра ніяким боком не лізе в процедурну парадигму С та оригінального С++

до чого С до С++ стандартів? Дивіться в С стандарти.
С++ завжди були мовою на якій можна було писати в будь якій парадигмі — будь то процедурна, об’єктно орієнтована, data орієнтована, мета-программування в темплейтах, функціональна, та будь яка ішна парадигма — С++ це швейцарський ніж, на ній можна програмувати як захочеш. Якщо Ви собі вирішили що С++ — це процедурна парадигма, в мене для Вас погані новини.
Є потреби в «функціональщіні» в інших програмістів, вас ніхто не зобов’язує писати в функціональній парадігмі. Підтримуйте свій procedure-style код.

я бачу що надмірне вживання ЦеПеПе веде що Стокгольмського синдрому

В кожної мови свої переваги й недоліки. Я як раз намагаюся розвінчати міф про те, що С++ легка мова, як дехто тут стверджував. Ніхто не казав що буде просто.
То ви ще не спілкувалися з visual basic погромістами (дякувати сучасності, їх вже не так багато залишилося) — які вважали що їх мова просто найкраща в світі.

І от в підсумку де той VB а де C++.

Не знаю де VB, а С++ четверта-п’ята-або-шоста за популярністю мова в усьому світі. (в залежності від того, хто проводив дослідження)

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

чого (епітет за смаком) мова має бути _не_ легка? нахіба воно треба?

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

Від самого початку книжка С++ за 21 день читалась за тиждень, і давала нормальну базу, щоб вже щось писать руками.

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

Я так заходив:
C++ in action — добре розповідає ООП, але дуже невнятно саму мову, нічого не зрозумів
AutoIt — трохи пописав скриптів
Python — з офіційного туторіала, помучав PyGame
C++ in 21 Days — структуровані знання з ядра мови, написав іграшку під WinApi
Страуструп
Походив по співбесідах, запропонували сішний проект

А з якої книжки шановний пан пропонує вивчати С++ новачкам, що не знають інших мов?

з початку LPTHW, а вже потім в С++ ) або можливо ніякого «потім» не буде

В мене однокласники заходили в С++ в школі з нуля, пітона тоді не було ніякого.

рубі з’явився в 93-му такшо вони слабакі ))

Інтернету не було з доками по Рубі)

Багато з них працює програмістами? Багато було переможців олімпіад з програмування?
Я нажаль такого досвіду немаю. В мене С++ — це четверта чи п’ята мова програмування (й теж до Пітона).

Багато з них працює програмістами?

Не знаю, п’ятеро чи шестеро пішли на кібер шевченка навчатись, пару — на мехмат. Один потім в аспірантуру по CS в Швейцарію.
В олімпіадах з програмування участь не приймали, здається.

Плюсую. Сам выучил вначале C по книге K&R и серии брошюр «C для PC», затем основы C++ по публикациям в журнале Компьютер-Пресс, ну а потом уже Страуструп, да :)

а ну ок )) я за 2 тижні буду в місті запитаю

ЗЫ: моя сі++ почалася з книжки точніше навіть двох вони йшли однією серією щось там veni vidi vici на жаль книжки «дав почитати» і не зберіг (( купив геть випадково бо тіко приїхав з села в місто а в селі такого різноманіття книжок не було ))

і нічо не поняв бо якийсь дикий невідомий синтаксис.

але потім опять повезло бо трохи згодом купив книжку дуже просту але цілком повну по самих сях ну типу printf і таке інше як то шо то за страшна конструкція for (;;) ну і дужки всякі канєшно тож і її вистачило на вечір і тоді вже після неї тих двох вже за плюси вистачило ще на 2 вечори не більше.

так шо я спитаю канєшно.

трохи вище відповів, але повторюся — питання в легкості освоення як першої мови програмування, та знайомства з програмуванням взагалі, й використанням лише синтаксису підмножини С.
Чи коли ти заходиш вже зі знанням програмування, та починаєш використовувати не лише базовий синтаксис, а й більшу частину всієї мови.
А так думаю, за 21 день можно легко запригнути с якихось C# чи Java.
А ось для людини незнайомої з програмуванням зазвичай вивчення С++ — це дуже ймовірно останне знайомство з програмуванням взагалі, особливо якщо вони одразу направляють на тему з форматом scanf та тему pointer-ів на pointer-и, навіть не доходячи до мета-програмування на template-ах, template traits & specialization.

то для безгамотних вчителів ім’я їм легіон ім’я йому СССР Родіна

вхідний курс «сі++ для сішників» триває повних 2 дні всьо після цього людина готова одразу в бій ще не senior але готовий мідл точно

так окремі курси шото на зразок «variadic templates extended» поки тільки плануються але а) незроміло кому воно треба б) відповідно незрозуміло чи воно треба взагалі

вхідний курс у програмування триває повних 2 дні цього так само вистачає щоб освоїти усі початкові концепції і почати щось робити на чистому сі

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

перехід що з сі що з сі++ на c# складніший але загалом «вхідний курс сішарп для сі++ шішників» так само 2 дні але це радше «нульовий курс» хоча би б тому що «просто сішарп» ніше прямо не застосовується а там де застосовується там курсу «вхідний у програмування» цілком досить

ще раз повертаючись до питання «а нахіба воно ото взагалі нада ото програмування взагалі?» у людей які плотять $4000 за курс то є питання набагато більш прагматичне воні ніколи не були в СССР і навряд вже встигнуть побувати втім навряд чи вони навіть думають

Надмірне вживання будь чого — це погано. Що занадто — то нездраво.
Тому завжди треба підбирати інструмент під задачу. Але ж ми зараз не про це?

Надмірне вживання будь чого — це погано. Що занадто — то нездраво.

з С++ вже явно передоз, якась наркоманська тема

Тому завжди треба підбирати інструмент під задачу. Але ж ми зараз не про це?

тре підбирати, і що?

з С++ вже явно передоз, якась наркоманська тема

Тобто ця тема, де ми обговорюємо С++ — наркоманська? Хм... ну ОК. Не зрозуміло що Ви тоді тут робите?

тре підбирати, і що?

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

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

наразі дефакто таких проектів та задач нема селяві.

скажімо будь який фроненд

web assembly

Поки що я бачу якись дитячі комплекси щодо цієї мови програмування.

хіба в дзеркалі? ))

заставляючи писати на С++ фроненд?

а в чому проблема до появи власне вебу та mvc була сила силенна таких самих задач тіко воно не звалося «фроненд»

ну і потім ходити нікуди не нада зараз є вже QML та сама суєта тіко збоку )) я вже перестав питати «чойта чуваки а нахіба вам вопче той qml в чом фішка?» ну нада значить нада дєньгі давай ось нашльопана формочка приходьте ще ))

чи співбесіду в гугл завалили?

так нема же ж в гуглі і фхтангах вообще співбесід по сі++ ))

так нема же ж в гуглі і фхтангах вообще співбесід по сі++ ))

я думаю Ви дуже здивуєтесь...

наразі дефакто таких проектів та задач нема селяві.

така собі заява
чомусь тільки С++ — це топ-5 мова програмування :) то всі такі дурні, але лише ви один найрозумніший

web assembly
QML та сама суєта тіко збоку

тут Вам правильно інтуїція підказала щодо «збоку», суть Ви вхопили

я думаю Ви дуже здивуєтесь...

я думаю 146% ))

то всі такі дурні, але лише ви один найрозумніший

я думаю я дуже не здивуюся ))

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

так нема же ж в гуглі і фхтангах вообще співбесід по сі++ ))

=>

але амазони та гугли С++ приймають на співбесідах — аж гуде

саме це я й мав на меті довести я так гадаю тема себе таки вичерпала саме за вже доведеними суб’єктивними особистими факторами ну і так див. п.п. «за наркоманів» це воно саме про те

так, С++ тема наркоманська, якщо хто підсів на С++ то вже конткретно, і вже не може спригнути... якось так

і при чому тут фронтеенд? не придумуй фантазій.

так, С++ тема наркоманська, якщо хто підсів на С++ то вже конткретно, і вже не може спригнути... якось так

нє не так )) тема цілком нормальна суть в самому наркоманстві якшо наркоман то загалом пофіг на шо підсисти аби тіко наркоман ))

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

Навпаки, pthread один і той же, а стандарти С++ ростуть як гриби.

С++ завжди були мовою на якій можна було писати в будь якій парадигмі
функціональна, та будь яка ішна парадигма

 Як функціональна парадигма підтримується в С++03?

А тепер — повертаємось до питання: який стандарт С++ складніший: 17 чи 03? По якому С++ буде важче підготуватись до співбесіди? В якому більше сторінок?

а ще потім читати код в якому застосовано кілька парадигм:
— С з класами
— метапрограмування на шаблонах
— функціональщина
— ООП\ООД

Гівнокод я на будь якій мові. Якщо хтось не дотримується парадігми розробки продукту конкретного продукту, або такої парадігми взагалі не існує — то це «пред’яви» ніяк не до мови программування.

ну спробуй зробити в Go «мультипарадигмове програмування»

та то же ж для тих хто не здужав сі++ ))

а Ви мені за це заплатите, якщо вийде? :)

Навпаки, pthread один і той же, а стандарти С++ ростуть як гриби.

доречі там потіхоньку системи починають підтримувати купу нових цікавих парадигм як лінукс ще не знаю але на вінді на рівні системи «thread as a simple thread» то вже чутка застаріла концепція дето так початку століття а зараз там цілком собі норм пули всякі і може таки скоро і до coroutine дійде а може і вже дійшло.

інша справа що і сам api на рівні системи був доволі ацьким )) треба було проникнутися а може й навпаки не треба а клепати собі форми на делфі і потіхоньку зашибать дєньгу ))

Qt круче вашого Делфі, я за Qt,
як колись уже писав «Qt це саме лучче шо случилось в ЦПП»,
правда тепер скурвилось в платну пропроітарщину,
пздць плюсам..

воно вже давно не ц++ і воно вже давно зайняло свою нішу «фронтенду для тих хто нездатний запустити браузер для фронтенду платформ» ))

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

А хтось десь заставляє сдавати єкзамени по цілому стандарту ? o_O
Приходиш на співбесіду, кажеш оце «юзав» оце «не юзав». Все.
Але якщо на проекті використовуються повсемісно algorithm-и новітні, атрибути, stringview, structured binding, та інші фічі С++17, то людина повина їх була використовувати, або хоча б чути трохи про них.
Інакше виходить те саме що брати Сішніка на С++ позицію. Будь він хоч тричи сіньор-супер-мега-пупер Сішнік.

«Змінити роботу через розходження в стандартах» :)

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

використовуються повсемісно algorithm-и новітні, атрибути, stringview, structured binding, та інші фічі С++17, то людина повина їх була використовувати, або хоча б чути трохи про них.

то ідуть такі лісом

Хтось десь писав, що нові стандарти спрощують мову С++

algorithm-и новітні, атрибути, stringview, structured binding, та інші фічі С++17

А 10 років тому їх не було, і сішника спокійно брали на проект.
І навіть (усі) сішники вміли С++.
Стала мова простіше?

Для сішніка ні, для С++ — так, покращення з кожним стандартом.
Пам’ятаю як волали на 11 стандарт фани 03.
Зараз всі вміють в 11. (добре, не всі, але більшість).
Тобто майже ±8 років — й всі вміють.
тому очікувати щоб 17 став де-факто за-замовчуванням можна десь до 25 року.

тому очікувати щоб 17 став де-факто за-замовчуванням можна десь до 25 року.

по суті вже став «дефакто» обмежуюсь тільки явними технічними або адміністративними обмеженнями у 17-му взагалі дивна штука купа явний виправленнь явних «прой...колів» 14-го нашо 14-й вводили вообщє непонятно ну от скажімо ті самі std::string_view та std::optional це так круто дуже важко було одразу здогадатися? шо сірьозно 3 роки пішло на розробку?

або скажімо std::map::try_emplace ого яка сурова вєщЪ! я вже зіткнувся одразу же ж після виходу 17-го стандарту тобто обійти власними силами звісно можна але раз зіткнувся я значить штука же ж доволі очевидна нє?

«Не помиляється лише той, хто нічого не робить»

щодо move семантики — вже відписав нижче, це для оптимізації та швидкодії, використовувати Вас ніхто її не зобов’язує

ну да а потом починається стандартна війна «а давайте срочно скрізь заюзаємо move semantics бо то же ж для оптимізації та швидкості!» ну ок «заюзали» х.з. зачєм но нада значить нада далі кодять і тут якось так само собою складається що скрізь собствєнно самі лише pod дані юзаються а як тепер у нас move semantics то то є ж круто! нє ну чутка канєшно раньше по-старінкє було ссилка на об’єкт а далі з нею удобно працювати а тепер значить у нас move то ми можемо вирнуть об’єкт сразу в зад прямо як результат функції... як швидкодії впало на порядок!? то непорядок срочно визвать оптимізатор статичній ось бюджет $100500 на придбання софта «ой а тут у вас pod муваються то такі непорядок!» ну а поки сіли переписувать шоб pod не мувались то й забули нашо то воно є всьо було так буває ))

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

ну да ну да і вже маємо js подібну ситуацію коли «використання вже готового фреймворку» (к) (тм) важливіше за власне саму ціль а нахіба вообще ця програма робиться ))

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

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

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

ну да ну да і вже маємо js подібну ситуацію коли «використання вже готового фреймворку» (к) (тм) важливіше за власне саму ціль а нахіба вообще ця програма робиться ))

я не розумію печії, від готового фреймворку
якщо готовий фреймворк присутній, й він вирішує проблеми та задовольняє потреби, які постали на конкретному проекті, то чому б його не використовувати? бо лінкуватись з тим самим boost, коли щось вже є готове «з коробки» чи писати новий «велосипед» з підтримкою кросс-платформи?
Якщо на якомусь проекті Вас заставляли юзати stl, який не підходив для вирішення задач саме цього проекту, моргні-те!

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

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

якщо ти тех-лід чи архітект

може за тиждень виходить чиста година кодінга

то зрозуміло, питання в тому, що зазвичай такі люди контролюють та «спускають зверху» стандарти розробки
і якщо сказали ніякої функціональщини — то значить ніякої функціональщини та мета-програмування на темплейтах, та взагалі ніяких темплейтів, а якщо всім начхати на таке — й кожен грає у «лебідь, рак та щука» втілюючі свої еротичні фантазії в коді — то якби зрозуміло що можно побачити потім таких франкенштейнів, що краще б не бачити

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

Черговим стандартом С++
Давно вже треба було нову нову зробить, а не старій мацаки дошивати

Ви ж розумієте, що люди не будуть програмувати на тому, що незручно
Ніхто не буде використовувати той стандарт, який штучно «привитий», його просто пропустять в найкращому випадку
З С++17 стандарта я знаю не так багато тих, хто його використовує по перше, й ще менше тих, хто використовує УСІ фічі 17-го стандарту по друге.
Але не бачив з них тих, хто б плювався від нього.
Бо тим кому новий стандарт не зайшов, на нього просто не перейшли.
Добре що С++ взагалі розвиваються, а в правильному напрямку чи ні буде (був?) той чи інший стандарт — покаже лише час, й зазвичай у наступному всі «свіжо-розкидані граблі» перевертаються на якісь фічі, або викидаються (так само як стало з auto-ptr). Все таки дивлячись на роботу комітетів по стандарту, дуже складно, тим паче що новачків не так багато, мало хто з новачків має духу вийти й сказати що «що за г...о ви пхаєте» якимось маститим дядькам, та й мова сама не дуже «молода», зазвичай всі хто програмують на С++, це здебільшо 30+.
С++ не панацея, я ніколи такого не казав.
Мені вона подобається, бо багатьох від неї верне як в чортів від святої води.

IMO C++ як С треба було заморозити (воно й було заморожене з 98 по 11 купу років) і щось докидати невелике в бібліотеку та шаблони, що там з’являлось, типу хеш мапи.
Тоді ж почали писати мову D, от в неї чи подібне вкинутись, і зробить свіжу нативно-компільовану джаву без зворотньої сумісності з С та STL, і з повномірною зручною бібліотекою.

Я не розумію, чому Ви тут пишете коментарі, замість умовної мови D, чи E, наступника замороженої С++03, якщо Ви так наперед знаєте як воно краще.
Люди самі вирішать на чому їм писати, тим паче таке ком’юніті як прогамістське, й тим більше як С++ ком’юніті

програмує хто не розуміється на цій мові программуваня, до чого тут мова?

почитай нашо взагалі зробили руст там всьо написано досить точно і достовірно все так і є я перевіряв

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

всьо так всьо так див. п.п.1

Якщо на якомусь проекті Вас заставляли юзати stl, який не підходив для вирішення задач саме цього проекту, моргні-те!

бачиш осьо моргаю аж сквозняк та досі ціла купа проектів які саме «сі++ як інструмент до інших технічно нема а сі вже важкувати» і у яких «ніякого stl бо саме тому й сі++ бо ніякий пітон туди суто технічно не влазить».

ну а що «кросплатформеності» ну да гарна штука і які саме платформи наразі підтримує boost?

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

=>

будь які зміни вносятся не у результаті чієїсь забажанки «я так хочу»
Де тут спрощення?

ішо класна штука const якщо почати використовувати то там одразу же ж жопа неокрєпним умам падаванофф по-перше там 146% тупе дублювання коду ну так сложилось бо х.з. нашо той const вообще був нужен но в язикє жи ж єсть значіть нужен! ну а далі починаються вже язикові ті самі «новій конструкції» бо тепер нужен const_cast (ну того шо ми тіскали тіскали але всунуть все в той const compliance такі не змогли) ну а далі «тут тіпа const но тут панімаіш така жопа шо mutable» ну а далі «чойта наш const не дуже const то нада ісчо constexpr» і снова юніє падавани його скрізь сують х.з. як то раніше без нього жили ужас просто бере за ті старі часи! но далі всього случілась жопа нікогда нє било і вот опять! і тепер у сі++20 буде ще й consteval ну щоб вже напевне...

як результат «супер продвинутий компілятор» суто технічно відкидає саме суть програмування «а нахіба собствєнно ми його вообще робимо?» і ті самі пітоністи просто беруть і пишуть свої скріптики 2+2 і не видєлуються «глибинними глибинами крутого язика».

ну такоє.

По const & (!!!)
Все по const & (!!!)

х.з. як то раніше без нього жили ужас просто бере за ті старі часи

примерно так
gist.github.com/aztek/1349185

Александреску?

можно соптимизировать чутка добавив что N<1> тоже = 1

Половину советов можно с лёгкостью отбросить.

Главное определись что тебе ближе:
Геймдем
3д графика
Серверная часть
Ембедед

Из того что помимо самого C++:
stl
cmake
git

Ну и потренеруйся на задачках на leetcode.

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

«stl и cmake» — это не «что помимо С++» это и есть само «С++»
git — вообще просто must-have для любого разработчика.

А вот перспективные направление, где тут перечислены?

Розумієте, зазвичай розробники спеціалізуються на чомусь одному, тож розробник, який спеціалізується в embedded, про перспективність, скажімо, gamedev, може говорити чисто теоретично. З тих напрямів, що перераховані, начебто всі є в Україні, правда, не впевнений щодо 3д графіки.
По грошах, думаю, спеціалісти в будь-якій області отримують достойно — на всяк випадок можна скористатися зарплатними віджетами на ДОУ, щоб переконатися, тож спеціалізацію варто вибирати не за перспективністю, а або те, що більше подобається, або те, куди вдасться влаштуватися, якщо все однаково подобається.

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

C/C++: automotive, bigdata, ML, IoT, networks, wireless, OS, emedded systems ...

C/C++: automotive

ну например риальный кейз сидят люди и на полном сирёзе «переписывают» какой-то старинный фреймворк «на чистых поинтерах» «на новые кошерные std::vector-ы» работа крутая очень важная требует глубоких знаний си++ на уровне внутренней реализации компилятором управления памятью для выделения массивов ))

ЗЫ: ну и конечно виртуальный функции и абстрактные классы как жы ж биз них ))

или вот например реальный кейз х.з. что там у них но «an urgent role of C/C++ Developer with Postgres DB at Lorain, OH» я специально по карте посмотрел этот Lorain, OH прикольная такая дыра очень милая только реально же ж дыра натуральный такой Middle West что там у них такое х.з. так ни разу и не пробовал пишут вот 2 года по 2-3 раза в год кроме US Steel Corporation я по карте там больше никого не вижу но это вполне реально может быть фишка в том что в своё время когда вижуал бесика ещё не было и даже джавы ещё не было на этом си++ была написана куча чисто прикладного софта вроде «автоматизации бухгалтерии и производства» и ещё примерно столько же ж ещё до того ещё на «чистом си» а теперь наши дни надо бы б всё это взять и выбросить )) но не поднимается рука тем более что сегодня всё равно под всё это можно нанять 100500 падаванов «якобы сишников» половина из которых «пишет на плюсах в стиле джавы» а другая половина олицетворяет классический анекдот «программист на фортран может писать на любом языке как на фортран» (к) (тм)

так что да приходите в «плюсы» там вот это всё что ты написал ))

ЗЫ: это ты ещё реальную прикладную IoT не видел там реально Arduio с малинкой впустили в загон кучу реально нереальных хомячков )) опять же ж рупь пучок ))

«на новые кошерные std::vector-ы»

:) може смарт-пойнтери

реальную прикладную IoT

MBED

ЗЫ:
ще забув добавити multimedia до перспективних напрямiв

:) може смарт-пойнтери

ніт ))

ще забув добавити multimedia до перспективних напрямiв

порносайты штоле ))

3д графика

Мне кажется, уже давно неактуальная область для C++. Всё самое критичное по времени выполнения пишется с помощью шейдеров, а там свой, хоть и C-подобный язык. Для кода же, который не столь критичен по времени исполнения, использовать именно C++ не так уж и обязательно — благо, байндинги для того же OpenGL есть хоть для Python.

движки для игрух на С++. и если игруха модная, то ИИ и 100500 объектов надо обрабатывать, понимая про память и алгоритмы, а то в проц не влезешь.

Движки — да. Но саму игровую логику зачастую можно писать чуть ли не на скриптовых языках наподобие Lua. Не сильно в теме, но единственное исключение, о котором знаю — это Unreal Engine: вот там-таки «плюсы» нужны и для написания кода самой игры.

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

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

Можно, и так делали в нулевых. И у Unreal Engine был свой UnrealScript. А потом поняли, что программистам удобнее работать с плюсами — у них банально лучше инструментарий — а геймдизайнерам (непрограммистам) код вообще лучше не давать писать, кроме как в системах визуального проектирования типа Blueprint. Сегодня в геймдеве скриптовые языки не в фаворе, а программисту в геймдеве нужен или C++, или C#.

Подписаться на комментарии