Опрос: Три-пять лучших фич C++

производительность среднего алгоритма в вакууме на JS равняется производительности WAsm

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

https://takahirox.github.io/WebAssembly-benchmark/
https://dev.to/linkuriousdev/to-wasm-or-not-to-wasm-3803
и в последней статье еще ссылка на числодробилку:
https://www.dotconferences.com/2019/12/vladimir-agafonkin-algorithmic-perform... — 14-й слайд, JS выдает 90% производительности Rust/C.

Это к слову о том, что для C++ еще есть ниши, что не все могут позволить себе заваливать задачи железом, и так далее. Да, там по потреблению памяти у JS хуже, и я подощреваю, что это и есть основная причина отличия производительности — иначе бы оптимизированный JS и вовсе был бы равен C/C++/Rust.

Почему так происходит? Потому же, почему не умирает Python: в основе лежат структуры данных и функции на C/C++, которые работают так же быстро, как и другой C/C++, и быстрее, чем аналогичная функциональность, слепленная с нуля на виртуальной машине.

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

В активной фазе я это делаю примерно последние 15 лет. Надо сказать, что по большей части я делаю это скрытно, и только на форумах иногда откровенничаю. В том числе на моей прошлой работе я настолько удалился от последнего коллектива, что мы по итогу расстались. Ну то есть у меня был выбор: тащить проект, ловить ссаные тряпки за это, и ударными темпами выгорать, либо искать новую работу. Я выбрал наиболее разумное решение. Причем, много лет назад я таки выбрал первое, так что не надо тут рассказывать про «трус, начни с себя» — я выгорел до такой степени, что вообще хотел уйти из IT.

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

Внезапно, я ищу в споре истину. Тебе может это быть незаметно, но если ты посмотришь на меня хотя бы 2 года назад, то увидишь заметно отличающегося человечка. LOR реально много мне дал. Например, всего год назад я хотел изучить Rust, а теперь я распохейтер. Года полтора назад я всё еще думал, что C++ ужасен и единственный способ что-то с этим сделать — улучшать Си (привет Zig-у), а теперь я вижу, что обрезанный C++ уже в значительной степени близок к идеальному Си. Конечно, для окончательного достижения цели нужно убрать кучу UB, но в мире нет ничего идеального, а с тем, что есть, уже вполне можно работать.

Я думал, ты в Израили живешь

Я похож на еврея? Ну таки спасибо за комплимент.

А была бы воля фанатиков, так переписали бы и Qt без ООП

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

Что плохо в классах C++? Я исходном сообщении есть ссыль на целый талмуд о том, что именно плохо.

https://yosefk.com/c fqa/

А какая разница? Смысл в их поведении, а не в том, где они объявлены

Ну так а я о чем? Смысл в том, что я считаю смыслом, а не в объективных критериях.

Qt давно устарел

Ничего он не устарел. В мечтах хипстеров-фанатиков только если.

нужен более простой безопасный язык логики, в качестве которого выбрали JS

Ты давай полностью пиши суть. JS встроен в QML для описания поведения интерфейса. Можно конечно и целиком на JS (но не для любой функциональности), но это тупой подход - код становится трудно отлаживаемым и плохо читаемым, со своими приколами в части передачи по ссылкам и т.п.

Потому что путь высокопроизводительносй логики на C++ требует еще более сложных и решительных действий, то есть, многопотоки, многозадачи. распределенные системы, GPGPU, и так далее.

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

Ну так а я о чем? Смысл в том, что я считаю смыслом, а не в объективных критериях.

Не юли. Разве ООП критерий - это встроенность типа в компилятор?

нужен более простой безопасный язык логики, в качестве которого выбрали JS

Ты давай полностью пиши суть

Я не понял, какая тебе суть нужна.

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

Бро, я лет 6 активно участвовал в разработке блоатвари на очень схожих делфях. Проблема не только в «падают в обморок», а еще и в том, что единственная паршивая овца может угробить весь проект. Дизайнеры похерят верстку с примерно одинаковым успехом.

И я тебе напоминаю, что Qt - это далеко не только гуй

Для 2021 это «не только» там настолько смишное, что про него говорить серьезно нельзя. Для 1995 Qt был крутым, но сейчас — сорян, девяностые прошли.

Разве ООП критерий - это встроенность типа в компилятор?

Я не знаю, что такое «ООП критерий». То, что ты подразумевал под этим, включало в себя почти все инструмента во всех языках, то есть, грубо говоря, если я складываю целое и веещственное число — у меня же ООП. А поскольку тогда не существует языка/инструмента, не удовлетворяющего «ООП критерию», то этот критерий теряет смысл. С чем я тебя и поздравляю.

Я не понял, какая тебе суть нужна.

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

