История изменений

Исправление byko3y, 30.07.20 07:41 (текущая версия) :

во время компиляции ты хочешь контролировать размер данных, которые выделяются в рантайме, динамически, размер которых заранее неизвестен ?

При чем тут конкретно размер? Я разве писал про размер? Я писал про то, чтобы корректно выделять и высвобождать память. Ты засунул строку в 10 символов в переменную, передал ее параметром в другую функцию, после выполнения этой функции строка стала 15 символов, мы прочитали ее значение и освободили память. Инструменты паскаля и C++ позволяют гарантировать безопасность этих операций вне зависимости от сложности производимого перевыделения памяти. То есть, это алгоритмы. которые были один раз написаны и повторно используются, экономя труд программиста. Си не позволяет делать этого и заставляет каждый раз выполнять проверки вручную, что, естественно, весьма трудоемко для сложных случаев, а для компилятора это миллисекунда работы.

procedure ReplaceSomething(var Somestr: String; Somearg: Integer);
var
  s: String;
begin
  s := 'a: ' + InToStr(Somearg) + ';';
  // или
  s := Format('a: %d;', [Somearg]);
  Somestr := StringReplace(Somestr, s, 'found it!',
                          [rfReplaceAll, rfIgnoreCase]);
end;

Как бы я не сочетал функции работы со строками — я не получу ошибок. В результате я могу заниматься построением логики работы приложения. В более поздних паскалях возникла конструкция «for C in AString do», которая позволяет еще и безопасно проходить по строке не парясь о том, что я прочитаю символ за пределами строки.

Это же относится к Variant, интерфейсам, динамическим массивам, и локальным переменным-структурам, содержащим эти структуры.

java memory leak example
ну и заодно можешь рассказать о том, как вся эта ботва легко и просто выявляется «на этапе компиляции»

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

Исходная версия byko3y, 30.07.20 07:38:

во время компиляции ты хочешь контролировать размер данных, которые выделяются в рантайме, динамически, размер которых заранее неизвестен ?

function ReplaceSomething(Somestr: String; Somearg: Integer): String;
var
  s: String;
begin
  s := 'a: ' + InToStr(Somearg) + ';';
  // или
  s := Format('a: %d;', [Somearg]);
  Result := StringReplace(Somestr, s, 'found it!',
                          [rfReplaceAll, rfIgnoreCase]);
end;

java memory leak example
ну и заодно можешь рассказать о том, как вся эта ботва легко и просто выявляется «на этапе компиляции»