Может ли C++ быть таким же безопасным, как Rust?

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

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

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

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

Идея расширения C++ и последующего его ограничения не нова. Как отмечает Саттер:

По крайней мере с 2014 года Бьярне Струструп выступает за решение проблемы безопасности в C++ через "подмножество супермножества": То есть сначала "супермножество", чтобы добавить существенные элементы, отсутствующие в C++14, а затем "подмножество", чтобы исключить небезопасные конструкции, которым теперь есть замена.

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

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

"Применять профиль безопасности Pro.Type по умолчанию. Это включает либо запрет, либо проверку всех небезопасных приведений и преобразований (например, статических_кастов указателей, переинтерпретированных_кастов), включая неявное небезопасное приведение типов через C union и vararg".

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

Менее сложным является его второе предложение:

Применять профиль безопасности Pro.Bounds по умолчанию и гарантировать проверку границ.

Я не могу понять, почему этого еще нет. Возможно, это связано с неэффективностью таких проверок. Есть также дополнение к этой идее:

Арифметика указателей запрещена (вместо этого используйте std::span); это гарантирует, что указатель ссылается на один объект. Разложение массива на указатели, если оно разрешено, будет указывать только на первый объект в массиве.

С этим сложнее смириться, но его можно отключить.

Остальные предложения по большей части очевидны и заставляют задуматься, почему это еще не так. Мне очень приятно читать заявление о неопределенном поведении (Undefined Behavior, UB):

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

Думаю, я бы поспорил с тем, что ПБ необходимы. Хороший язык никогда не должен приводить к UB - только к поведению по умолчанию.

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

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

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

В качестве примера, с которым я столкнулся совсем недавно, а не в худшем случае, рассмотрим обращение с возвращаемыми значениями. В C вы всегда можете отбросить возвращаемое значение. В C++17 вы можете добавить [[nodiscard]], и компилятор заметит ошибку, если вы проигнорируете возвращаемое значение. Казалось бы, все просто, но есть std::ignore, который можно использовать для переопределения [[nodiscard]]. Это не стандарт, но он предложен в C++26 и является рекомендуемой практикой наряду с предложением атрибута [[discard]], чтобы формально отбрасывать возвращаемое значение, которое было явно помечено как [[nodiscard]]. Что можно сказать?

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

Прочитайте остальные предложения Саттера. Они дают представление о мышлении C++, если не больше.