Бро, я лет 6 активно участвовал в разработке блоатвари на очень схожих делфях. Проблема не только в «падают в обморок», а еще и в том, что единственная паршивая овца может угробить весь проект. Дизайнеры похерят верстку с примерно одинаковым успехом.

А что, овца на js не может сложить проект? Сложить проект в принципе можно в какой бы парадигме оно не было бы написано. Это не проблема ООП, это проблема низкой квалификации и плохой архитектуры.

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

Для 2021 это «не только» там настолько смишное, что про него говорить серьезно нельзя

Файловая система, сеть, sql, гео, bluetooth, serial port, строки, многопоточка, изображения, печать - и это только то что я использовал, а ведь там еще можно дописать. Ну посмейся, раз тебе смешно.

Я не знаю, что такое «ООП критерий». То, что ты подразумевал под этим, включало в себя почти все инструмента во всех языках, то есть, грубо говоря, если я складываю целое и веещственное число — у меня же ООП. А поскольку тогда не существует языка/инструмента, не удовлетворяющего «ООП критерию», то этот критерий теряет смысл. С чем я тебя и поздравляю.

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

это проблема низкой квалификации и плохой архитектуры.

Да, это именно проблема низкой квалификации «сеньоров» этой шаражки. В нормальной фирме где нужно два апрува для любого комита никто не может сложить проект.

Блин. Ну а почему бы в случае багов Qt не предложить самостоятельно тот же патч, если собственные сеньеры круче ихних?

нужен более простой безопасный язык логики, в качестве которого выбрали JS

А в чем его безопасность? В том, что можно любое говно запустить и оно запустится, ничего не упадет, что там будет выполняться, но один хер нормально работать не будет? В том что любой недоучка прошел курс для идиотов и кричит: «все, теперь я программист». Компилятор - прекрасное изобретение, он позволяет часть ошибок найти ЗА программиста и предложит их исправить, таким образом, как минимум часть из возможных ошибок при условии успешного запуска приложения уже будет исправлена, а в JS похерачит все сразу со всеми ошибками и проблемами. И кстати, неидеальность js как минимум подтверждает появление такого языка как TypeScript.

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

Адекватные разработчики? Где ж их найти? И сколько они будут стоить? Я подчеркиваю, что речь уже будет идти про два языка. Макаки, вон, целую вечность третий питон осваивали, а тут целый новый язык. Ты бы еще предложил в эту всю кучу еще и лисп для метапрограммирования закинуть. Сравни это с UWP, где язык один.

А что, овца на js не может сложить проект? Сложить проект в принципе можно в какой бы парадигме оно не было бы написано. Это не проблема ООП, это проблема низкой квалификации и плохой архитектуры

Может, но это намного сложнее. А «намного» напрямую выливается в риски и стоимость проекта.

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

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

Файловая система, сеть, sql, гео, bluetooth, serial port, строки, многопоточка, изображения, печать - и это только то что я использовал, а ведь там еще можно дописать. Ну посмейся, раз тебе смешно

Если ты что угодно из этого спиcка собрался использовать на серьезном уровне, особенно файлы, сеть, SQL, потоки — тебе придется выкинуть стандартные реализации Qt на помойку. К сову о том, почему Electron не настолько хорош, как его рисуют. К сожалению, сделать эти штуки продвинутыми и при этом кроссплатформенными — это непосильная трудоемкость.

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

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

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

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

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

И кстати, неидеальность js как минимум подтверждает появление такого языка как TypeScript

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

Адекватные разработчики? Где ж их найти? И сколько они будут стоить? Я подчеркиваю, что речь уже будет идти про два языка. Макаки, вон, целую вечность третий питон осваивали, а тут целый новый язык. Ты бы еще предложил в эту всю кучу еще и лисп для метапрограммирования закинуть. Сравни это с UWP, где язык один.

Лисп я не предлагал. Про UWP: он не кроссплатформенный. QML вместе с JS в Qt достаточно прост, я бы не сравнивал это со знанием C++. Кроме того на Qt/QML можно под ведроид пилить.

Может, но это намного сложнее. А «намного» напрямую выливается в риски и стоимость проекта.

С хера ли сложнее? Точно так же.

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

Не тяжело, а тяжелее чем в JS. И опять ты переворачиваешь мой аргумент. Я не говорю, что компилируемость исключает ВСЕ ошибки. Я говорю, что компилируемость исключает часть ошибок.

Если ты что угодно из этого спиcка собрался использовать на серьезном уровне, особенно файлы, сеть, SQL, потоки — тебе придется выкинуть стандартные реализации Qt на помойку

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

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

Не юли бл***. Мысли ты читать не можешь. Ты попытася выставить несостоятельность моего аргумента за счет подмены его своим абсурдным примером. Хватит пи3**ь и оспаривать то, что я не утверждал.

