Комментарии 135
я конечно извиняюсь, но откуда такие "выводы" получились?
70% уязвимостей в продуктах связано с ошибками работы с памятью.
Более правильный вывод: в хромиуме по их подсчётам 70% ошибок (неверно называемых уязвимостями) в древнем докладе, который цитируют ежедневно в течение уже десятка лет, который описывает древний код связаны с работой с памятью
Эксплуатация уязвимостей позволяет запускать чужой код (RCE), получить полный контроль над системой и не только.
Давайте уже по правде - после создания виртуальной памяти / двух стеков каким-то образом использовать именно УБ в коде так, чтобы как-то подстроится в систему и сделать что-то осмысленное - невозможно. Если сами разработчики не могут понять что произойдёт, компилятор не знает что скомпилируется, то куда уж взломщикам понять во что выльется их попытка влезть в эту систему. Реальные уязвимости связаны с людьми и логическими ошибками (интерпретация логов и eval из любого интерпретируемого языка, попробуйте сделать это на С++)
С++ не обеспечивает безопасную работу с памятью.
Если покопаться, то хромиум из доклада это С или С с классами
Насчёт предлагаемых языков:
Утечка памяти
Эту проблему не способен решить никакой язык, более того, все из перечисленных "безопасных" языков содержат GC, который суть есть утечка памяти
C#, Go, Java, Ruby и Swift.
в языке Go нет 'const', при этом все функции принимают всё по (мутабельным) указателям, а менять данные из двух потоков - уб. Невероятно безопасный язык.
C# Java - ждём хромиум на этих языках, посмеемся
Ruby - земля пухом
Swift - никакой адекватный человек не стал бы использовать это, не будь это требованием для айфониан
Насчёт предлагаемых языков:
Действительно ли Rust - лучший язык, чтобы выстрелить себе в ногу? :)
Проверять тоже можно
Проект "Web2" содержит следующие уязвимые пакеты
[net8.0]:
Пакет верхнего уровня Запрошено Разрешено Уровень серьезности URL-адрес рекомендаций
System.Text.RegularExpressions 4.3.1 4.3.0 High https://github.com/advisories/GHSA-cmhx-cq75-c4mj
При билде, как в редакторе, так и в консоле:
warning NU1903: У пакета "System.Text.RegularExpressions" 4.3.0 есть известная уязвимость https://github.com/advisories/GHSA-cmhx-cq75-c4mj (уровень серьезности: высокий)
Более правильный вывод
Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.
куда уж взломщикам понять во что выльется их попытка влезть в эту систему
Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.
Реальные уязвимости связаны с людьми и логическими ошибками
Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.
Эту проблему не способен решить никакой язык
Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.
в языке Go нет 'const', при этом все функции принимают всё по (мутабельным) указателям, а менять данные из двух потоков - уб. Невероятно безопасный язык.
Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.
Windows, Linux, iOS, macOS, android
это всё очень древний код, более того, линукс вообще на 100% состоит из С, остальное основано на линуксе. Виндоус тоже недалеко от этого состояния ушёл
И все эти проблемы были бы решены безопасными языками
это шутка? На каком "безопасном языке" вообще можно написать линукс, виндовс и прочие из перечисленных ОС? Единственное на чём кроме С их можно написать - С++ без исключений (и то придётся вставлять всё равно ассемблер)
Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно.
это где оно "Эксплуатируется" ? Есть разница между "существует баг" и "эксплуатируется". Двойное освобождение, которое приведёт к падению программы - что там эксплуатировать? Целочисленное переполнение, тут то что эксплуатировать? Раст например ваш "безопасный" язык просто игнорирует переполнения, говоря что это норма (на релизе), получается иди да эксплуатируй?
Эта проблема полностью решена в GC языках как класс
Нет, утечки памяти невозможно решить, потому что вы даже не можете определить что такое утечка памяти. Банальное неэффективное использование памяти эквивалентно утечке, а языки с ГЦ колоссально неэффективно используют память.
Если бы вы хоть немного разбирались, вы бы знали, что в С++ сделать утечку сложнее чем в джаве
И самое главное, это не приведет к эксплуатируемой уязвимости
ну если определять как эксплуатируемую уязвимость "любая проблема в коде на С++", то да. Именно за счёт таких определений рождаются эти "уязвимости"
вас так любят, что я даже (некомпетентно) с Вами (извините) поспорю:
более того, линукс вообще на 100% состоит из С
насколько могу судить по собственному развитию, но продолжать писать сложный продукт в низкоуровневом стиле - это особый вид мазохизма. обычно (и наблюдаю это даже в своих никому не нужных маленьких проектах) собственно код постепенно разделяется на отдельные модули, причем низкоуровневый эволюционирует от монолита, живущего в своей папке, до модуля приложения, потом подключаемой библиотеки, а потом и отдельного фреймворка. (здесь надо пояснить различия в этапах: сначала просто выносим общие части в виде отдельных классов, которые очень прочно связаны с конечным приложением и не могут существовать отдельно; затем выносится в отдельную папку/пакет, который тоже нужен только конечному приложению и никак иначе - часто, например, отдельно он и не соберётся. следующая ступень - отдельный модуль. как бы всё то же как с утилитами - очень связан с главным приложением и без оного иногда и собраться не может, но типа лежит отдельно, чтобы так было удобно разработчику. следующий этап - библиотека, которая достаточно абстрактна и независима, чтобы использоваться другими проектами, но всё же пока ещё она подчиняется прихотям конечного приложения. и наконец настает этап фреймворка, когда уже он решает, как именно будет выглядеть приложение... со всеми соглашениями, требованиями, и т.д. а основное приложение больше похоже на вызовы различных операций фреймворка, что иногда выводит этот фреймворк на уровень построения, любых других приложений, главное, чтобы он всё сам)
Невероятно безопасный язык
ну, если делать как говорят, то код может остаться как минимум при загрузке, а если откажутся волевым отношениям - то нам действительно не по пути.
Если бы вы хоть немного разбирались, вы бы знали, что в С++ сделать утечку сложнее чем в джаве
да немного проще: просто уберите а исходниках любое хитрое приведение, текут все и подавлении о многих возможностей; и, надеюсь, адаптируются в будущем. а пока имеем не очень хороший код для виртуальной машины.
и на самом деле, очень спорный вопрос. для этого Вы должны понимать и код и автора...
Двойное освобождение, которое приведёт к падению программы - что там эксплуатировать?
вот так и рождаются уязвимости: а что в этот момент происходит в программе, что теперь делает процессор/виртмашина? наверное, исполняет код, который был пассивными данными.
Если бы вы хоть немного разбирались, вы бы знали, что в С++ сделать утечку сложнее чем в джаве
провокационно. не могли бы Вы пояснить, чем это так? потому что в Жабе мы имеем баги исключений и утечек, а в Сиси мы имеем баги падения приложений, плюс те же утечки.
ну если определять как эксплуатируемую уязвимость "любая проблема в коде на С++", то да.
да. и векторов атаки много: от исключения и выполнения произвольного кода, которого не было в системе, до уязвимостей "атаки по времени", т.е. чем меньше неудачная попытка взлома занимает меньше времени, тем ближе хакер к успеху. и тут уже не так важно, это конечный программист недоглядел, или разработчик самой платформы. важен результат: если удалось сломать, значит, уязвимость есть и редко она (особенно учитывая распространенное поведение контор вместо поощрения давать наказания и не исправлять ничего) не является чем-то незначимым. даже если удалось сломать программу и она не отдает вам ни денег ни паролей ни фамилий/адресов, то это всё равно успех как недоброжелателя, поскольку вам удалось затормозить бизнес и заставить понесли упущенную прибыль.
так что, в итоге: безопасность прежде всего, даже когда она отнимает часть свобод (переборщить тоже не надо, но нужно оставлять выбор). а ответственность несёт сам (конечный вендор) вне зависимости, какой косолапый со стороны вдруг заснул на работе.
насколько могу судить по собственному развитию, но продолжать писать сложный продукт в низкоуровневом стиле
С хотя бы +- читаем в отличие от плюсов
С хотя бы +- читаем в отличие от плюсов
долго держалась, но... вы это серьезно? оба языка не слишком читаемы потому что требуют низкоуровневых знаний, в отличие от... ну всех остальных языков
даже столь нелюбимый мной Rust и ещё менее любимый Go показали, что можно писать низкоуровневый код менее понятно, чем на С...
...
500 ой всё
Простите, но я лично не согласен с данным тезисом. До определённого этапа оба языка, C и C++, очень даже лаконичны и читаемы. Но при определённых подходах программирования оба языка превращаются в месиво. И тут стоило бы привести пример. Я вставлю GTK. Это прямой показатель, как код на C превращается в нечитаемое говно, которое даже дебажить невозможно из-за переполнения кода макросами. При этом есть библиотека gtkmm, которая используется для программирования под GTK на C++. И она в разы более адекватно выглядит. В противовес стандартная библиотека C++ в GCC. Там такой бардак с именами и костылями, что знать её хорошо - это целая отдельная компетенция.
И здесь есть нюанс, который стоит выделить. Несмотря на то, что код обоих языков может превратиться в дичь, у C++, за счёт больших возможностей самого языка, есть инструменты делать код лаконичным дольше, чем это можно делать на языке C. На определённом этапе язык C становится заложником своего же минимализма
остальное основано на линуксе
macOS/iOS ни в коем случае не основаны на Linux.
ну, у них есть общий предок - Unix ,и ещё раньше, (если не ошибаюсь) Minix, оттуда вышли и мак и линукс.
Так это же вечный спор Тененбаума и Торвальдса. Тененбаум топил за микроядро, а Торвальдс лепил монолит. И сейчас микроядро миникса в полной мере так нигде и не работает, ибо даже в iOS его не смогли достаточно изолировать, чтобы колоссально не потерять в производительности. При том тот же линукс за это время вполне себе из монолита разделился на само ядро и модули для него. Но он предполагает как монолитное использование, так и модульное, а ядро миникса так не может - только модульное. И почти все ОС сейчас в каком-то компромиссе между модульностью и монолитом. Но в части GNU - пакета программ, созданного группой товарищей во главе со Столманом, то в этом как раз и связь между UNIX и всем тем, что сейчас понапилено.
не помню конкретных фактов, но есть скандал, что ядро содержит в себе очень много - и какие-то драйвера, и ещё что-то, что, мол, не должно быть там. если вы в курсе, ио пожалуйста, киньте в меня ссылкой (жевательно на русском, но можно на английском),где можно об этом почитать
https://habr.com/ru/articles/171033/ - вот эту статью можно почитать.
сейчас микроядро миникса в полной мере так нигде и не работает
Intel management engine – какая-то шутка?
Ну поэтому я и говорю "в полной мере". Ну сколько там процессорных часов эта прослойка Intel ME наработала, какую пользу она приносит пользователю? Это встроенная сервисная ОСь, которая больше напрягает безопасников, чем приносит пользы. Вот когда на десктопах начнет устанавливаться не только энтузиастами в виртуальных машинах, вот тогда и поговорим о "в полной мере".
Максимально кринжевый аргумент. Тогда у всех фон Неймановских архитектур общий предок – ENIAC. Поэтому не надо их разграничивать. :)
В Go можно легко присвоить любое значение в указатель, я не понимаю чем это отличается от си.
Ну и про строгое определение поведения я не согласен, у языка нет формального стандарта, и получается что UB скрыто вуалью единственной реализации и надеждами что в следующей версии она не поменяется.
не такого понятия как UB
Ну и зря.
A send to a nil channel blocks forever
A receive from a nil channel blocks forever
A send to a closed channel panics
A receive from a closed channel returns the zero value immediately
DoS тоже вполне себе атака.
а косвенно из того же Javascript атакуют JIT
Вот только сам JIT по себе сводит безопасность "безопасных" языков (со стороны виртуальной машины) к нулю - генерируемый JIT-компилятором машинный код ей неподвластен.
то куда уж взломщикам понять во что выльется их попытка влезть в эту систему
в том и суть взлома: что на миллион неудачных попыток на миллион первый можно достичь ожидаемого хакером и не ожидаемого владельцем, поведения
все из перечисленных "безопасных" языков содержат GC, который суть есть утечка памяти
а вот это правда. уход от ручного управления памятью и времени жизни данных порождает проблему их своевременной смерти - что мы и наблюдаем во всех программах, написанных, начиная от компилируемых в jvm (java, kotlin, scala etc) и заканчивая... да любой платформой с gc, а дальше всё по формуле "максимум (квалификация_разработчиков_языка, квалификация_разработчиков_конечного_продукта)". и так выявить утечки памяти непросто, а когда уж не понимаешь, что с памятью происходит в который момент, то... возможны сюрпризы, и ищи год баг, который проявляется при особой позиции планет, но от которого интерфейс приложения чаще виснет, чем работает...
Невероятно безопасный язык.
да, если делать так же просто, как он сам и для чего создавался. а главное - понять философию языка. конечно, можно хоть на бейсике писать в стиле ассемблера, но... возможно, просто Вам не подходит целевой язык/платформа, а может, Вы языку, или и Вы и язык для решаемых задач?
(вот как пример: прекрасный язык Python несмотря на его лаконичность мне не нравится, а вот и Kotlin и Ruby нравятся, хотя генерируют код с немыслимым оверхедом - да лучше бы я на С# писала...)
C# Java - ждём хромиум на этих языках, посмеемся
а Вы не в курсе, что на этих языках и железки программируют, и даже целые почти операционки пишут? (ссылок не привожу ибо сейчас лень искать) и иногда даже удачно. да, оптимизация по скорости, памяти и особо, утечкам, оставляет желать лучшего, но тем не менее, если пользователь запустил, выполнил задачу и выключил, а не молотит что-то круглосуточно - то отлично работает.
Ruby - земля пухом
согласилась бы, но... сколько бизнеса крутится на Рубине, а уж сколько прикладного софта сначала требует руби рантайм и прочие зависимости... честно, после такого я готова писать на native kotlin, лишь бы избавиться от гигабайта зависимостей (но на сисярп пока не готова на такой хардкор)...
Swift - никакой адекватный человек не стал бы использовать это, не будь это требованием для айфониан
а не могли бы Вы подробнее рассказать мотивации? ибо, пока я не знала про kotlin, именно его я рассматривала как достойный шаг от Руби: и вменяемый рантайм имеется, а синтасахара столько, чтобы ещё 3 проградмабета получить к уже имеющимся.
(вместо послесловия) но Котлин меня спас - теперь я делаю на нём всё: и сайты, и десктоп, и мобилкины приложения, разве что в натив получается пока очень сложно, и в смысле конечного приложения, совсем никак, но: сервер я полностью делала на котлине, фронт я делала на котлине, даже расширение для браузера делала на котлине. и десктоп (с установщиком на венду и линух, не знаю, как там с яблоко-ос, скорее всего тоже заведётся, но проверить не могу). то есть на одном языке я могу собрать что угодно, только натив (под llvm) осилить осталось... где там Свифт, да даже С/С++/С# - сколько там требуется усилий для сборки под основные платформы?
а главное - понять философию языка. конечно
Тогда, наверное, стоит понять философию C++ и перестать писать плюсовый код, имеющий функции с сигнатурами вида int foo(ptr_t1 *src, ptr_t2 *dst) (пример из поста)? А там, глядишь, и за границы выходить перестанете.
С++ тоже не стоит на месте и постепенно обрастает модным нынче сахаром...
но проблема в том, что низкоуровневость языка осталась, и некоторые конструкции языка продолжают пугать. или это уже форма мышления кодеров, которые предпочитают этот язык? в других языках давно используется более... высокоуровневый, что ли, подход (даже в до-диез не встретишь таких конструкций), и только программисты Си/Си-Крест-Крест продолжают писать код так, как писали 30 лет назад. (или это моё такое впечатление)
я иногда перевожу какие-то проекты с С-подобных языков... так вот, перевод производится в несколько этапов:
сначала делаем код компилируемым
потом делаем код корректно работающим оглядываясь на различия начальной и целевой платформы
затем, блин, рефакторим во все места, делая код понятным без комментариев, используя весь доступный сахар.
и именно на последнем шаге невозможно сдержать мат, потому что слишком уж часто благодаря и стандартной библиотеке и сахару, целевого языка, код волшебно сокращается в несколько раз. а если подумать, то ещё несколько. иногда даже целые процедуры заменяем методом из стандартной библиотеки. после мата, ощущение такое, будто детей научила жить, Ей-Богу....
Если вы переписываете что-то с С/С++97-03 на что угодно, понятное дело, что там махровое легаси и выброшенные практики языка. Ощущения не сильно бы отличались, переписывай вы на C++17.
Не так давно работал над проектом, где нормой было в си-стайле маллокать в начале функции и фришить в конце (периодически забывая фришить в ранних ретурнах). Юз афтер фри во все поля и прочие приятные изыски. А все потому, что написано в 2003-2004 году и работало для win95.
Огромная часть багов ушла просто от того, что заменяли ручной менеджмент памяти на RAII захват и освобождение.
Так что проблема не только в языке, а еще и в том, что люди сталкиваются с тем, что было собрано 15 лет назад и естественно вызывает боль. Просто современные языки не успели "пожить" достаточно чтобы было легаси в двадцатку.
По большей части да, проблема в нежелании/невозможности писать современный идиоматичный плюсовый код. В меньшей части эти невозможности обусловлены требованиями (ультра производительность, считаем каждый байт и такт руками и т. п.), но там никакие безопасные языки и подавно не помощники. Там и С и С++, порой, не помощники.
извините за невежество, а разве улучшения языка (конкретно С++) как-то влияют на генерируемых код?
вот для примера: в котлин очень просто добавить, ну скажем, функцию uppercase для String (опустим тот момент, что в стандартной библиотеке есть и эта и много других функций). так вот, в java мне бы пришлось для этого делать новый класс с методом, принимающим значение строки и возвращающую строку. так вот, котлин делает именно это, хотя в семантике языка это выглядит будто я действительно добавила ко всем String новую функцию uppercase. в итоге код читаемее, а оверхеду нисколько.
что нам предлагает С++ в 2024 году?
что нам предлагает С++ в 2024 году?
Например, он предлагает нормальный кортеж :) Нет, не те убогие Pair или Triple из котлина, а настоящий, с произвольным количеством разнотипных элементов без всякого type erasure и динамических аллокаций, и нормальную работу с такими кортежами в вашем обобщенном коде:
Пример
#include <iostream>
#include <tuple>
template<typename... Ts>
class C
{
public:
C(Ts... args) : t{args...} {};
void print()
{
std::apply([](auto&... args) { ((std::cout << args << std::endl), ...); }, t);
}
private:
const std::tuple<Ts...> t;
};
int main()
{
C c1{"aa", 1.2, 3, std::string{"bc"}};
c1.print();
}Причем этот кортеж - это не "компиляторная магия", при желании можно реализовать его "вручную" (что, к слову, является куда более мощной возможностью C++, чем просто библиотечный кортеж, просто не столь наглядной).
P.S.
То же самое, но с perfect forwarding
#include <iostream>
#include <tuple>
template<typename... Ts>
class C
{
public:
template<typename... Args>
C(Args&&... args) : t{std::forward<Args>(args)...} {};
void print()
{
std::apply([](auto&... args) { ((std::cout << args << std::endl), ...); }, t);
}
private:
const std::tuple<Ts...> t;
};
template<typename... Ts>
C(Ts&&...) -> C<Ts...>;
int main()
{
C c1{"aa", 1.2, 3, std::string{"bc"}};
c1.print();
}А то еще придерутся некоторые :)))
Во-первых, это ложная дихотомия: наличие кортежей в языке не отменяет возможность их реализовать вручную.
Вы, очевидно, не поняли, что я хотел сказать. Ну попробуйте реализовать аналог плюсового std::tupleна том же котлине. Тех же вариадиков нет, сверток нет, будете вручную выписывать N вариантов с <T1, T2, ..., Tn>? Как будет выглядеть его использование, сможете написать что-то аналогичное коду, приведенному мной выше? Или, как это обычно бывает, заявите, что "потребности в колбасе нет"?
потребности в колбасе нет
знаете, вот правда. ни джава ни котлин, действительно, не могут похвастаться такими возможностями. но я вам скажу: иногда я извращалась, чтобы сделать определенную магию. иногда это получалось, иногда я упиралась в ограничения и языка и платформы. но в успешном варианте, сколько бы счастлива ни была, но основное разочарование приходило, когда понимала, что я это нигде использовать не буду.
Ах, потратьте выходные хотя бы на поверхностное ознакомление с template c++. И "магия" и "ограничения и языка и платформы" сразу пропадут. Ни джава, ни котлин, ни c# generics и близко не лежали.
Не научились и не научатся, ведь эта штука предназанчена, можно сказать, для прямо противоположного.
обкостыливать другие нелогичности
Собственно.
но, как и любые реалистичные куски, они потребуют больше контекста и затуманят общую идею
Я её и так не очень понимаю. Ну, т.е., да, некоторые вещи в плюсах выражаются весьма посредственно, некоторые не выражаются вовсе и их приходится эмулировать. Но как много из этих вещей широко используются где-то кроме наколеночных проектов, созданных из тяги к прекрасному?
Что поделать. "Нужно всего, в особенности того самого, и побольше" — такое себе решение.
Ну что тут можно сказать, https://isocpp.org/std/submit-a-proposal. Без пропозалов никто и ничего не будет в язык добавлять, даже тримы (тоже совершенно базовая вещь для языка со строками).
Вот человек потратил, наверно, не одни выходные: оффигенный пример с c++ template-ами, пример компилируется и работает, только практической пользы не видно.
Интересно, может кто-то продемонстрировать код с темплейтами, который действительно решает какую-то проблемму в практическом плане, и который нельзя переписать проще бЕЗ темплейтов? Только не простое использование темплейтов из стандартных библиотек, конечно. В библиотеках они вполне оправданы, конечно.
Интересно, может кто-то продемонстрировать код с темплейтами, который действительно решает какую-то проблемму в практическом плане, и который нельзя переписать проще бЕЗ темплейтов?
Не буду скромным:
Однако, на счет "бЕЗ темлейтов" не уверен, но уверен, что "бЕЗ" дешевле точно не будет.
Ну и еще парочка, но тут как раз "в библиотеках":
И это я еще с шаблонами С++ "на вы": приходится очень много выкуривать и изучать прежде чем такое сделать.
Я почему-то так и думал, что ничего, кроме философии за триста о том, как потенциально страшно жЫдь, я от вас тут не увижу :) В целом все ясно (С), вопросов больше не имею.
P.S.
можно я просто возьму что-нибудь более хаскелеподобное
Что-то вы мне все больше кое-кого напоминаете :) А что случилось с вашей предыдущей инкарнацией?
Какой тип будет у
tup2иtuptupздесь?
decltype(tup2) и decltype(tuptup), не благодарите :)
#if defined(__clang__) || defined(__GNUG__)
#include <cxxabi.h>
#endif
template<typename T>
std::string type_name( )
{
#if defined(__clang__) || defined(__GNUG__)
int status{};
return { abi::__cxa_demangle( typeid( T ).name( ), NULL, NULL, &status ) };
#elif defined(_MSC_VER)
return typeid( T ).name( );
#endif
}Не очень понял пример. Что такого впечатляющего в функции uppercase, не дающей оверхеда? Отдельной функцией всё без проблем решается. Добавить такую функцию-член в библиотечный std::string, конечно, не получится, но можно унаследоваться и в свой класс дописать что угодно, а для вызова функций, которые ожидают std::string просто кастовать к базовыму, это бесплатно.
в том и суть взлома: что на миллион неудачных попыток на миллион первый можно достичь ожидаемого хакером и не ожидаемого владельцем, поведения
проблема этого в том, что уб очень нестабильно, может поменяться с новым коммитом или просто с новым запуском, вкладывать ресурсы в "взлом" через такую мелкую щель просто невыгодно (зачастую это просто невозможно)
главное - понять философию языка
тут сразу 2 возражения:
1. Go создавался для многопоточности, единственный способ разделить данные в нём это передать по указателю, а константности нет. Язык располагает к ошибкам
если понять философию С++, то писать эффективно, понятно и безопасно это очень просто. Но пишущие статьи предпочитают взять худший код в мире и критиковать его
прекрасный язык Python несмотря на его лаконичность мне не нравится
мне он тоже не нравится, не понимаю как на нём вообще пишут не короткие скрипты
а не могли бы Вы подробнее рассказать мотивации?
не люблю языки привязанные к вендору и платформе
да даже С/С++ - сколько там требуется усилий для сборки под основные платформы?
Видимо имеется в виду именно для работы GUI, это зависит исключительно от библиотек, например Qt будет работать под кучу платформ сразу. А сами языки никак к платформе не привязаны, работают вообще где угодно
p.s. Маша, ты?
проблема этого в том, и это всё гадр что уб очень нестабильно,
наоборот, в этом и профит: очень многие программисты (даже я) оставляют за скобками такие моменты как - затирание памяти после использования (зачем, если этот мусор всё равно недоступен больше) и другие операции (переполнение стека, ну сломается программа и освободит все ресурсы). а на уровне процессора происходит иногда то, что он уверен, что хоть и произошла исключительная ситуация, но дальше надо исполнить "код" в сегменте данных (иначе бы не было никаких meltdown или spectre, которые тоже не гарантируют успех ч первого раза, а столько шума наделали)
если понять философию С++, то писать эффективно, понятно и безопасно это очень просто.
я и не только я считают это неверным, иначе бы ни было ни других платформ, ни языков. дело в том, что программируя на С/Сиси приходится держать в голове не только сам алгоритм, но и то, как определенная конечная архитектура поймет то, что вы написали (а это и размер данных 16-32-64-128, и что любой класс - это не эфемерная сущность, а имеет определенное положение в памяти и размер, строки - это массив данных и т.д., т.е. знание хотя бы принципов работы типа 8080 - обязательно). куда уж проще с созданием просто объектов и невозможностью доступа, когда никто его не способен использовать.
при этом, в поддержку предыдущего ответа: вы понятия не имеете, какой код у вас на выходе (ну потому что невозможно знать всё) - а хакер может угадать, он ведь специально учил и пробовал слабые места, пока вы (мы) учили, как быстро сделать заказ, и сценарии работы конечного кода неизвестны именно в силу ub, а ведь, как известно , софт (особенно, если это код для продажи, а не использования) не умеет развиваться не обрастая фичами, чтоб продаваться. а хакерам просто делать нечего, только находи кнопочные телефоны и выбрасывай в реку.
мне он тоже не нравится, не понимаю как на нём вообще пишут не короткие скрипты
ну, и на php есть возможность строить законченные приложения с гуями (gui, или же ui, и прочее "ого"), а синтаксис обязательного форматирования в угоду возможности писать хоть в одну строчку - вот иногда таскать свой алтарь и шликать что случилось сделать в 1 строчку и без магии) - ну, очень многим нравится.
не люблю языки привязанные к вендору и платформе
а есть такие? и хороших сотрудников скидывают с пропасти, если не называют неправильно "обратки из случаев ранее.
Qt будет работать под кучу платформ сразу.
да. но для сначала мёртвая и мертворожденная секта. да блин, силовом много десктоп библиотеки С/'++ вылетят сразу. но, оказалось, слишком сложно всё помнить а голове.
Достаточно обделаться со спецификатором формата в printf/scanf
компиляторы проверяют это
если у вас нет легаси-кода, то зачем вы вообще используете C++
затем что этот язык лучше других справляется с задачами?
можно забыть сделать free
невозможно забыть сделать free, если не делал malloc
В 2024-м году практически нет причин выбирать C++
ЕМНИП, фраза "В XXXX году практически нет причин выбирать C++" попадается мне на глаза с завидной регулярностью года с 2010-го, если не раньше. И, есть подозрение, будет попадаться еще лет 15.
В 2024-м году практически нет причин выбирать C++ (кроме, вероятно, целевых платформ, для которых нет компиляторов других языков, но и тогда я бы скорее взял что-то, компилирующееся в C, вместо написания кода на C или C++ напрямую).
Есть ли альтернатива С++ в крупном проекте, с кучей математики (а это автоматом тянет библиотеки типа eigen/opencv/ROS), инференсом нейросетей (tensorrt/cuda/npp) и возможностью быстро найти либу под любую задачу или быстро портировать её? Часто это все необходимо сделать под какую-либо борду, например, в беспилотнике. Как показывает практика, альтернативы нет даже близко. Любые решения с биндами библиотек превратят этот проект во франкенштейна с постоянными поисками багов в прослойках между основным языком и библиотеками.
Кстати об эффективном коде, есть на плюсах аналог такого https://hackage.haskell.org/package/accelerate , чтобы писать почти обычный для языка код по работе с массивами, а оно мне могло выплюнуть код и под CPU, и под GPU, и под ещё что-нибудь?
Звучит как очень странная задача с непонятной практической ценностью и неочевидной эффективностью. Есть где-нибудь сравнения того, что он выплёвывает с тем, что показывает какая-нибудь библиотека для cuda?
Можно ещё в другую сторону: есть на Хаскелле что-то типа https://google.github.io/highway?
Действительно, очень странно желать написать код, который потом будет работать и на CPU, и на GPU
Множества кода, который хочется гонять и на CPU, и на GPU, если есть возможность, думается, не очень большое. Если GPU в системе нет, то это 99% какой-нибудь сервер, где выгодно оптимизировать под конкретное железо и сэкономить хоть ещё 5% сверху, чем надеяться на либо, пусть она и неплоха в целом. А если GPU есть, то весь код, который на GPU обрабатывать выгодно пусть там и обрабатывается.
в окрестности 5-10% от производительности оптимизированной руками куды.
Ынтересно. Но было бы интересно что-то более специализированное. Поиск объектов (без определения точных границ), сортировка (актуально в свете архитектурных решений 4000 поколения).
Даже в компиляторе интринсики есть
Да, и в плюсах можно написать #include <intrin.h>, но эта либа предлагает несколько, мягко говоря, больше.
Или это мой ноутбук с настолько кастрированной встройкой, что на процессоре будет быстрее. Да и в CUDA оно не умеет.
Весьма пограничный случай (в ноутах с кастрированными встройками, как правило, и процессоры немощные), но соглашусь.
а тут — одинаковые
Вот именно эта часть, пожалуй, самая неинтересная. Если мы опускаемся до ручной векторизации, то, в целом, нужно иметь представление о платформе, иначе можно легко получить пессимизацию по сравнению с обычным кодом на языкнейм. Т.е., даже если я пишу cool_intrin вместо cool_x86_intrin/cool_arm_intrin, мне, таки, нужно понимать, cool ли этот intrin в этом случае, или не очень. Когнитивная нагрузка остаётся, экономятся символы. И даже тут: я посмотрел, там 16 разных plusInt (и всех остальных его коллег) в зависимости от типа. Т.е. мне правда, вместо Add(a,b), как в хайвее, нужно писать все эти plusInt16X16, plusInt64X8 и т.д. руками? Такое.
Бонусом идёт привязка к LLVM (не прям беда-беда, но тем не менее), отсутствие автоматической диспетчеризации (если не пропустил) и сильная ограниченность операций (сравнения, масочные операции? Встанет передо мной ответственная задача поиска минимального элемента в массиве, и что делать?).
Непонятно, причём ROS к математике, ну да ладно.
Это шутка такая? Вы список библиотек, которые с ROS идут, видели? Да и потом это SOTA в робототехнике.
Я в ответе на первую цитату привёл пару примеров либ. Можете быстро найти их аналог или портировать их?
Из моего скромного списка только пару либ, да. Проект, например, блок управления беспилотником. Там, кроме, того, что я написа будет еще два десятка либ (работа с CAN, камерой, облаками точек и т.д.). Вот, например, захотел ты DeepSORT, в репозиториях сразу десятка имплементаций и на С++ и на питоне. Что касается вашего вопроса, то сколько комманд эти либы используют? У стека ROS сотни тысяч разработчиков.
Ну вон тоже биндинги какие-то даже в официальной репе https://github.com/tensorflow/haskell
Вы перепутали tensorflow и tensorrt. Возможно, haskell очень удобен в деле обучения нейросетей и инференса, но это огромный проект. Биндинги к таким проектам изобиуют багами.
Кстати, если среди ваших требований будет pytorch, то, я так понимаю, альтернатив Python в крупном проекте не будет?
открою страшную тайну, так называемый "py"torch написан на C++ и имеет публичный api на нем же
Опять этот неведомый настоящий C++, на котором почему-то в проде никто не пишет, и настоящие программисты, которых не может нанять ни гугл, ни RH, никто.
Могут. Но у гуглов и ко кодовая база тянется с тёмных времён, им её переписывание и перетестирование во сколько обойдётся, в сотни миллионов? В миллиарды?
А где-то есть образцовый новый свежий реальный проект, не уровня привет мир, а побольше, на современном правильном безопасном С++, вот чтобы прям конфетка был? Чтобы прям захотелось после этого познать дзен и перейти на него навсегда? И чтобы не мучаться со всякими зависимостями, чтобы 1 строчкой поставить компилятор и тулзы для него, склонировать репу и 1 командой запустить пощупать?
От "Examples of memory safe language include C#" я очень сильно удивился. Дабы далеко не ходить классика жанра с циклическими ссылками
public class Pet{
Dog petName;
}
public class Dog{
Pet petName;
}
class HelloWorld
{
static void Main()
{
Dog tom = new Dog();
System.Console.WriteLine("Hello, World!");
}
}И в чём тут проблема?
Циклическая ссылка первый объект ссылается на второй, а 2-й на первый. В результате они никогда не будут удалены, и получаем утечку памяти. Полная аналогия, когда в C++ 2 shared_ptr указывают друг на друга.
Даже если бы это было проблемой, memory safety — это когда невозможно вместо объекта получить неинициализированную память (или попасть в середину чужого объекта), а не утечки памяти.
Вы прежде чем писать подобную чушь почитали бы как устроенные копирующие GC в современных языках. Стыдно должно быть.
У вас тут даже циклических ссылок нет. tom.petName будет null, ни одного объекта класса Pet в памяти нет...
Меня тут ниже абсолютно верно поправили, что GC прекрасно умеет такое обрабатывать. Извиняюсь за неверную информацию.
И что? Для GC циклические ссылки не представляют проблемы. Или вы о чем?
Как Вы относитесь к cpp2 by Herb Sutter
https://github.com/hsutter/cppfront
который является "расширением" C++ (похож на C#), цель которого "упростить" C++ и сделать его более безопасным?
Для меня выглядит как новые обои на старый фундамент. Ничем принципиально лучше раста не будет, а проблемы "универсального компилируемого" у него останутся. Да и не выглядит, что это "продакшн реди" еще лет 5-7.
Ну а ничем кроме обмазывания санитайзерами и следованию современным практикам в C++ безопасность и не сделаешь.
Странно, но rust вообще не упоминается как одна из альтернатив.
Преимущества перед растом - собственно тесная интеграция с плюсовой же кодовой базой. То есть постепенно переписать проект на это заметно проще ибо оно в итоге все равно в плюсы превратится.
Ну тут как всегда проблема того, что я не очень много видел плюсистов которые умеют колдовать .cpp2, а растовиков визуально много бродит.
Просто исторически есть Carbon от гугла, в котором рекомендация использовать раст, а карбон это для извращенцев особых случаев. А эта штука как карбон только ближе к плюсам.
Как всегда, найти пересечения растовиков/плюсистов сложно, а найти пересечения плюсовиков/плюсы2 еще еще сложней.
Попробовал пройти квест. Уже на одном из самых начальных уровней "Помочь владельцу стадиона" в качестве правильного указан неверный ответ. Правильный ответ, выбранный мной ─ "ошибка компиляции". Причина ошибки компиляции: использование cout без std::, при этом ни using namespace std, ни using std::cout в коде нет. А в квесте предполагается, что программа скомпилируется и что-то будет выведено.
Java относительно безопасна, но на каком языке написана её виртуальная машина ?
За всё надо платить. Хотите максимум гибкости - платите за это потенциально отстреленной ногой. Хотите максимум безопасности - платите за это ограничениями на каждом шагу. А вот рыбку съесть и на люстре покататься не получится.
Проблема не в C++. Проблема когда его суют туда где без него вполне можно обойтись.
Проблемы есть и в C/C++ -- эта сладкая парочка просто провоцирует возникновение ошибок на пустом месте.
Например, изначально, ещё в чистом C, регулярно возникали большие проблемы из-за отсутствия логического типа. Такие ошибки, как & вместо && или наоборот, в Паскале невозможны в принципе. (Замечу попутно, что введение bool в C++ ничем реально не помогло, поскольку типизация как была слабой, так и осталась -- сплошные автоматические преобразования без всякого реального контроля).
Ещё одна проблема -- присваивание рассматривается как операция, а не оператор, что приводит к if (a = b) вместо if (a == b).
Можно припомнить и отсутствие настоящего символьного типа, ведь char -- целое число, а не символ. Конечно, технически это одно и то же, но логически-то это разные вещи. Проблема усиливается тем, что char может быть как знаковым, так и беззнаковым, и это никак не регламентировано (например, какой-то древний код, успешно работавший раньше, вдруг может перестать работать, будучи скомпилирован новым компилятором).
А ещё приснопоминаемый break, который нужно явным образом указывать в case...
А ещё до самого 2011-го года не было стандартизации размеров целочисленных типов. Правда, в Паскале этого тоже нет -- но язык создавался как учебный. Вот в Аде есть, правда, оформлено по-другому.
Плюс, запутанный и неудобочитаемый синтаксис. Увидишь * и не можешь сразу, без анализа, понять, что это -- умножение или разыменование указателя? Или int *A[10] -- это массив указателей или указатель на массив? Понятно, что постоянное использование языка смягчает эти проблемы, но читабельность в любом случае хуже паскалеподобных языков, которые куда однозначнее, а заодно не допускают слишком уж извращённых синтаксических конструкций.
Да, сейчас большая часть потенциальных проблем в C/C++ более-менее решается включением всех предупреждений и превращением их в ошибки, но когда-то такой возможности не было; кроме того, подобные костыли нужны для обхода/смягчения изначальной кривизны самого языка. Так что реальная проблема изначально кроется всё ж и в языке тоже, а не только в его "гибкости" -- ту же самую гибкость и функциональность, что имеет C, имеет и классический Паскаль (и точно так же имеет проблемы с утечками памяти или использованием её после освобождения -- поскольку вот эту проблему без ущерба гибкости, функциональности и производительности в полном объёме решить как раз невозможно).
Мне нравился паскаль всегда. Я начал программировать на нем в начале 90х. Он тогда назывался ТурбоПаскаль. Я на нем писал программу для редактирования прошивки и прожига ПЗУ с ультафиолетовым стиранием. В соседнем отделе люди использовали ТурбоСи. Посмотрев на этот С код я понял что это использовать будет сложно, синтаксис непонятный и тратить время на его не хотелось. На паскале получилось не хуже по интерфейсу и скорости работы. И причём значительно меньше ушло времени для того чтобы его изучить. Потом, в конце 90х уже использовал delphi для клиент- северных приложений. Использую Delphi и сейчас. Система стала универсальной, можно писать под десктоп, андроид, линукс, мас, любые бд.
сплошные автоматические преобразования без всякого реального контроля
Статические анализаторы умеют предупреждать при подозрительных приведениях между bool и не bool. Мне так встроенный в MSVS2019 анализатор помог пару древних ошибок найти.
Я в последнем абзаце указал, что сейчас почти все проблемы решаются включением всех предупреждений и превращением их в ошибки -- но (1) эта возможность появилась не так уж давно (напомню, чистый С -- самое начало 1970-х, С++ -- 1980-е) и (2) это, по сути, костыль, смягчающий кривизну языка. Собственно, мой пост как раз про то, что С/С++ -- изначально кривые, откуда и возникает множество ошибок на пустом месте.
У всех этих Rust и Go, конечно же, такая же многолетняя история и необходимость сохранения обратной совместимости?
Было бы странно, если бы у языков, созданных 30+ лет назад, косяков не было бы. И их изначально создавали не с прицелом на безопасность.
Что касается предупреждений - не все предупреждения способен компилятор выдать. Я привёл пример как раз того, что компилятор не посчитает даже за предупреждение, т.к. такое приведение типов абсолютно допустимо по правилам языка. А вот статические анализаторы уже учитывают типичные ошибки программистов, возникающие из-за человеческого фактора.
Ну, я сравниваю, главным образом, чистый C и чистый Паскаль, причём Паскаль появился на пару лет раньше -- но не имеет основной массы проблем, которые имеются в C. Изрядная часть кривизны С++ -- это следствие попыток сохранить совместимость с чистым С вместо того, чтобы выкинуть её полностью и делать нормальный язык с читабельным синтаксисом и строгой типизацией.
Ещё одна проблема -- присваивание рассматривается как операция, а не оператор, что приводит к if (a = b) вместо if (a == b).
с таким же успехом можно жаловаться на то, что цифру 0 (ноль), можно перепутать с буквой 'о' , я еще застал времена когда эти жалобы звучали во весь голос,
или рускую 'с' с английской 'c' (letter)
Чем меньше возможностей для случайных ошибок, тем лучше. Тем более, что путаница между 0 и o, c и с, l и 1 нередко приводит-таки к возникновению ошибок при компиляции (скажем, неизвестный идентификатор). Паскаль препятствует возникновению подобных ошибок, C допускает массу случаев, где они возможны.
Это самое адекватное мнение о C++ которое я когда-либо видел на хабре.
AFL
Речь за AFLPlusPlus или вы прям тот самый старый AFL используете?
Мне интересно, а как вообще происходит прогон фаззинга. Ну, то есть написали тест, а дальше с ним что? Как вы его запускаете, когда останавливаете? По критериям ФСТЭК?
А есть что-нибудь про формальную верифицированные программы, которые были сформированы из пруфов на каком-нибудь Coq/Lean/Idris?
AFL++. Оригинальный уже не поддерживается.
Запускаем на ферме по необходимости. Критерии ФСТЭК используем, но они достаточно общие, например там не указывается целевое покрытие. Критерии останова фазинга это вообще сложный вопрос, одно время у нас был критерий по целевому покрытию, сейчас от этого уходим.
А есть что-нибудь про формальную верифицированные программы, которые были сформированы из пруфов на каком-нибудь Coq/Lean/Idris?
При это я немного знаю, слышал что у нас делалась формальная верификация на основе TLA+ модели.
одно время у нас был критерий по целевому покрытию
От нас аккредитованные лабы требовали 25-30% покрытия, но я не знаю откуда эту цифру брали. Ну и минимальные требования на количество исполнений/циклов. Но непонятно как вы замеряете покрытие пока фаззинг ещё в процессе.
А в общем как ваши тесты выглядят - просто набор мини тестов, которые нацеливаются на конкретные функции или вы целиком приложения скармиливаете? Сколько времени оно фаззит одну исполняемую единицу?
А в общем как ваши тесты выглядят - просто набор мини тестов, которые нацеливаются на конкретные функции или вы целиком приложения скармиливаете? Сколько времени оно фаззит одну исполняемую единицу?
Да, набор тестов для конкретных функций. Предварительно выбираем наиболее уязвимые места, там где внешний ввод, близость к сети, большой импакт и т.д. По времени от 2-х до 24 часов.
Простите, не удержался. Работал раньше плотно с их оборудованием.
есть ситуации где без плюсов никак. И я не могу сказать что плюсы или чистые Си это плохо.
Но в коммерческой разработке надо хорошо думать, нужны ли они. Из недавнего, достаточно большой серверный проект, не прямо гигантический, но не маленький, и начинаются спонтанные падения. Скилл требуемый для разбора проблемы требуется выше чем скилл просто для написания кода. Плюсы, с их переполнениями или use after free, позволяют приложению неизвестно долгий период времени существовать в сломанном состоянии, и потом крашиться так, что крайне сложно выловить причины возникновения такой ситуации в кода которая привела к падению.
Как задолбало уже это "язык ... чтобы выстрелить себе в ногу"! Языком нельзя выстрелить себе в ногу! Из языка вообще стрелять нельзя! Вот засунуть язык в степлер (например) вполне допустимое логически выражение, и еще :) очень не раскрытое в блогах, как мне кажется, только с ним проблема - читать нечего по теме :).
Сколько можно повторять одно и то же, это же так отдает примитивизмом. Что-то свое даже не пытаемся придумать!
Читаь статью с таким названием не хочется.
Из языка вообще стрелять нельзя
А дождь или фильм могут идти, если у них нет ног?
Специально для любителей иронии переходящей в сарказм:
Получается что не могут, судя по тому, что таких заголовков, в которых упоминается как дождь или фильм ходят не туда я не видел.
Если бы какая-то статья называлась как-то:
тра-та-та дождь или фильм пошли не туда. ...
По крайней мере это было бы что-то новенькое, сначала.
Но когда каждая пятая статья потом станет так называться, я думаю у многих бы это привело к несварению. Я только это имел в виду.
Извините если слишком эмоционально выразился, наболело.
А вот часы вообще могут стоять|висеть|лететь|падать и идти одновременно, и без ног!
Мне понравилось как в этой рекламной статье успешно обошли альтернативы как Android или ChromeOS.
Ужасная статья.
В заголовке - C++, по ходу текста в очередной раз появляется несуществующий язык С/C+. Нет такого языка. Зато есть сишники, не умеющие/не желающие писать на C++, но которых почему-то заставляют это делать. Вот таких действительно надо гнать на какой-нибудь Rust.
Первый же пример на C в его же парадигме, "extern C" долже был бы намекнуть автору, но он это игнорирует (это ж C/C++ видимо). Строка в C++ - это std::string, а вовсе не сишный массив байт.
В примере про состояние гонки вообще кажется Javascript. Так возможно C++ ни при чём?
Куча вброшенных тезисов с абсолютно "левыми" примерами, приправленных кучей рандомных отвлекающих картинок. Как говорится, КГ/АМ.
P.S.: Комитету C++ давно пора полностью сломать совместимость с C, чтобы не было таких вбросов.
Эта статья - близкий к тексту пересказ вот этого доклада: https://highload.ru/moscow/2023/abstracts/10669, но под другим названием. Ни в случае доклада, ни в случае статьи содержимое не соответствует названию.
Дело Страуструпа будет жить. Считаю, что перепись д***бов прошла успешно.
Давайте писать на том языке, который нужен для конкретной задачи, а не подбивать статистику, кто и где какую коленку прострелит.
NSA официально заявило, что программисты это обезьяны с гранатой и их стоит держать в надёжной клетке. А мы здесь обсуждаем, какая клетка будет для нас наиболее комфортной.
C++ предоставляет свободу в выборе стиля написания кода. На нём можно писать безопасно, можно писать красиво, а можно и наоборот :-) За это я его и люблю. И конечно получить на нём sigsegv очень несложно :-)
Мне понравилось описание уязвимости на JS (оно ещё работает?), но не понравилось, как всё это встроено в остальную статью.
По поводу безопасности Java, у меня, пока я понял как работает этот эксплоит для JS назрел вопрос - если кто-то сумел собрать такой лютый поэлоад, с учётом стольких нюансов работы внутреннего механизма... то откуда уверенность, что для той же JVM подобных "таблеток", позволяющих выполнить произвольный код нет?
Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.
Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.
Проблемы в коде - это недоработка разработчика. А попытка создать компилятор который будет генерировать типа безопасный код, попытка создать инструмент для разработчика, который не понимает например отличия указателя от указываемого значения.
Зачем сгенерированные картинки? Чтобы визуально объём статьи увеличить? Касперский, вы понимаете, что статья превращается в мусор с такими картинками? Они не отражают суть происходящего в тексте. Иллюстрация называется «Иллюстрацией», потому что иллюстрирует. В википедию хотя бы зайдите за описанием, что такое Иллюстрация. Нагородили херни в статью. Потому что модно-молодёжно? Такие картинки лишь показатель насколько автору плевать на текст в статье. Эти картинки, как ярлык бесполезности
Действительно ли C++ — лучший язык, чтобы выстрелить себе в ногу?