Вопросы по Delphi (35 стр)

samrrr
> То-есть сделать нормальный массив в дельфи можно, но для этого прийдётся свой
> велосипед пилить?

В современном паскале дженерики есть. Включая наличие стандартных контейнеров в стандартных библиотеках (как в плюсах).
Проблема в тут в том, что по какой то причине во FreePascal стандартная библиотека контейнеров на дженериках называется по другому, включая названия классов.
Там у где у Delphi TList: https://docwiki.embarcadero.com/CodeExamples/Sydney/en/Generics_C… ctions_TList_(Delphi)
У FreePascal (и как следствие - Lazarus) - TFPGList https://www.freepascal.org/docs-html/rtl/fgl/tfpglist.html
Плюс вот эти мелкие отличия в синтаксисе с которыми надо осторожнее писать кроссплатформенный код.
Технически наверное проще съехать с платной Delphi совсем и пересесть на кроссплатформенный и бесплатный фрипаскаль.

=A=L=X=
> Там у где у Delphi TList:
> https://docwiki.embarcadero.com/CodeExamples/Sydney/en/Generics_C…
> ctions_TList_(Delphi)
>

List := TList<Integer>.Create;
List.Free;

Руками всё это прописывать надо. О чём я и говорю.

=A=L=X=
> кроссплатформенный и бесплатный фрипаскаль.
а чё с .dfm их фрипаскать съест?

samrrr
> а чё с .dfm их фрипаскать съест?

В Lazarus делаются файлы с расширением lfm и таким содержимым:

object Form1: TForm1
  Left = 256
  Height = 240
  Top = 127
  Width = 320
  Caption = 'Form1'
  ClientHeight = 240
  ClientWidth = 320
  LCLVersion = '2.2.2.0'
  object ToggleBox1: TToggleBox
    Left = 67
    Height = 25
    Top = 45
    Width = 75
    Caption = 'ToggleBox1'
    TabOrder = 0
  end
  object RadioButton1: TRadioButton
    Left = 141
    Height = 19
    Top = 110
    Width = 91
    Caption = 'RadioButton1'
    TabOrder = 1
  end
end

Вроде всё то же самое в рамках совместимости.
Она далеко не 100%-ая, но конвертеры базовых вещей есть.

> Руками всё это прописывать надо. О чём я и говорю.

Да, тут паскаль не исправить и я не думаю что и надо. Те же интерфейсы присобачили просто чтобы поддерживать COM в Windows и они выглядят как имхо не очень органично. То как COM работает зауживает правильные способы применения и может даже ставить палки в колёса, а не помогать.
А всё легаси на ручном .Free сделано и... работает. Прошлый век, но ужасность проблемы преувеличена. Если совсем неохота думать про аллокации и циркулярные ссылки, то надо сдриснуть тогда в ужасе и из плюсов в Сишарп.

=A=L=X=
> Если совсем неохота думать про аллокации и циркулярные ссылки,
Дело не в аллокациях, еслиб я писал код на дельфи, мне бы быстро надоело постоянно писать конструкторы деструкторы, когда компилятор мог бы и сам их добавить запросто.

samrrr
> Руками всё это прописывать надо.
не всё. А только то, чему ты выделяешь память. Да и то, может на автомате прописаться на уничтожение (по крайней мере в FPC).
Это правила хорошего тона, подчищать за собой. Как и везде.

Mirrel
> Это правила хорошего тона, подчищать за собой. Как и везде.
А почему этим должен заниматься я, а не компилятор например?

MrShoor
> А почему этим должен заниматься я, а не компилятор например?
может быть потому что ты лучше знаешь, чем компилятор когда нужно освободить память.

вот зачем в шарпе IDisposable? а память не является таким же ресурсом?

В шарповских программах бардак обычно понажористей, чем в дельфевых, хотя там вроде как автоматика за всем следит. "Раз тебе помогают, значит можно не думать" - видимо так считает большинство программистов и таки не думает, что дает вполне прогнозируемый результат.
В этом отношении С++ лучше тем, что там все взрывается сразу, если не подумаешь. Никакой надежды даже на иллюзию работоспособности.

skalogryz
> может быть потому что ты лучше знаешь, чем компилятор когда нужно освободить
> память.
Если ссылка теряется, то я уже даже если захочу - не смогу освободить память.

> вот зачем в шарпе IDisposable? а память не является таким же ресурсом?
В шарпе если по хорошему - тоже можно сказать ручной менеджмент памяти.
Вот есть у тебя объект текстура. Она хранит какой-то хендл на на неё. Это анменеджед данные. Значит что? Значит надо делать IDisposable:

class Texture : IDisposable {
  uint tex_handle;
//.....
}

Теперь у нас есть объект, которому назначена данная текстура:

class MyObject {
  public Texture texture { get; set; }
}

И это не правильно. По хорошему т.к. объекты, реализующие IDisposable - считаются анменеджед. Значит что? Значит MyObject тоже должен поддерживать IDisposable:

class MyObject : IDisposable {
  public Texture texture { get; set; }
}

Храним мы объекты в списке, он тоже должен быть IDisposable:

class MyWorld : IDisposable {
  List<MyObject> game_objects;
};

И внезапно язык из автоматического менеджмента памяти превращается в ручной. Конечно можно забить болт, и сделать только class Texture : IDisposable. И в большинстве случаев это сработает, ибо GC бегает по памяти очень часто. Но как бы сам факт. В тех же плюсах если следовать RAII такой проблемы нет. А Rust тебе еще и сам проверит, что ты следуешь RAII.

MrShoor
> Если ссылка теряется, то я уже даже если захочу - не смогу освободить память.
для этого и делают данные для её сохранения.
Если ты знаешь, что будешь создавать динамические данные, то как ты ими пользоваться собрался, если ты ссылку на них теряешь? )))

Mirrel
> Если ты знаешь, что будешь создавать динамические данные, то как ты ими
> пользоваться собрался, если ты ссылку на них теряешь? )))

begin
    obj := TSomeData.Create(input);
    obj.DoSomething();
    //всё, я поработал с данными, получил какой-то результат, obj мне больше не нужен
    //но не забудь удалить, ведь компилятор не в курсе, что ты потерял ссылку на данные
end;

MrShoor
obj - уже содержит указатель. От него и удаляем.

Но конечно проще, когда за нас это делает компилятор.

MrShoor
> Значит что? Значит MyObject тоже должен поддерживать IDisposable
Работать оно будет и без этого. Просто текстурка освободится не сразу, а позже.

MrShoor
> всё, я поработал с данными, получил какой-то результат, obj мне больше не нужен
а если ты obj тебе по завершению нужен, то сам собой напрашивается refcount.
ты же уже советовал интерфейсы выше по теме.

Может быть тебя заинтересует спец конструктор, которой инструктирует компилятор освободить объект по завершению процедуры (аки какой-нить управляемый тип - принудително в скрытой finally секции)? (а любой явный .Free или .Destroy ещё и зануляют ссылку)

var
  obj : TSomeData local; // всё! ты заявил что переменная используется только здесь
                         // и только здесь она должна быть освобждена
begin
  obj := TSomeData.Create(input);

samrrr
> Просто текстурка освободится не сразу, а позже.
при прибитии процесса? ну это как бы и есть классическая утечка ресурсов.