Вот мое утверждение:

Опрос: Три-пять лучших фич C++ (комментарий)

vec4 и mat4 - это аналоги объектов из C++. Как минимум у них есть конструкторы и перегруженные операции умножения.

Проблема в том, что самые примитивные ошибки одинаково успешно отлавливаются как тестами, так и типами

Ага. Экономим время на компиляции, зато тратим его больше на поиск ошибок. Какая крутая фича.

Самая большая проблема как раз заключается в ошибках логики

Так никто и не спорит с этим. Еще раз: я не утверждаю, что компиляция исключает все ошибки, она исключает ЧАСТЬ, а в js ты эту часть будешь ловить тестами.

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

Это уже огромный плюс.

Получается, что вот например ты отстаиваешь то, что js круче c++ потому что проще, нет компиляции и все ошибки в рантайме. Но оказывается есть ts который лучше js потому что компиляция и статические типы.

И да, я ошибся, там тайпдефнуть не получится — только макросом атрибут cleanup докидывать.

В каждом месте, ага.

Хер с два он проиграл. Ты мне это скажешь, когда рейтинг Go и количество вакансий на нем догонят C++. https://www.tiobe.com/tiobe-index/.

Hе стал бы, конечно, говорить, что С++ проиграл Go, хотя бы потому что полностью заменить один другим не получится. Но у тебя тоже странная логика: Go уже в двадцатке. Я бы ставил на то, что через год-два он будет в десятке. Подозреваю, что с вакансиями ещё быстрее будет.

Так когда он будет выше в рейтинге и в количестве вакансий, тогда я скажу - ок, go выиграл. Но пока то нет.

