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

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

Щодо Стіренка — можу повірити, що з нього міг би вийти хороший ректор, під керівництвом якого у КПІ був би шанс вибратися з совка. Центр обчислень, яким він керував, був доволі солідним. І його аспіранти, які проводили пари, були цікавими розумними чуваками. У них я дечому корисному навчився — на відміну від більшості місцевих професорів/доцентів, які просто читали «з папірця» якусь нудну безнадійно застарілу програму.

Саме тому, що всі імена, що починаються з двох _, а також з одного _ і великої букви, зарезервовані для стандартної бібліотеки.
Її внутрішні деталі реалізації використовують такі імена, щоб гарантувати відсутність колізій з клієнтськими макросами. Бо ти маєш право зробити #define foo bar, потім заінклюдити стандартний хедер, і гарантовано в ньому нічого не зламаєш. Але якщо напишеш #define __foo bar — можеш поламати, ССЗБ.

Щодо імен, які починаються з одного нижнього підкреслення, за яким не слідує велика буква, — їх можна юзати в обмеженому скоупі (поля класів, локальні змінні). На попередній роботі був конвеншн юзати такі назви для приватних змінних у класі.
На поточній юзаємо m_. Спочатку було незвично, але виявилось теж доволі зручно. Це ж все-таки не угорська нотація, яка зашиває в назву змінної її тип. Ось вона — то вже перебор, як на мене.

* і коли ця лямбда має непустий список кепчурів. Інакше лямбда-корутини норм.

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

C++ заявлено як мову, котра безпечніша за С.

Ще Страуструп писав: «In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg». Це той випадок.

Усі постріли в ноги — від необачності.

Ну так це теж необачність. Людина забула, що написання лямбди з кепчуром — це те саме, що створення класу з відповідним полем. І якщо нестатичний метод класу зробити корутиною, така корутина може пережити сам об’єкт і звертання до полів буде робити use after free.

Для цього є compiler warnings.

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

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

Так, це граблі, але вони дуже логічні, якщо згадати, що таке лямбди в C++ по своїй суті.
Лямбда — це спосіб швидко згенерувати клас з перевантаженим оператором `()` і створити його інстанс.

Замініть в цьому прикладі `operator()` на будь-яку іншу нестатичну мембер-функцію (точніше, нестатичну мембер-корутину) — і отримаєте більш загальну форму цих граблей: нестатичні мембер-функції, що є корутинами, штука стрьомна. Адже об’єкт `*this` може померти, коли корутину хтось ще збирається резьюмити.

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

Ні, то я заснув обличчям на клавіатурі, перепрошую.

А ще там можна перевантажити оператор , (кома).
Це взагалі весело.

Якось на одній конференції Стефан Лававей — майкрософтівський чєл, відповідальний за їх реалізацію стандартної бібліотеки — показував приклад з циклом for у реалізації якогось generic алгоритму, де в третій частині інкрементилися два ітератори:

for (...; ...; ++iterator1, (void)+++iterator2)

Питає у аудиторії: «як думаєте, нафіга там каст до void?»
Не вгадав ніхто.

Відповідь: тому що клієнтський код міг оверлоадити оператор «кома» для своїх ітераторів xD

Їхало збочення через збочення,
Бачить збочення: в збоченні збочення.
Збочення, збочення, збочення, збочення,
Збочення, збочення, збочення, збочення.

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

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

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

really are

У каждого своё «really».

Не верю в существование «Stack Overflow-driven development». В реальности крайне редко встречаются задачи, решение которых от начала до конца будет присутствовать на stackoverflow. Разве что если компания постоянно занимается рутинным "формошлёпством"/"крудошлёпством"/etc.

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

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

Да и во всех мейнстримных реализациях стандартной библиотеки std::swap отмечен inline (constexpr с 20 стандарта, что также подразумевает inline для функций).

Так что не вижу смысла здесь имплементить свой свап.

Ну, це коли мова йде про використання об’єктів зі стандартними контейнерами. Не з усіма об’єктами їх використовують.

Але так, хороше правило by default: позначати move constructor і move assignment operator як noexcept, коли це можливо.

Щодо інших функцій — питання неоднозначне.
З одного боку, це непогано документує код для інших девелоперів, а також дозволяє темплейтному коду приймати рішення на підставі того, чи гарантує певний виклик 100% відсутність ексепшенів (подібно тому, як це робить std::vector при релокації своїх елементів).
З іншого — сама функція може стати повільнішою через вимогу стандарту детектити порушення «контракту» і викликати terminate.

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

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

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

Чи мається на увазі, що сама операція «=» має щось повернути? Тоді від цього маразму давно треба було позбутися — через його непередбачуваність людською логікою.

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

А построение логики приложения на эксепшинах считается просто гигантской индусятиной.

Крайности.
Как минимум, не performance-critical код на эксепшенах имеет ряд своих преимуществ (читабельность, отделение «нормального» воркфлоу от хендлинга ошибок в коде, всё такое). Не удалось открыть соединение с БД или подключиться куда-то по сети — кинули эксепшен. Это нормально.
Что касается низкоуровневых алгоритмов вроде той же сортировки — там да, эксепшены вряд ли привнесут что-то хорошее.

А вы тоже подумали, что это топик от Кожаева? :)