Безопасность типов и ресурсов в современном C++

[x2v0]

Появление GSL - отлично!
Но, почему Бьерн Стрaуструп ничего не упоминает о другой работе/предложении своего коллеги, Херба Саттера, о передаче параметров https://github.com/hsutter/708/blob/main/708.pdf, которое подразумевает расширение синтаксиса C++, с включением в таких языковых элементов, как "in", "out", "inout" (a la C#), которое ещё более повысило бы "Безопасность типов и ресурсов в современном C++".

[domix32]

Главным образом из соображений совместимости я так понимаю. Плюс это ж надо будет ещё и всей комиссией потом обсуждать, подтверждать, доказывать, формализовать. Поэтому Cаттер и стал писать свой С++2

[x2v0]

Спасибо за ссылку! Посмотрел.

Хотелось бы, чтобы у них получилось.
Но, стоит заметить Carbon - детище google, а Саттер работает в Microsoft, в коммиттерах его нет.

[domix32]

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

[kovserg]

Безопасность типов и ресурсов в современном C++

Безопасность в C++ может быть достигнута, только жесткой дисциплиной и специализированными костылями.

Каждый указатель либо указывает на объект, либо является nullptr.

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

[kale]

Думаю, его не будет, потому как бред

[kovserg]

потому как бред

Этот бред называется pointer provenance. И очень активно используется компиляторами. Вы просто, видимо, слабо знакомы со стандартом, который позволяет делать очень чудные вещи компиляторам (которые человек в трезвом состоянии не оценил бы).

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm
https://youtu.be/ZgZ4_2YwtDQ?t=301

[kale]

Я очень поверхностно знаком с C++, но даже мне видно что основой для статьи (на которую вы ссылаетесь) является код, который любой зеленый джун определит как невалидный. Сдвигать указатель в неопределенную область памяти, получать UB и делать выводы вроде "Побайтно равные указатели в C++ могут одновременно указывать на совершенно разные объекты" выглядит все-таки бредово)

[kovserg]

Реальные кодовые базы огромны, а подобные грабли найти не всегда возможно. При смене компилятора на более новый могут всплывать очень забавные глюки. Поэтому используют несколько компиляторов и статических анализаторов и кучу автоматических тестов, но и это не спасает т.к. на разных платформах например на macos могут всплыть свои особенности, которых на других платформах даже с тем же компилятором не было. В общем C++ с его чудо стандартом, еще долго будут заставлять людей страдать.

[KanuTaH]

Конечно можно:

https://godbolt.org/z/o7zeY6MPe

Правда, это, скажем так, не валидный C код, потому что в нем эксплуатируются последствия undefined behavior, а в коде с undefined behavior, как известно, может происходить что угодно. Поэтому с формальной точки зрения нельзя заявлять, что этот код демонстрирует, что "побайтно равные указатели в C++ могут одновременно указывать на совершенно разные объекты" потому, что код с UB - это уже не код на C++ или на C :)

[kale]

Т.е. примеров с валидным кодом не будет?))

[KanuTaH]

В валидном коде такой ситуации быть не может. Более того - в этом коде ее тоже не будет, если выключить оптимизации (заменить -O2 на -O0), но, строго говоря, это просто "случайное совпадение", т.к. и в неоптимизированном невалидном коде она тоже могла бы быть.

[Explorus]

мне кажется, Страуструп юмор оценил бы

[Kelbon]

Не могут они указывать на "совершенно разные" объекты. Только
struct A {
B field;
};

Указатель на A и B могут побайтово совпадать, (standard layout), но это не является проблемой.
Указатель + тип указателя уже гарантирует, что указатель уникален(и даёт более широкие гарантии, если смотреть на алиасинг)

[kovserg]

Дело не в типе. Два указателя могут указывать на один и тот же тип данных и побитно полностью совпадать, но компилятору позволено считать что значения на которые указывают эти указатели совершенно разные. Т.к он с указателями таскает дополнительные данные — их происхождение (для блага оптимизаций) и на основании эти внутренних данных способен на очень креативные UB. И самое главное всё строго по стандарту.
Тоже самое со значениями: у вас 1 байт может принимать не 256 значений, а 257. Дополнительное значение poison (которое всё портит) не подчиняется правилам модульной арифметики для целых чисел, что очень способствует озорным UB (таким как выкидывание условий выхода из цикла например). Там сплошные минные поля если вы не в курсе. И главное постулируется что программист знает где все эти коровьи мины заложены, даже свежие, и никогда на них не наступает.

[Kelbon]

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

не может, для этого должно случиться UB

[rsashka]

Два указателя на один и тот-же объект (они равны побитно), но один указатель const, а другой обычный.