Ну тогда подождём, хотя на твоём месте я бы заранее подыскивал пути отступления. (:

QML вместе с JS в Qt достаточно прост, я бы не сравнивал это со знанием C++. Кроме того на Qt/QML можно под ведроид пилить

Самая-присамая большая проблема заключается в том, что вообще-то кресты в GUI уже почти никому не нужны, кроме пары разработчиков браузеров, да и то последние тоже думают об уходе на другие языки. То есть, в принципе, GUI можно было бы писать на голом JS. Но в реальности если ты захочешь какую-то минимально кастомную фичу, то придется бежать на поклон к крестовикам. Таким в 90-е был подход к разработке GUI у Microsoft, но девяностые уже прошли и разрабы хотят единственный язык на котором можно было написать всё, который был бы безопасен, на котором можно быстро написать «набросок, потом перепишем», и потом десять лет крутить его в проде. «Серьезный качественный софт» с «быстрыми интервалами релиза» 1-2 раза в год уже никому не нужен.

Может, но это намного сложнее. А «намного» напрямую выливается в риски и стоимость проекта.

С хера ли сложнее? Точно так же

С такими успехами ты дойдешь до «зачем нужна сишка, если есть ассемблер». Намного сложнее, НАМНОГО. Настолько намного, что можно брать первую мартыху с улицы, садить ее писать на реакт, без ревью тыкать ее код в прод, и оно будет работать, по крайней мере не сломает проект. Мне нужно объяснять, что произойдет в аналогичном сценарии на крестах? На крестах сеньорам нужно очень сильно постараться, чтобы достичь того же уровня дуракоустойчивости, который в JS есть из коробки.

И опять ты переворачиваешь мой аргумент. Я не говорю, что компилируемость исключает ВСЕ ошибки. Я говорю, что компилируемость исключает часть ошибок

А я пишу, что компилируемость исключает только самые очевидные ошибки, которые очень быстро отлавливаются самыми простыми тестами. Это раст реально заточен под проверку на этапе компиляции, а в крестах UB на UB и UB погоняет. Блин, даже в Паскале меньше UB... да что там, даже в Фортране меньше UB, чем в крестах. От того, что ты научился писать на крестах и не слишком часто стрелять себе в ногу, кресты не стали безопасным языком.

Если ты что угодно из этого спиcка собрался использовать на серьезном уровне, особенно файлы, сеть, SQL, потоки — тебе придется выкинуть стандартные реализации Qt на помойку

Во первых, понятие серьезность - это твоя субъективная оценка

Файлы в Qt не умеют в асинхронный ввод-вывод. Это всё, что тебе нужно знать про «серьезность» системных либ Qt. Официальная позиция разрабов — создавайте потоки. Но потоки — это новая самостоятельная беда.

Опрос: Три-пять лучших фич C++ (комментарий)
vec4 и mat4 - это аналоги объектов из C++. Как минимум у них есть конструкторы и перегруженные операции умножения

Нет у них никаких конструкторов и перегруженных операций умножения. Иначе ты приходишь к тому выводу, к которому пришел я. vec4() — это паскалевый оператор каста:

https://wiki.freepascal.org/Typecast#caveats

В Сишке это пишется еще так:

typedef struct {
    int  field1;
    bool field2;
} structname;

structname somefunc(void)
{
    return (structname){ .field1 = 2, .field2 = true };
}

Ололо, где тут конструкторы?

А то, что в ЯП для векторных вычислений можно производить операции над векторами — это автоматически делает язык ООП?

Проблема в том, что самые примитивные ошибки одинаково успешно отлавливаются как тестами, так и типами

Ага. Экономим время на компиляции, зато тратим его больше на поиск ошибок. Какая крутая фича

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

Чтобы реально экономить время на тестировании за счет более сложной компиляции, нужно прежде всего убрать 70% UB, небезопасных, и просто дебильных фич из крестов. Но этого никто не сделает, потому что путь разработки у крестов только один — больше новых фичей. Я не спорю с тем, что теоретически возможно упростить разработку за счет ловли ошибок при компиляции, но C++ точно не позволяет этого добиться. C++ прежде всего принят индустрией за то, что позволяет автоматизировать написание багов, за счет чего баги получаются более гомогенными и для их исправления нужно смотреть меньше строк кода.

Получается, что вот например ты отстаиваешь то, что js круче c++ потому что проще, нет компиляции и все ошибки в рантайме. Но оказывается есть ts который лучше js потому что компиляция и статические типы

В TS можно писать на голом JS, если чо. Для защиты от джунов есть еще линты. Это просто дополнительные рубежи, как статические анализаторы для C/C++. Я могу придумать подобный JS язык, в котором польза от проверки типов во время компиляции была бы смехотворна, поскольку язык сам по себе безопасен. Но JS такой, какой он есть, потому там в наличии широкий ассортимент граблей, на которые обязательно наступит джун — это не общее свойство динамических языков и отсутствия статических проверок, это свойство конкретно JS.

Фундаментальный букет граблей — это слабая типизация и полиморфность не по делу, который был заложен господом за 10 дней создания изначальной реализации JavaScript. И TS нужен именно для того, чтобы гарантировать мономорфность кода. Исправь эту проблему — и ты устранишь большую часть смысла существования TS.

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

Например, вы можете попробовать привести примеры функциональности классов, которая будет потеряна вместе с исключениями и конструкторами.
Давайте предположим, что у нас есть гипотетический язык Ц++.
Пусть этот язык обладает всеми «фичами» C++, кроме исключений и конструкторов.
Расскажите, какие проблемы вы видите в этом языке? Будет ли при этом неминуемо утрачена какая-то ещё функциональность из C++, помимо конктруторов и исключений? Какие проблемы вы видите у этого языка?

Есть три фичи крестов, которые приколочены друг к другу гвоздями: RAII на конструкторо-деструкторах, исключения, и перегрузка операторов. Смысл их в том, чтобы в языке можно было писать «a = b + c» и не париться о том, где хранится «b + c» и как оно присваивается. То есть, теряется огромный пласт неявных операций выделения-высвобождения-перемещения-копирования объектов, причем, не обязательно именно в операторах, но также и в обычных функциях плана «передать результат одной функции аргументом другой функции», что можно считать неявным присвоением.

Проблемы языка с Optional в качестве результата конструктора обсуждались в моем треде:
Функциональщина на C++
Коротко: программа очень быстро оказывается заваленной шаблонами и алгоритмами обработки вариантов, со свойственными такой программе невменяемыми сообщениями об ошибках. Я уже написал, чего крестам не хватает, чтобы избежать такой судьбы — это богатых встроенных типов, чтобы ветвиться по тому же Optional легко и непринужденно, с минимумом ментальных усилий по сравнению с классическим крестовым кодом.

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

У меня недавно возникала та же мысль. Весь смысл классов C++ сводится к сахару для передачи первого аргумента и статической генерации vtable. Причем, я настаиваю на том, что дальше идти ни в коем случае нельзя и все остальные относящиеся к классами фичи крестов губительны. Идея RAII очень заманчива, но без конструкторов и исключений от крестового RAII остается только смишной сахар над «goto cleanup».

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

Уф-ф-ф, ошибки инициализации агрегатных объектов... Я боюсь, что автоматическое срабатывание деструкторов могло бы принести много своих радостей.

При этом создатель метода в праве выбирать в качестве возвращаемого значения как Optional, так и экземпляр объекта.

То есть язык требует возвращать объекты по значению? Или он будет требовать все объекты выделять исключительно на куче?

Лично моя позиция — таскать строго тривиальные объекты по значениям, далее уже по необходимости оптимизировать копирования-перемещения этих значений. Страсть Страуструпа к монстрам с пятидесятью щупальцами привела к тому, что в классах смешалось слишком много плохо сочетающихся фич — и прежде всего нужно отделить объекты-значения от агрегатов, оперируемых по ссылкам. То есть, объекты-значения становятся тем, что нынче называется «rvalue reference» — изменяемые объекты, у которых нет адреса. При это для объектов-ссылок нужно явное управление жизнью, то есть, через всякие там shared_ptr и прочее.

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

Как будет выглядеть обработка ошибок инициализации, скажем, десятка объектов в одной функции?

Справедливости ради, то, как в крестах реализовано RAII массивов, представляет собой еще тот костыль. Самый безопасный способ — выделять память одним запросом под десяток зомбяков, далее безошибочно инициализировать их «пустыми» значениями, и далее при ошибке просто все десять объектов условно высвобождать. Примерно так делает Object Pascal. Эта проблема не вызвана отсутствием RAII, исключений, атомарной инициализации, а вызвана страстью архитекторов C++ к вообще-вообще-вообще нулевой стоимости абстракций ценой самых безумных UB, что привело к опасной сущности «неинициализированный объект в неопределенном состоянии» — хотя там, где производительность реально нужна, всё пишется руками, а где нужна надежность и высокоуровневость, такие микрооптимизации не делают погоды. К тому же, в режиме оптимизации сам компилятор может обнаруживать неиспользуемое пустое инициализированное значение и оптимизировать его до неопределенного значения, которое точно никогда не будет видимо в программе.

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

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

А я бы все-таки рекомендовал JS, или в крайнем случае Go. Слишком уж жава ублюдочна i.e. построена вокруг тупиковой фундаментальной конструкции, которая неудобна в разработке и еле ползает при выполнении. Превосходные средства отладки? Ты можешь на жаве выполнить произвольный код в контексте программы? Перезагрузить модули в работающем приложении? А это возможно на JS.

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

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

Derived(int a, int b, int c): Base(a, b, c) {}

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

Начну искать, когда количество вакансий будет меньше количества соискателей.

Почитай " Inheriting constructors" здесь: https://en.cppreference.com/w/cpp/language/using_declaration

Офигеть, они с ума сошли, еще одну щупальцу осьминогу пришили.

Если я, к примеру, буду писать что-то в 100% сишном стиле, и мне потребуется полиморфизм (например, паттерн стратегия), я в гробу видал эмулировать vtable вручную

Стоимость switch по нескольким константам сравнима со стоимостью чтения vtable. А std::visit сам строит статический vtable, без каких-либо торчащих наружу классов. Так что понятие «полиморфизм» тут не совсем ясно, но я подозреваю, что тебе нужны просто vtable.

страстью архитекторов C++ к вообще-вообще-вообще нулевой стоимости абстракций ценой самых безумных UB, что привело к опасной сущности «неинициализированный объект в неопределенном состоянии»

Справедливости ради, те же контейнеры STL, вплоть до примитивного shared_ptr, используют вспомогательные объекты-прокладки для ссылки на конечные содержащиеся объекты. Так что до нулевых накладных расходов там как до киева раком, но кто ж там разбирался, когда принимали решение.

Самая-присамая большая проблема заключается в том, что вообще-то кресты в GUI уже почти никому не нужны, кроме пары разработчиков браузеров

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

язык на котором можно было написать всё, который был бы безопасен

Да это манипуляция. Да js не падает. Но это просто перетекание проблемы поиска ошибок на стадию выполнения.

С такими успехами ты дойдешь до «зачем нужна сишка, если есть ассемблер». Намного сложнее, НАМНОГО. Настолько намного, что можно брать первую мартыху с улицы, садить ее писать на реакт, без ревью тыкать ее код в прод, и оно будет работать, по крайней мере не сломает проект. Мне нужно объяснять, что произойдет в аналогичном сценарии на крестах? На крестах сеньорам нужно очень сильно постараться, чтобы достичь того же уровня дуракоустойчивости, который в JS есть из коробки.

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

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

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

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

А пишу что это уже хорошо, что не нужно потом тратить на эти ошибки время.

а в крестах UB на UB и UB погоняет

Ну так пиши так, чтобы не было UB.

Файлы в Qt не умеют в асинхронный ввод-вывод. Это всё, что тебе нужно знать про «серьезность» системных либ Qt. Официальная позиция разрабов — создавайте потоки. Но потоки — это новая самостоятельная беда.

Надоели мне эти твои СЕРЬЕЗНЫЙ/НЕСЕРЬЕЗНЫЙ. Ты давай бля пример кода на Qt с использованием файлового API который не работает. И пример того, как он обернутый в поток тоже не работает. А то это уже копание в фантазиях.

Нет у них никаких конструкторов и перегруженных операций умножения

Я не знаю как оно написано внутри. Но ведут они себя как объекты и классы. Вот кстати заметка от khronos в которой бл*** чкерным по белому написано «constructors» https://www.khronos.org/opengl/wiki/Data_Type_(GLSL).

Ололо, где тут конструкторы?

Сам отвечай на свое утверждение и свой код, мастер выдачи своих аргументов за чужие.

Отличная история от апологета ЯП, в котором принято иметь ошибки, проявляющиеся на каждом сотом выполнении теста.

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

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

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

Учитывая, что ts компилируется в js это очевидно, если что.

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

Сначала придумай и внедри. А потом хвались таким.

это не общее свойство динамических языков и отсутствия статических проверок, это свойство конкретно JS

Как минимум статическая проверка изымает несоответствие типов с времени выполнения на время компиляции и это очень хорошо.

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

Бля, это очевидно. Не строй из себя оракула. Так вот статическая типизация и увеличивает предсказуемость.

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

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

Ну так пиши так, чтобы не было UB.

UB - это не баг C++, а его особенность, его сила. Да, игрушка на C++ будет крашиться раз в неделю, но зато работает быстро и памяти ест не так много, как если бы была написана на другом языке.

Чтобы писать на C++ без UB, надо превратить его в другой язык. Например, надо перехватить переполнение целочисленных переменных. Можно написать безопасные методы для математических операций, но с их помощью не напишешь формулу - не будет приоритетов и возможности создать несколько неявных переменных. Например, в a = b * c + d * e у нас для произведений создаются две неявные переменные, которые будут сложены. Как такое сделать на функциях? Можно перегрузить операторы, но тогда лучше это сделать не для стандартных типов, а для каких-то своих.

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

Ты удивишься, но оказывается, что нужен. Во многих компаниях софт пилят на C++/Qt

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

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

Ты отстал от индустрии. Уже давно есть статическая проверка линтом, которая бьет линейкой по рукам за какой-нибудь оператор «==», присвоение к const, или + со строками. Синтаксис JS на порядок проще крестовых, он настолько проще, что серьезно сравнивать языки нельзя. Синтаксис C++ даже компилятор с трудом может разобрать, его невозможно разобрать чисто синтаксически, без анализа семантики — это тупо самый сложный язык во всей индустрия, даже сложнее какого-нибудь хаскеля, одних только способов инициализации переменных с десяток.

Ну так пиши так, чтобы не было UB

«Почему бы нам просто не писать софт без багов?».

Надоели мне эти твои СЕРЬЕЗНЫЙ/НЕСЕРЬЕЗНЫЙ. Ты давай бля пример кода на Qt с использованием файлового API который не работает. И пример того, как он обернутый в поток тоже не работает. А то это уже копание в фантазиях

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

Я не знаю как оно написано внутри. Но ведут они себя как объекты и классы. Вот кстати заметка от khronos в которой бл*** чкерным по белому написано «constructors» https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)

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

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

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

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

