free pascal vs Delphi 10.3

[iskander]

На nil есть специальная заглушка

Желательно подробнее с этого места.

[Alex2013]

Ладно признаюсь снова копать лень, но весь этот спор напомнил одну старую "разборку" ...
В этой теме ...
viewtopic.php?f=5&t=11461&start=30
(Я честно говоря сам не ожидал, что использование динамического массива настолько проигрывает стандартному списку особенно в плане очистки )

Зы
Код с использованием динамического массива писал не я.

[iskander]

То ли этот форум модерируется, то ли нет, но в любом случае эта говёшка здесь точно лишняя.

[Alex2013]

То ли этот форум модерируется, то ли нет, но в любом случае эта говёшка здесь точно лишняя.

Ладно мир... Картинку убрал . Но суть в том что сколько я не пытался использовать динамический масив это всегда получалось медленнее чем при создании динамических структур доступа к данным в памяти любым другим способом .

Добавлено спустя 44 минуты 15 секунд:
Кстати LGenerics требует fpc 3.2 так что поверить более "продвинутый" пример со стандартным 3.0.4 не получилось .
Зы
Народ где бы готовые стабильные бинарники старших версий фпс взять ? (Собирал несколько раз с svn но все что-то глючное выходит )

[MylnikovDm]

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

Может быть тогда объяснишь, каким образом переменные внутри блока помогут избежать проблемы с исключением, которое ты сам же и добавил внутрь блока, где раньше был не нужен finally?

Приведённый тобой последний пример вообще никак не связан с изначально обсуждаемой темой. Он лишь должен убедить читающих эту ветку в том, что использование конструкции try...finally есть зло. Это и называется "передёргивание".

Кстати, что касается твоего примера с integer и double, то опять мимо кассы. Ситуация, которую ты описываешь, может возникнуть разве что при программировании на голом ассемблере. Во всех остальных случаях не будет выдаваться никакого мусора. Будет либо автоматическое приведение, либо ошибка приведения типа на этапе компиляции, если автоматический режим не предусмотрен. Если память мне не изменяет, автоматическое приведение integer к double появилось только в Turbo Pascal, а до этого в обе стороны преобразование выполнялось через соответствующие функции. Обратное приведение от double к integer до сих пор осталось через функции по той простой причине, что тут возможны разные варианты, а прямое приведение однозначно, поэтому его компилятор может подставлять автоматически. Вот он его и подставляет начиная с Turbo Pascal.

[runewalsh]

Подобно тому, как приведение целого числа к вещественному можно выполнять тихо благодаря его ～однозначности～, способ освобождения ресурса ～однозначно～ следует из того, как он захватывался (вспомни, когда ты последний раз видел у объекта больше одного деструктора). Поэтому заставлять пользователя дёргать его вручную излишне.

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

Таким, что (см. viewtopic.php?p=159377#p159377) с ними работу с критической секцией вместо

Код: Выделить всё

EnterCriticalSection(cs);
try
   // work
finally
   LeaveCriticalSection(cs);
end;

можно будет оформить так:

Код: Выделить всё

begin
   var guard := TScopedGuard.Create(cs);
   // work
end;

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

Ты не понял моих глубоких аллегоричных аналогий. «Мусор» с явным try-finally получить очень легко: вот создал ты объект, как его теперь освободить?
— Free? После Free у тебя буквально останется мусорный указатель.
— FreeAndNil? Если ты удерживал больше одного указателя на объект, остальные всё так же станут мусорными. Более того, по историческим причинам она сделана без проверки типов, поэтому ошибочно FreeAndNil'нуть можно что угодно.

С автоматическими переменными это не твоя проблема.

Вот я и сравнил твои высказывания против них с тем, как если бы ты получал мусор при не(правильно )прописанных приведениях типов и оправдывал это тем, что нужно ПРОСТО писать без ошибок, и вообще так даже лучше, ведь всё перед глазами.

Так вот, без inline-переменных тоже можно изредка получать «мусор» из-за недостаточной гранулярности, пример я уже приводил.

[Sharfik]

С автоматическими переменными это не твоя проблема.

Все читать не стал, прошелся глазами и зацепился.
У MS в последние годы появилось много новых и мало понятных сервисов. Чтобы в них разобраться месяц надо потратить. А практическую задачу по факту можно стабильно и аккуратно решить использовав старые сервисы, которые вчерашние студенты грязью поливают, как якобы плохие. Это аналогия.
Этот "автоматизированный" саботаж аукнется что FPC заглохнет в развитии на долгие годы, пока его авторы будут искать ошибки в очередной новой функции из-за использования "модных" приемов.

[Alex2013]

Этот "автоматизированный" саботаж аукнется что FPC заглохнет в развитии на долгие годы, пока его авторы будут искать ошибки в очередной новой функции из-за использования "модных" приемов.

В принципе с этим нельзя не согласиться . Но если это было бы "плевым делом" автоматизированная сборка мусора давно бы стала как миниму опционально включаемым режимом. (Кстати, а нет ли возможности, сделать это хотя-бы в танковых версиях FPC ? Ведь разработка на месте не стоит . )

[iskander]

Народ где бы готовые стабильные бинарники старших версий фпс взять ? (Собирал несколько раз с svn но все что-то глючное выходит )

На ftp-сервере ?

Sharfik писал(а):
Этот "автоматизированный" саботаж аукнется что FPC заглохнет в развитии на долгие годы, пока его авторы будут искать ошибки в очередной новой функции из-за использования "модных" приемов.

В принципе с этим нельзя не согласиться...

а мужики-то не знают...

[Alex2013]

На ftp-сервере ?

О спасибо!
(Есть несколько интересных проектов на "старших версиях ", до которых я никак не мог добраться )
Зы
Не пытайтесь читать тестовые ридими на том ftp-сервере (Это такой совет )