OberonCore

https://habrahabr.ru/post/126566/
Статья старая, может кто-то и читал. Но поскольку, строки в стиле Си ещё похоже долго будут использоваться -- статья не потеряет актуальности ещё долго))

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

http://russian.joelonsoftware.com/Artic ... asics.html
Ещё одна статья про сложности строк в Си.

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

Допустить, мы будем хранить рядом со строкой еще одно число, где хранится длина текущей строки чтобы в дальнейшем можно было быстрее конкатенировать строки и так далее.
В данном случае, со словом Hello, у нас длина будет 5 символов.
Но что если в дальнейшем будет обращение к элементу массива str[1] := 0X; ?
Получается, что каждое присваивание элементу массива должно проверяться на то, что нет ли там нулевой строки и не уменьшилась ли строка.

Вопрос решается легко.
1. Ноль -- обозначает конец строки (хотя сам массив может быть гораздо длиннее).
2. В строке (буквально) хранить её длину первым числом -- неразумно.
Сделать примерно так:

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

Во второй статье отличный анекдот про маляра Шлемиэля. Это про проблемы конкатенации в Си)) Не в бровь, а в глаз)) И инетерсные подробности работы malloc. Это практически недоделанный сборщик мусора!!!)))

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

Существует обширная практика хранения BLOB в строках. На самом деле удобно.

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

Это удобнее, чем обычный массив байт?

Зачастую да. Например, в Дельфе в TStringList укладывать.
Но, может, это только моя специфика, сейчас особо не с чем сравнивать...

У сишников в строках проблема не в завершающем нуле, а отсутствии контроля границ массива.

У сишников проблема в самом построении языка))
Статью вчера прочитал: "протечка абстракций".
Вот 146% про Си. И эти сквозные протечки -- неустранимы. С++ -- попытка устранить. Кривая))
Я не вижу протечку в Оберонах. Если, конечно, специально в потроха не лезть))

В 0 тоже есть проблема. Когда содержимое строки получают извне, многие забывают проверить, чтобы в содержимом не было 0, так как в этом случае длина строки окажется короче ожидаемой. Такие особенности остро встают при работе над безопасностью приложения. Неправильного поведения программы можно добиться и без порчи памяти.
К слову, если бы проблема была только в отсутствии контроля границ, то её бы и не было вовсе, потому что современные компиляторы Си умеют их контролировать. Для получения такого контроля нужно использовать ключ -fsanitize=address , поддерживаемый и gcc, и clang. По моим наблюдениям для gcc программа замедляется раза в 3, но при включённой оптимизации всё равно работает быстрей эквивалентной программы на Blackbox.

Это немножко из другой оперы.
Это про взаимодействие двух систем, поэтому здесь работает заповедь дедушки Вирта:"Вся программа должна строиться в оборонительном стиле". Поэтому при подобной ситуации программа на О может остановиться, но не упасть или улететь в космос. Это огромная разница.
Внутри правильных Оберонов подобная ситуация невозможна. Что касается быстродействия, тут опять же: я предпочту неубиваемый "Москвич" с предельной скоростью 120, чем смешной "Феррари", который развалится через 500 км на скорости 340 км в час. На практике проблема вычислительной мощности в 67% случаев перерастает в проблему ввода-вывода. Например, отрисовка на экране)))
Кроме того, включение такой опции безопасности в GCC говорит о том, что проблема не высосана из пальца. И эта опция неполноценна, так как это попытка заштукатурить кривой фундамент.

Я отвечал не вообще, а конкретно на утверждение. Никто не убеждает, что нужно использовать Си, но:
1. Контроль за памятью в Си есть.
2. Проблема с завершающим нулём есть и при наличи контроля за памятью.
Остальное - лирика.

В "оберонительном".

Тут нужно отметить, у ББ вообще старый компилятор, медленный код не из-за только лишь границ массива (ну, желающие могут выключить контроль границ и проверить).
Хотя, очевидно, что это зависит от алгоритма, который меряем.
Реально, думаю, замедление должно быть из-за контроля границ на 5-20% (от алгоритма, опять же).
Именно такая цифра, по-моему, будет при сравнении C# и C++ на массивовых алгоритмах.
В С же требуется контролировать не просто массивы, а адресную арифметику, поэтому, конечно, замедление колоссальное - и используют его только в отладочном режиме, по сути.

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

В release-сборках большинства приложений контроль за памятью деактивирован.
Если я не прав, просьба привести несколько противоположных примеров.
Таким образом.... хоть контроль за памятью в Си есть... контроля за памятью в Си-приложениях, как правило, нет...
Остальное - лирика

Примеры есть, "но мы вам о них не расскажем" (С). Это не прихоть.

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

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

Хм...
1. Проверки используются...
2. Сборщик мусора используется....
Мы всё ещё говорим о Си?))))

Консервативный сборщик там у них есть... Т.е. всякое значение, потенциально могущее указывать на объект кучи, трактуется как якорь (как в ББ для стека).