А тут мы внезапно вспомнили про опечатки. Двойные стандарты, однако: когда нам нужно — вот опечатки у вас, когда не нужна — так сразу из кода исчезает всё UB.

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

Сначала придумай и внедри. А потом хвались таким

Это совершенно разные вещи: придумать и внедрить. Потому я даже не пытаюсь делать никаких прототипов — все всё равно будут дальше писать на JS. Даже у гугла это не получилось, а куда там мне.

Как минимум статическая проверка изымает несоответствие типов с времени выполнения на время компиляции и это очень хорошо

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

Бля, это очевидно. Не строй из себя оракула. Так вот статическая типизация и увеличивает предсказуемость

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

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

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

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

UB - это не баг C++, а его особенность, его сила.

Нет спасибо, братан, мне кокс не нужен :-)

Чтобы писать на C++ без UB, надо превратить его в другой язык

Чтобы не быть голословным, покажи код, который невозможно написать без UB.

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

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

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

Петросян, тоже мне. Сравнил диплом с коммерческим ПО.

Другое дело, что за то же делфи плотют раза в полтора-два меньше

Дядя, ты дурак? Причем тут делфи? Я тебе уже писал, хорош самому придумывать тезисы и самому их героически опровергать. За C/C++ пока платят нормально. Не меньше чем за JS.

Ты отстал от индустрии. Уже давно есть статическая проверка линтом, которая бьет линейкой по рукам за какой-нибудь оператор «==», присвоение к const, или + со строками. Синтаксис JS на порядок проще крестовых, он настолько проще, что серьезно сравнивать языки нельзя. Синтаксис C++ даже компилятор с трудом может разобрать, его невозможно разобрать чисто синтаксически, без анализа семантики — это тупо самый сложный язык во всей индустрия, даже сложнее какого-нибудь хаскеля, одних только способов инициализации переменных с десяток.

Ок. Сложный. Но я не утверждал обратного.

«Почему бы нам просто не писать софт без багов?».

Ну и что ты опроверг? Прировнял UB к багу?

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

Ну так если ты не понимаешь работы Qt. То кто виноват? Длительные операции записи можно выполнять порционно с постоянными вызовами processEvents(). Если не хватает перфоманса, можно заюзать поток. А эти твои СЕРЬЕЗНЫЙ/НЕСЕРЬЕЗНЫЙ - это как мазня на заборе.

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

Херасе, сайт khronos - это забор. Да ти кто ваше? Твоя писанина - это забор.

Конструкторы из ихней документации — это один в один крестовый static_cast, не больше и не меньше. Важно здесь не то, что они назвали конструкторами, а то, что ты назвал конструкторами — а ты уходишь от этой ответственности.

А никуда не ухожу. Я пишу, что:

vec4 и mat4 - это аналоги объектов из C++. Как минимум у них есть конструкторы и перегруженные операции умножения

По поводу конструкторов - есть подтверждение, которое ты назвал забором. Специалист мне…

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

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

А тут мы внезапно вспомнили про опечатки. Двойные стандарты, однако: когда нам нужно — вот опечатки у вас, когда не нужна — так сразу из кода исчезает всё UB.

Опечатки у всех. Где я утверждал обратное, дядя? Но компиляция как минимум часть их соберет.

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

Не всегда.

Это совершенно разные вещи: придумать и внедрить. Потому я даже не пытаюсь делать никаких прототипов — все всё равно будут дальше писать на JS. Даже у гугла это не получилось, а куда там мне.

Тогда нечего балаболить.

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

Читай ниже мое сообщение.

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

Правильно и вместе с этим статическая проверка.

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

Ты запутался, что ты где утверждаешь:

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

но статические проверки мне очень даже нравятся

UB - это не баг C++, а его особенность, его сила. Да, игрушка на C++ будет крашиться раз в неделю, но зато работает быстро и памяти ест не так много, как если бы была написана на другом языке

Не соглашусь по поводу «его сила». Минимальные гарантии отсутствия UB, вроде проверки переполнения и границ буфера, стоят довольно дешево и в нормальной работе не приводят к ветвлению выполнения. Я понимаю, что сейчас будет что-то типа «ну на каждый доступ к массиву проверять границы будет дорого». Есть аш целых два варианта выхода из положения, оба задействованы в том же Rust: однократная проверка для неизменяемых объектов, и готовые функции библятеки, которые выполняют под капотом небезопасные операции после однократной проверки.

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

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

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

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

Петросян, тоже мне. Сравнил диплом с коммерческим ПО

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

За C/C++ пока платят нормально. Не меньше чем за JS

Да, я же не спорю. Но C/C++ методично сдает позиции. Я тебе примерно 2-3 сообщения назад уже отвечал, что пишут и на коболе, но тенденция очевидная — кобол уходит на покой, у него нет актуальных ниш вообще. У C/C++ ниши еще остались, но их сильно меньше фактического спроса на кодеров, а значит работодатели и их проекты будут долго, но уверенно перекочевывать на более безопасные языки с быстрой разработкой. Даже какой-нибудь CAD/CAM, для которого тоже актуально GPGPU и обвязка на любом безопасном, но отзывчивом ЯП. Счастье крестовиков здесь заключается только в том, что этих самых безопасных и отзывчивых языков и готовых решений под них мало.

«Почему бы нам просто не писать софт без багов?».

Ну и что ты опроверг? Прировнял UB к багу?

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

Херасе, сайт khronos - это забор. Да ти кто ваше? Твоя писанина - это забор

На этом можно и закончить.

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

Ты запутался, что ты где утверждаешь:

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

Я здесь вижу два разных утверждения. Ты не видишь? Твои проблемы.

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

Конечно. ПО для нефтянки разрабатывает команда разрабов фултайм. А диплом - один студент. Выбор очевиден.

Но C/C++ методично сдает позиции

Поговорим, когда не будет вакансий.

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

Баг, который проявляется изредка - это не обязательно UB.

На этом можно и закончить.

Да с радостью. У тебя и студент скилованнее команды опытных разарабов.

Я здесь вижу два разных утверждения. Ты не видишь? Твои проблемы.

Да у тебя всю дорогу проблемы.

Чтобы не быть голословным, покажи код, который невозможно написать без UB.

Хорошо.

int math_func(int a, int b, int c, int d, int e)
{
    return (a + b - c) * d / e;
}

При определённых параметрах функции будет UB. Что надо сделать, чтобы это предотвратить?

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

Стек вывести можно, но не везде. Возьмём простейший пример:

#include <iostream>
#include <vector>
using namespace std;


int main()
{
    vector<int> v = {1, 2, 3};
    cout << v.at(4) << endl;
    return 0;
} 

В Linux c gdb у меня такое:

$ g++ -ggdb test.cpp -o test
$ gdb -q test
Reading symbols from test...
(gdb) run
Starting program: /home/serg/cpp/test 
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 4) >= this->size() (which is 3)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: Нет такого файла или каталога.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7be6859 in __GI_abort () at abort.c:79
#2  0x00007ffff7e6c951 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7e7847c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7e784e7 in std::terminate() ()
   from /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7e78799 in __cxa_throw ()
   from /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7e6f3eb in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00005555555557fe in std::vector<int, std::allocator<int> >::_M_range_check (this=0x7fffffffdf20, __n=4) at /usr/include/c++/9/bits/stl_vector.h:1070
#8  0x0000555555555597 in std::vector<int, std::allocator<int> >::at (
    this=0x7fffffffdf20, __n=4) at /usr/include/c++/9/bits/stl_vector.h:1091
#9  0x0000555555555339 in main () at test.cpp:9

В принципе, то что требуется. Но в MinGW почему-то останавливается на gcc\x86_64-w64-mingw32\8.1.0\include\c++\bits\stl_vector.h:960

Но аргумент принимается, так как отладчик выдал то, что надо, хоть и выглядит оно не очень. Про Visual Studio я говорить не буду, не тот форум.

int math_func(int a, int b, int c, int d, int e)
{
    return (a + b - c) * d / e;
}

Ты имеешь ввиду деление на ноль и переполнение?

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

Так возьми тот же Qt Creator, он тебе красиво все подсветит и курсор куда нужно поставит.

Но аргумент принимается, так как отладчик выдал то, что надо, хоть и выглядит оно не очень. Про Visual Studio я говорить не буду, не тот форум.

Так а в чем вопрос тогда? MinGW под рукой нету. Но есть msvc в винде. Я конечно могу проверить, если ты очень хочешь, но мне кажется там норм с отладкой.

Ты имеешь ввиду деление на ноль?

Не только. Переполнение при сложении. Переполнение при вычитании. Переполнение при умножении. Деление на ноль. Деление на -1 при максимальном делимом.

Так а в чем вопрос тогда?

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

Не только

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

(a + b - c) * d / e;

(a + (b - c)) * d / e; // для случая когда a, b, c - большие положительные числа

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

предварительная оценка

Тут будет человеческий фактор. Это риск.

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

Берём uint64_t для факториала. Широкий же тип? Интуитивно кажется, что хватит для больших входных значений. Ну для 25 то уж точно хватит. Или нет? Проверяем. На выходе какая-то огроменная цифра. Ну значит ок, работает.

-fsanitize=undefined ловит переполнения, если достаточно просто чтобы программа падала на них

https://gcc.godbolt.org/z/YhdKqqxc8

Да, ты мне это уже показывал. Зачем подсказываешь? И потом это же не стандарт. Придётся надеяться, что каждый компилятор подобный флаг предоставляет.

А я бы все-таки рекомендовал JS, или в крайнем случае Go. Слишком уж жава ублюдочна i.e. построена вокруг тупиковой фундаментальной конструкции, которая неудобна в разработке и еле ползает при выполнении. Превосходные средства отладки? Ты можешь на жаве выполнить произвольный код в контексте программы? Перезагрузить модули в работающем приложении? А это возможно на JS.

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

2. Торговцы и прочие заказчики ПО хотят быстро увидеть рабочее ПО, чтобы зарабатывать на нем прямо завтра. Поэтому пердолинг на «Крестах» пойдет против воли рынка, где надо, чтобы было быстро сделано сейчас и устойчиво работало потом. Делать что-либо качественно возможно только на себя ибо деньги сейчас у купцов с ростовщиками, которые совершенство техрешения просто не поймут.

3. Джаваскрипт я тоже использую, но на Интернет-странице только. Он же однопоточный, поэтому не сможет выжать всю вычислительную мощь на сервере.

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

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

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

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

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

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

Так ты же делаешь утверждение. Ты и должен доказать. Или ты как Михалков: если я делаю утверждение, то я не должен ничего доказывать…

Тут будет человеческий фактор. Это риск.

Так программы пишут люди - это тоже риск.

Берём uint64_t для факториала. Широкий же тип? Интуитивно кажется, что хватит для больших входных значений. Ну для 25 то уж точно хватит

Лихо ты перескочил с изначального кода на факториал. Это ты уже новый код обсуждаешь? Тут тоже самое в общем. Есть таблица факториалов, ты можешь подобрать максимальный аргумент при известном типе и сравнивать предварительно. Это в общем банально. Ты же сам прекрасно знаешь. Конечно ты должен делать некоторые телодвижения, ты это доказываешь?