Smart pointers(деструкторы) в у Delphi - Delphi & Builder

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, Курилка, Вы писали:

К>>Так я не пойму — можно ли заставить дельфи деструкторы вызывать или нет? Или из твоего текста

ST>можно, но это будет криво выглядеть

Не так уж и криво.
Часто надо использовать локальные переменные — экземпляры классов, например, TStringList.
Тогда можно написать приметрно такой код:

interface 
...
  IObject = interface(IUnknown)
    function getObject: TObject;
    property AObject: TObject read getObject;
  end;

  TAutoPointer = class(TInterfacedObject, IObject)
  private
    FObj: TObject;
  public
    constructor Create(Obj: TObject);
    destructor Destroy; override;
    function getObject: TObject;
  end;

implementation

constructor TAutoPointer.Create(Obj: TObject);
begin
  FObj := Obj;
end;

destructor TAutoPointer.Destroy;
begin
  FreeAndNil(FObj);
  inherited;
end;

function TAutoPointer.getObject: TObject;
begin
  Result := FObj;
end;

и вот так использовать

procedure SomeProcedure;
var
  StringList: IObject;
begin
  StringList := TAutoPointer.Create(TStringListCreate);
  with StringList.AObject as TStringList do
  begin
    // что-то делаем, но StringList не уничтожаем
  end;
  // уничтожать StringList не надо
end;

Здравствуйте, Курилка, Вы писали:

S>> Зачем же создателям. Бери исходники в System и изучай. Все достаточно прозрачно.

К>А там есть исходники компилера? Что-то сомневаюсь...
К>А деструкторы там явно не написано как создаются и вызываются...

Зато все написано в хелпе. Если покопаться

В Delphi экземпляры классов хранятся только в куче, больше нигде. Переменная типа класса всего лишь указатель.
Деструктор вызывается автоматически только в одном случае, когда в конструкторе возникла исключительная ситуация.
Если объект создан — будь добр уничтожить его, когда он не нужен, вызовом деструктора.
После выполнения всего кода деструктор дополнительно вызывает FreeInstance, освобождая память.
Классы в Delphi создаются вызовом конструктора как метода класса, то есть MyObject := TMyObject.Create; например. В этом случае конструктор вызывает прежде всего NewInstance, которая выделяет память под экземпляр класса в куче и обнуляет все его поля. Замечу, что при вызове конструктора как простого метода, например, MyObject.Create, NewInstance не вызывается, а просто выполняется его код. Вот, собственно, и вся кухня.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Курилка, Вы писали:

S>>> Не представляет особого труда (хотя такая возможность явно не помешала), закинуть в некий список все создаваемые объекты и в Try Finally
S>>>их освобождать. Кстати полохо, что в Net нет такого для объектов с финализацией.
S>>> По поводу ООП и языков, то как можно говорить если в некоторых языках нет различия между структурами и объектами. А в Delphi как в Яве Net все объекты наследуются от базового (TObject,Object) класса.

К>>Ага и Integer и String тоже?
К>>Вот ненадо гнать пжлста...
S> Интежер это структура или примитивный тип (как больше нравится).Кстати в Яве (могу ошибаться) нет структур, а в Net это струтуры самостоятельны как Value тип (в Native Delphi есть структуры с методами но считаются (лись) устаревшими). По поводу String то это исключение, как и для динамических массивов как встроенных объектов и что в этом плохого ????.

А то, что язык получается ни чисто ОО, и чем обусловлено такое исключение не совсем понятно (вон в жабе замечательно строки как объекты существуют...)

S> Интефейсы же тоже поддерживаются компилятором и не надо как некоторым делать Addref или Realse хотя и это не проблема. Не говоря уже о позднем связывании.
S> Не надо хаять Язык.

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

> Да и смысл деструкторов в дельфах я теперь уже не понимаю тогда, в плюсах понятно — он вызывается когда уничтожается объект, а в дельфах получается наоборот что ли? — он используется для уничтожения объектов??

давай зрить в корень!

1. Делфи быстрый компилятор
2. Для этого он должен быть однопроходным
3. Для этого объявление должно быть до использования
4. Поэтому нет автоконструкторов
5. Что такое автодеструктор без автоконструктора!? Это бред!

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Курилка, Вы писали:

К>>Нифига, наоборот, что для того чтобы писать программы надо больше фигачить — допустим теже интерфейсы пихать для автоматических деструкторов, тогда как в плюсах это изначально так, другое дело, что в дельфе переменные есть по сути ссылки, из-за этого и грабли с деструкторами и пр.
S> Не совсем так есть packed object

Пиши со знаками припинания, плиз

А пакет он же для выравнивания используется только? И к деструкторам уж совсем не относится...

> OAB> невозможно в делфях создать класс не от TObject...
>
> Возможно.

Если можно — пример пожалуйста....

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Romkin, Вы писали:

R>А мне, например, нравится именно это. Терпеть не могу, когда система что-то делает, чем я не могу управлять.

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

R>И что, если есть GS — то это так круто, что остальное уже и не катит?

Так в том-то и дело, что альтернатив нет — только собственные ручки.

R>Безопасность, на мой взгляд, как раз в том,

В чем?

В>>P.S. Необходимость вызова деструктора предка ручками — это серьезно? Или я чего-то не так понял? Чего, и контсруктор предка тоже ручками всегда вызывать??? А чем это объясняется?
R>Синтаксисом языка.

Причем здесь синтаксис? Или если я не напишу вызов деструктора предка компилятор ругнется? Тогда претензий нет.

R>Видно, что делается и как делается, сразу. Delphi самодеятельностью не занимается. Что такого собственно? Это так ужасно?

А если компилятор не ругнется, то тогда еще раз: в чем глубокий смысл возможности не вызова конструктора/деструктора предка? Мне кажется это абсолютно бессмысленным и заведомо ошибочным.

Здравствуйте, Serginio1, Вы писали:

В>>Исключительно в угоду эффективности, а не из каких-то глубоких идеологических соображений, как я понимаю. В плюсах такое разделение не нужно — там классы сами по себе достаточно эффективны

S> Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу

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

S>а за счет гибкости

Какой такой гибкости?

S>и виртуальных конструкторов во много превышает возможности С++ классов. И

Аналоги виртуальных конструкторов в плюсах есть (уже многократно обсуждалось, на любой вкус). Причем намного более безопасные в использовании.

S>именно из- за своей структуры в Net С++ классы дают unsafe код.

Этого не понял.

S>>> Заметь и Борланд махнул рукой на Native. Зачем мыслить прошлым???
В>>Речь то шла не о .NET

У NET есть альтернатива (в какой-то степени) — GC. У дельфей альтернативы нет.
S> У нативной. В Delphi 8 есть.

Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название.

В>>P.S. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?
S> Можно. Но иногда вызывать нужно в определенной последовательности.

Зачем в определенной последовательности? Последовательность вполне логична и очевидна. Сначала конструируется базовый класс, потом наследник. Разрушается наследник, потом базовый класс. Любое отклонение от этой схемы ни к чему кроме глюков не ведет. Причем даже пресловутые виртуальные конструкторы не являются препятствием для реализации такой схемы. Так почему тогда все-таки допускается безобразие с невызовом конструктора/деструктора предка?

S>Вариантов много.
S>Особенно когда есть перекрестные ссылки.

Не понял? Примерчик?

S>Но с этим хорошо справляются интерфейсы. Итд итп
S> Гибкость.

Гибкость??? Где??? А вот глюков можно огрести — это вполне очевидно.

Здравствуйте, Serginio1, Вы писали:

S>>> Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу

S> А оно мне надо. В основном это долго играющие объекты.

В основном где? В дельфях?

Еще бы, там других не бывает (packed object на роль полноценных классов не годятся).

S> И выгоды от стека нет. Так как и в С++ в основном это ссылки.

Это тебе кто сказал?

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

[...]
S> Ну ну. Кстати в Net в Delphi виртуальные конструкторы и статические виртуальные методы сделаны в виде Метаклассов. Но старый механизм мне больше нравится.

А чем отличается?

S>>>именно из- за своей структуры в Net С++ классы дают unsafe код.
В>>Этого не понял.
S> Именно из- за того, что нет разницы между объектом и структурой.

ИМХО, ты чего-то не понимаешь. Ну да ладно.

[...]
В>>Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название.
S> Идеологически очень схож.

ИМХО, ты опять чего-то не понимаешь

Ну да ладно.

[...]
S> Не всегда так. У меня было много ситуаций когда разрушать нужно было сначала в базовом классе, а затем уже в потомках.

Не верю. Это говорит лишь о кривом дизайне. Хотя можешь попробовать привести конкретный пример.

[...]
S> Например Хип организуется наследником, а заполняется и удаляется в базовым классом но через наследника, то сначала должны вызвать деструктор базового класса, а затем уже свой итд.

Не понял. Чем в данном случае плох вызыв деструктора потомка до деструктора предка???

S> Есть объекты хэлперы которые наследуются от базовых классов но удалять внедренные объекты не нужно, так как эти объекты являются полями объекта для которого создается этот класс хэлпер, а только память под этот объект.

И чего? Не надо удалять — так не надо. Причем здесь "кривой" порядок вызова деструкторов?

S> Сейчас на вскидку тяжело вспомнить. Но поверь таких ситуаций предостаточно.

Не верю. Ни разу даже желания не возникало уничтожить предка до наследника или делать что-то в конструкторе наследника до конструирования предка. Извращение какое-то. Неужели сам не осознаешь, что это криво и противоестественно? Желание получить виртуальный вызов функции наследника из конструктора предка, каюсь, возникало — но это легко обходится.

[...]
S> Переходи на Net.

Как только будет поставлена соответсвующая задача — с удовольствием попробую, что это такое. Хотя не думаю, что открою для себя что-то принципиально новое — с джавой я успел поработать. И, надеюсь, к тому времени там появятся generics (а то точно буду плеваться

Просвятите чайника — никак не могу найти толкового описания времени жизни объектов в Delphi, есть такое ощущение, что для всех объектов нужно обязательно вызывать Free насильственно, что не очень-то помогает программисту на мой взгляд (для чего в C++ к примеру есть std:auto_ptr<>, но там для объекта в хипе деструктор вызывается автоматически). Допустим при возникновении исключений довольно криво будет всем объектам Free вызывать в случае чего...
Может есть всё-таки выход из ситуации?
(буду рад любым линкам по теме, сам что-то ничего пока не нашёл

)

Здравствуйте, Курилка, Вы писали:

К>Просвятите чайника — никак не могу найти толкового описания времени жизни объектов в Delphi, есть такое ощущение, что для всех объектов нужно обязательно вызывать Free насильственно, что не очень-то помогает программисту на мой взгляд (для чего в C++ к примеру есть std:auto_ptr<>, но там для объекта в хипе деструктор вызывается автоматически). Допустим при возникновении исключений довольно криво будет всем объектам Free вызывать в случае чего...
К>Может есть всё-таки выход из ситуации?
К>(буду рад любым линкам по теме, сам что-то ничего пока не нашёл

)

в C++ все классы — суть object в Delphi, плюс автоматические деструкторы(с конструкторами хуже — в Delphi их можно заменить простые Init процедуры, "конструктор по умолчанию" обнуляет все поля). Так что class в Delphi совсем не то, что в C++. И принципы работы другие — выделяется только в куче, позволяет быть представителем интерфейса, COM-объектом напрямую, а не через страшные шаблоны как в C++ и пр. и пр. А вообще стоит посмотреть в исхдники VCL — там все такие кинструкции заключениы в try..finally..end, это такое правило

. Хотя я для свох нужд сделал обвязку типа smart pointer для Delphi на интерфейсе — все стало проще

правда для использования smart pointer существует жуткое количество ограничений, например нельзя использовать const& для содержимого

но только это проблемы самой идеи, а не реализации.

Здравствуйте, Аноним, Вы писали:

А>в C++ все классы — суть object в Delphi, плюс автоматические деструкторы(с конструкторами хуже — в Delphi их можно заменить простые Init процедуры, "конструктор по умолчанию" обнуляет все поля). Так что class в Delphi совсем не то, что в C++. И принципы работы другие — выделяется только в куче, позволяет быть представителем интерфейса, COM-объектом напрямую, а не через страшные шаблоны как в C++ и пр. и пр. А вообще стоит посмотреть в исхдники VCL — там все такие кинструкции заключениы в try..finally..end, это такое правило

. Хотя я для свох нужд сделал обвязку типа smart pointer для Delphi на интерфейсе — все стало проще

но только это проблемы самой идеи, а не реализации.

Так я не пойму — можно ли заставить дельфи деструкторы вызывать или нет? Или из твоего текста

C++ все классы — суть object в Delphi, плюс автоматические деструкторы

т.е. объект дельфи — класс C++ минус автоматические деструкторы, так чтоли?

Здравствуйте, Курилка, Вы писали:

К>Так я не пойму — можно ли заставить дельфи деструкторы вызывать или нет? Или из твоего текста

можно, но это будет криво выглядеть
поэтому общей практикой является использование блоков try-finally

К>C++ все классы — суть object в Delphi, плюс автоматические деструкторы

К>т.е. объект дельфи — класс C++ минус автоматические деструкторы, так чтоли?

это какие-то запутки, не стоит вникать

Здравствуйте, Курилка, Вы писали:

К>Может есть всё-таки выход из ситуации?

Вообще-то можно использовать интерфейсы (в них реализован подсчет ссылок), но ИМХО это полумера. Можно еще использовать garbage collector — несколько реализацией есть в интернете, ноя лично не пробывал.

Читаем Garbage Collector For Delphi Objects and Components, и здесь
Качаем Garbage Collector for Delphi и здесь

> Просвятите чайника — никак не могу найти толкового описания времени жизни объектов в Delphi, есть такое ощущение, что для всех объектов нужно обязательно вызывать Free насильственно, что не очень-то помогает программисту на мой взгляд (для чего в C++ к примеру есть std:auto_ptr<>, но там для объекта в хипе деструктор вызывается автоматически). Допустим при возникновении исключений довольно криво будет всем объектам Free вызывать в случае чего...
> Может есть всё-таки выход из ситуации?
> (буду рад любым линкам по теме, сам что-то ничего пока не нашёл

)

именно поэтому и смотрю последнее время в сторону C++.
либо смотри в сторону интерфейсов:
http://rsdn.ru/forum/Message.aspx?mid=544019

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

>> Просвятите чайника — никак не могу найти толкового описания времени жизни объектов в Delphi, есть такое ощущение, что для всех объектов нужно обязательно вызывать Free насильственно, что не очень-то помогает программисту на мой взгляд (для чего в C++ к примеру есть std:auto_ptr<>, но там для объекта в хипе деструктор вызывается автоматически). Допустим при возникновении исключений довольно криво будет всем объектам Free вызывать в случае чего...
>> Может есть всё-таки выход из ситуации?
>> (буду рад любым линкам по теме, сам что-то ничего пока не нашёл

)

OAB>именно поэтому и смотрю последнее время в сторону C++.
OAB>либо смотри в сторону интерфейсов:
OAB>http://rsdn.ru/forum/Message.aspx?mid=544019

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

Здравствуйте, Курилка, Вы писали:

К>Что-то как-то я тоже гораздо больше смотрю в сторону плюсов, т.к. в дельфах гораздо меньше документированы вот такие подробности, т.е. или хрен знает как сделать или извращаться, тогда как плюсы дают практически возможность переделать чуть ли не любую логику...
Тогда уж смотри в сторону Net.

> OAB>именно поэтому и смотрю последнее время в сторону C++.
> OAB>либо смотри в сторону интерфейсов:
> OAB>http://rsdn.ru/forum/Message.aspx?mid=544019
>
> Что-то как-то я тоже гораздо больше смотрю в сторону плюсов, т.к. в дельфах гораздо меньше документированы вот такие подробности, т.е. или хрен знает как сделать или извращаться, тогда как плюсы дают практически возможность переделать чуть ли не любую логику...

да, он бывают такие вещи как "корпаративный стандарт" и "куча наваяного кода"...
вот тогда, привыкнув к С++ (очень быстро кстати) и смотришь в сторону таких либ...

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

так что либо интерфейсы либо try try try по типу:

var
  HStmt : THStmt;
  V : array [0..1] of Variant;
begin
  Result := '';
  HStmt := PrepareHStmt( Database, sql_GetPackageBody );
  try
    BindParamArray( HStmt, [PackageId, PackageType]);
    HStmt.Execute;
    try
      while FetchNextRow( HStmt, V ) do
        Result := Result + Var2Str(V[0]);
    finally
        CloseHStmt(HStmt);
    end;
  finally

    FreeHStmt(HStmt);
  end;
end;

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>так что либо интерфейсы либо try try try по типу:

OAB>

...
OAB>

Но ведь убого и неслабо чревато ошибками (т.е. можно забыть освободить ресурс, если он 1 то это элементарно, а если их до хохота разных?), неужто Delphi как инструмент появившийся попозже C++ не включает таких вещей? (причём не очень уж и сложных)

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Курилка, Вы писали:
К>>Что-то как-то я тоже гораздо больше смотрю в сторону плюсов, т.к. в дельфах гораздо меньше документированы вот такие подробности, т.е. или хрен знает как сделать или извращаться, тогда как плюсы дают практически возможность переделать чуть ли не любую логику...
S> Тогда уж смотри в сторону Net.

Смотрю, смотрю, но всё-таки это гораздо более высокая абстракция и плюсы позволяют управлять "более глубокими" механизмами. К примеру — как вы на .нете поменяете GC?

> OAB>так что либо интерфейсы либо try try try по типу:
>
> OAB>

> ...
> OAB>

>
> Но ведь убого и неслабо чревато ошибками (т.е. можно забыть освободить ресурс, если он 1 то это элементарно, а если их до хохота разных?), неужто Delphi как инструмент появившийся попозже C++ не включает таких вещей? (причём не очень уж и сложных)

хм... говоришь "появившийся попозже C++" ?

... а по-моему последний стандарт С++ был позже...
Делфи — это в первую очередь RAD и уже потом ООП. к сожалению

вот сейчас пишу и плачу — нужно дописаль один кусок не в моем коде, вроде ООП, а в итоге — процедурное програмирование:
прямое обращение к глобальным переменным и десятки процедур одного класса — это форма! итого если убрать везде объявление формы получим что? правильно! обычное процедурное программирование

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

>> OAB>так что либо интерфейсы либо try try try по типу:
>>
>> OAB>

>> ...
>> OAB>

>>
>> Но ведь убого и неслабо чревато ошибками (т.е. можно забыть освободить ресурс, если он 1 то это элементарно, а если их до хохота разных?), неужто Delphi как инструмент появившийся попозже C++ не включает таких вещей? (причём не очень уж и сложных)

OAB>хм... говоришь "появившийся попозже C++" ?

... а по-моему последний стандарт С++ был позже...
OAB>Делфи — это в первую очередь RAD и уже потом ООП. к сожалению

Ну для дельфей стандартов нет вообще!
А плюсы ещё в 80-х появились (дату не скажу, но где-то там)
И отстутствие этих самых стандартов есть тоже неслабый минус, хотя реализация только одна, но вот как работает та или иная конструкция бывает просто хз где откопать (правда и в плюсах есть немало подковырок, но основные Мейерсы всякие описывают).
А стандарт не очень сильно сам язык переработал (правда шаблоны там появились, но их в шарп уже почти запихали, так что дельфи уж за 10 лет своей истории могли сподобиться и попробовать реализовать хоть что-то подобное) и те же деструкторы были там изначально.
Но что-то уже это всё превращается в флейм постепенно

OAB>вот сейчас пишу и плачу — нужно дописаль один кусок не в моем коде, вроде ООП, а в итоге — процедурное програмирование:
OAB>прямое обращение к глобальным переменным и десятки процедур одного класса — это форма! итого если убрать везде объявление формы получим что? правильно! обычное процедурное программирование

Так вот дельфа и не приводит к ООП, хоть он в ней и есть, а в основном используется как скриптовые языки (VBS, Javascript) object-based, т.е. обычное процедурное, но с использованием объектов. И это немного (хоть и очень немного) напоминает забивание гвоздей видеомагнитофоном. Да ещё есть такое ощущение что даже сама борланд не очень ратует за ООП и проч. применительно к Дельфи, а картина рисуется: набросаешь компонентов, свойства выставишь, пару OnClick напишешь и вуаля — мегапрограмма готова...

ээээххх... к сожалению согласен...
хотя можно и на делфях писать прилично....
ладно, завязали, а то действительно в флейм перейдет, хотя...
где еще на делфю пожаловаться можно, чтобы не начали кричать: "Эй! С++ рулит!"

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>хм... говоришь "появившийся попозже C++" ?

... а по-моему последний стандарт С++ был позже...
OAB>Делфи — это в первую очередь RAD и уже потом ООП. к сожалению

Вступлюсь я За свой любимый язык.
Delphi позволяет писать как процедурно так и ООП.
Правда в Native Delphi нет статических переменных, но если есть желание полностью соответствовать ООП пиши синглтоны. Статические методы в том числе и виртуальные присутствуют как в Native так и Net.
Кстати в Net все процедуры и переменные трансформируются во внутреннем классе Unit, как статические переменные и методы.
По поводу Smart pointers, то существуют интерфейсы и safeCall.
Не представляет особого труда (хотя такая возможность явно не помешала), закинуть в некий список все создаваемые объекты и в Try Finally
их освобождать. Кстати полохо, что в Net нет такого для объектов с финализацией.
По поводу ООП и языков, то как можно говорить если в некоторых языках нет различия между структурами и объектами. А в Delphi как в Яве Net все объекты наследуются от базового (TObject,Object) класса.

Здравствуйте, Serginio1, Вы писали:

S> Вступлюсь я За свой любимый язык.
S> Delphi позволяет писать как процедурно так и ООП.
S>Правда в Native Delphi нет статических переменных, но если есть желание полностью соответствовать ООП пиши синглтоны. Статические методы в том числе и виртуальные присутствуют как в Native так и Net.
S> Кстати в Net все процедуры и переменные трансформируются во внутреннем классе Unit, как статические переменные и методы.
S> По поводу Smart pointers, то существуют интерфейсы и safeCall.
Т.е. для кажного случая мне эти интерфейсы прикручивать?

S> Не представляет особого труда (хотя такая возможность явно не помешала), закинуть в некий список все создаваемые объекты и в Try Finally
S>их освобождать. Кстати полохо, что в Net нет такого для объектов с финализацией.
S> По поводу ООП и языков, то как можно говорить если в некоторых языках нет различия между структурами и объектами. А в Delphi как в Яве Net все объекты наследуются от базового (TObject,Object) класса.

Ага и Integer и String тоже?
Вот ненадо гнать пжлста...

Здравствуйте, Курилка, Вы писали:

S>> Не представляет особого труда (хотя такая возможность явно не помешала), закинуть в некий список все создаваемые объекты и в Try Finally
S>>их освобождать. Кстати полохо, что в Net нет такого для объектов с финализацией.
S>> По поводу ООП и языков, то как можно говорить если в некоторых языках нет различия между структурами и объектами. А в Delphi как в Яве Net все объекты наследуются от базового (TObject,Object) класса.

К>Ага и Integer и String тоже?
К>Вот ненадо гнать пжлста...
Интежер это структура или примитивный тип (как больше нравится).Кстати в Яве (могу ошибаться) нет структур, а в Net это струтуры самостоятельны как Value тип (в Native Delphi есть структуры с методами но считаются (лись) устаревшими). По поводу String то это исключение, как и для динамических массивов как встроенных объектов и что в этом плохого ????. Интефейсы же тоже поддерживаются компилятором и не надо как некоторым делать Addref или Realse хотя и это не проблема. Не говоря уже о позднем связывании.
Не надо хаять Язык.

Здравствуйте, Курилка, Вы писали:

К>Так вот дельфа и не приводит к ООП, хоть он в ней и есть, а в основном используется как скриптовые языки (VBS, Javascript) object-based, т.е. обычное процедурное, но с использованием объектов. И это немного (хоть и очень немного) напоминает забивание гвоздей видеомагнитофоном. Да ещё есть такое ощущение что даже сама борланд не очень ратует за ООП и проч. применительно к Дельфи, а картина рисуется: набросаешь компонентов, свойства выставишь, пару OnClick напишешь и вуаля — мегапрограмма готова...

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

если проекты просты, то 1-й этап (написания спец. библиотек классов) сожно опустить

кстати, такое впечатление, ты расстроен тем, что программы писать становится все проще и проще ?

Здравствуйте, Курилка, Вы писали:

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

вот это точно. полностью согласен
я когда на дельфе начал писать сразу поселился в окне CPU

мрак.
понимать там нечего — это нужно просто знать, а узнать проще всего из CPU window

Здравствуйте, Курилка, Вы писали:

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

Вот уж ЭТО зависит полностью от этого самого программиста.

Здравствуйте, s.ts, Вы писали:

ST>если проекты просты, то 1-й этап (написания спец. библиотек классов) сожно опустить

Но вопрос в том, что эти библиотеки в дельфах ну не всегда подходят...

ST>кстати, такое впечатление, ты расстроен тем, что программы писать становится все проще и проще ?

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

Здравствуйте, kavlad, Вы писали:

K>Здравствуйте, s.ts, Вы писали:

ST>>Здравствуйте, Курилка, Вы писали:

К>>>Так я не пойму — можно ли заставить дельфи деструкторы вызывать или нет? Или из твоего текста

ST>>можно, но это будет криво выглядеть

K>Не так уж и криво.
K>Часто надо использовать локальные переменные — экземпляры классов, например, TStringList.
K>Тогда можно написать приметрно такой код:

это понятно, можно было код не рисовать.
и так ясно, что он кривой:
1. создание доп. наследников от существующих классов для реализации подсчета ссылок
2. постоянное явное приведение типов

Здравствуйте, kavlad, Вы писали:

K>Здравствуйте, Курилка, Вы писали:

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

K>Вот уж ЭТО зависит полностью от этого самого программиста.

Ты уверен???
Глянь вон на соседний пост

Да и смысл деструкторов в дельфах я теперь уже не понимаю тогда, в плюсах понятно — он вызывается когда уничтожается объект, а в дельфах получается наоборот что ли? — он используется для уничтожения объектов??

> это понятно, можно было код не рисовать.
> и так ясно, что он кривой:
> 1. создание доп. наследников от существующих классов для реализации подсчета ссылок

ну да! а auto_ptr не создает временный объект

> 2. постоянное явное приведение типов
согласен что шаблоны это хорошо, но можно опять же глянуть библиотеку SIL
так многое уже сделано!

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Курилка, Вы писали:

S>> Не надо хаять Язык.

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

Зачем же создателям. Бери исходники в System и изучай. Все достаточно прозрачно.
А ели есть проблемы то поможем.
К>Конечно в васике это почище ещё гораздо, но в васике этого не скрывают, да и сравнение-то велось не с ним, а с плюсами...
А вот с Васиком как раз другая картина.

Здравствуйте, Курилка, Вы писали:

К>Да и смысл деструкторов в дельфах я теперь уже не понимаю тогда, в плюсах понятно — он вызывается когда уничтожается объект, а в дельфах получается наоборот что ли? — он используется для уничтожения объектов??

Точно-точно. А конструктор — для их создания

В нем идет вызов NewInstance, которая выделяет память для экземпляра.
Вообще-то, это дело привычки. Delphi lang — очень простой язык, скажу больше, автоматическое уничтожение иногда очень путает новичков, например, здесь:

function smth: PChar;
var
  S: string;
begin
  S := ...;
  Result := PChar(S);
end;

Кстати, AV может и не дать при использовании

Здравствуйте, Курилка, Вы писали:

К>Ты уверен???
К>Глянь вон на соседний пост

К>Да и смысл деструкторов в дельфах я теперь уже не понимаю тогда, в плюсах понятно — он вызывается когда уничтожается объект, а в дельфах получается наоборот что ли? — он используется для уничтожения объектов??
В Delphi все объекты располагаются в куче. Структуры — packed object в стеке.
Поэтому Destroy освобождает память (не совсем освобождает так как использутся менеджер памяти о помечает как не используемую или при превышении неиспользованного блока более помоему 64кб (или 16) возвращает ее системе) и вызывает деструкторы всех внедренных объектов.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Курилка, Вы писали:

S>>> Не надо хаять Язык.

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

S> Зачем же создателям. Бери исходники в System и изучай. Все достаточно прозрачно.

А там есть исходники компилера? Что-то сомневаюсь...
А деструкторы там явно не написано как создаются и вызываются...

S> А ели есть проблемы то поможем.
К>>Конечно в васике это почище ещё гораздо, но в васике этого не скрывают, да и сравнение-то велось не с ним, а с плюсами...
S> А вот с Васиком как раз другая картина.

Не будем отвлекаться

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Курилка, Вы писали:

К>>Ты уверен???
К>>Глянь вон на соседний пост

К>>Да и смысл деструкторов в дельфах я теперь уже не понимаю тогда, в плюсах понятно — он вызывается когда уничтожается объект, а в дельфах получается наоборот что ли? — он используется для уничтожения объектов??
S> В Delphi все объекты располагаются в куче. Структуры — packed object в стеке.
S>Поэтому Destroy освобождает память (не совсем освобождает так как использутся менеджер памяти о помечает как не используемую или при превышении неиспользованного блока более помоему 64кб (или 16) возвращает ее системе) и вызывает деструкторы всех внедренных объектов.

Т.е. с ног на голову всё?
Получаем картинку, которую Oleg рядом нарисовал, ясно всё...

Здравствуйте, Курилка, Вы писали:

К>А там есть исходники компилера? Что-то сомневаюсь...
К>А деструкторы там явно не написано как создаются и вызываются...

Бери и иследуй класс TObject. Там все расписано.
И все действия со строками и динамическими массивами. Ну а исходники компилятора ....

class function TObject.NewInstance: TObject;
begin
  Result := InitInstance(_GetMem(InstanceSize));
end;


class function TObject.InitInstance(Instance: Pointer): TObject;
{$IFDEF PUREPASCAL}
var
  IntfTable: PInterfaceTable;
  ClassPtr: TClass;
  I: Integer;
begin
  FillChar(Instance^, InstanceSize, 0);
  PInteger(Instance)^ := Integer(Self);
  ClassPtr := Self;
  while ClassPtr <> nil do
  begin
    IntfTable := ClassPtr.GetInterfaceTable;
    if IntfTable <> nil then
      for I := 0 to IntfTable.EntryCount-1 do
  with IntfTable.Entries[I] do
  begin
    if VTable <> nil then
      PInteger(@PChar(Instance)[IOffset])^ := Integer(VTable);
  end;
    ClassPtr := ClassPtr.ClassParent;
  end;
  Result := Instance;
end;

procedure TObject.CleanupInstance;
{$IFDEF PUREPASCAL}
var
  ClassPtr: TClass;
  InitTable: Pointer;
begin
  ClassPtr := ClassType;
  InitTable := PPointer(Integer(ClassPtr) + vmtInitTable)^;
  while (ClassPtr <> nil) and (InitTable <> nil) do
  begin
    _FinalizeRecord(Self, InitTable);
    ClassPtr := ClassPtr.ClassParent;
    if ClassPtr <> nil then
      InitTable := PPointer(Integer(ClassPtr) + vmtInitTable)^;
  end;
end;


procedure TObject.FreeInstance;
begin
  CleanupInstance;
  _FreeMem(Self);
end;

> Зато все написано в хелпе. Если покопаться

> В Delphi экземпляры классов хранятся только в куче, больше нигде. Переменная типа класса всего лишь указатель.
> Деструктор вызывается автоматически только в одном случае, когда в конструкторе возникла исключительная ситуация.
Тааакккк... это где такое!?
IMHO бред!

Проверяемс

program test;

{$APPTYPE CONSOLE}

uses
  SysUtils;

type
  TDestroyOnException = class
  public
    constructor Create();
    destructor Destroy(); override;
  end;

constructor TDestroyOnException.Create();
begin
  raise Exception.Create('exception :TDestroyOnException.Create()');
end;

destructor TDestroyOnException.Destroy(); 
begin
  WriteLn('Destroy');
end;

var
  D: TDestroyOnException;
begin
  try
    D := TDestroyOnException.Create();
    WriteLn('D is Created'); 
    try
    finally
      WriteLn('Destroy D');
      D.Free;
      WriteLn('D is Destroyed');
    end;
  except
    on E: Exception do
      WriteLn(E.Message);
  end;
end.

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

>> Зато все написано в хелпе. Если покопаться

>> В Delphi экземпляры классов хранятся только в куче, больше нигде. Переменная типа класса всего лишь указатель.
>> Деструктор вызывается автоматически только в одном случае, когда в конструкторе возникла исключительная ситуация.
OAB>Тааакккк... это где такое!?
OAB>IMHO бред!

OAB>Проверяемс

OAB>

OAB>program test;

OAB>{$APPTYPE CONSOLE}

Ж)) Гыыы. Проверил? 

Не могу больше.  :))) Проверь 
[pascal]
destructor TDestroyOnException.Destroy();
begin
  ShowMessage('Destroy');
end;

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

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

внатуре стормозил....
с примером в смысле

деструктор объявлен как override!
класс TObject к этому моменту был создан и его деструктор был вызван...
по vmt попали и к нам....

если сделать reintroduce? то деструктор не будет вызван! и это правильно!!!
преставь тогда такой код:

type
  TDestroyOnException = class
  private
    L: TStringList;
  public
    constructor Create();
    destructor Destroy(); override;
  end;

constructor TDestroyOnException.Create();
begin
  raise Exception.Create('exception :TDestroyOnException.Create()');
  L := TStringList.Create;
end;

destructor TDestroyOnException.Destroy(); 
begin
  L.Free;
  WriteLn('Destroy');
end;

Posted via RSDN NNTP Server 1.7 "Bedlam"

скажу честно, я слегка озадачен...
хотя, это ведь TObject! его деструктор должен быть вызван, т.к. он был создан!

да...
вот здесь и кроется весь гемор того, что невозможно в делфях создать класс не от TObject...

хм... надо будет внимательно взглянуть в сторону VirtualPascal или чего-то подобного...

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, Oleg A. Bachin, Вы писали:

>> это понятно, можно было код не рисовать.
>> и так ясно, что он кривой:
>> 1. создание доп. наследников от существующих классов для реализации подсчета ссылок
OAB>) ну да! а auto_ptr не создает временный объект

>> 2. постоянное явное приведение типов
OAB>согласен что шаблоны это хорошо, но можно опять же глянуть библиотеку SIL
OAB>так многое уже сделано!

у меня вопрос :

кто-нибудь реально использовал этот гемор в достаточно больших коммерческих проектах (от 5-10 человеко-лет) ?
и каков результат ?

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, s.ts, Вы писали:

ST>>если проекты просты, то 1-й этап (написания спец. библиотек классов) сожно опустить

К>Но вопрос в том, что эти библиотеки в дельфах ну не всегда подходят...

дык я и говорю, что под проект пишутся доп. библиотеки

в приложении — толко бизнес-логика
все системные вещи — в библиотеках и компонентах

ST>>кстати, такое впечатление, ты расстроен тем, что программы писать становится все проще и проще ?

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

отсутствие шаблонов компенсируется простотой и прозрачностью кода

в общем, то, что применимо в C++ vs C#|Java применимо и в C++ vs Delphi

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>если сделать reintroduce? то деструктор не будет вызван! и это правильно!!!
OAB>преставь тогда такой код:

OAB>

OAB>type
OAB>  TDestroyOnException = class
OAB>  private
OAB>    L: TStringList;
OAB>  public
OAB>    constructor Create();
OAB>    destructor Destroy(); override;
OAB>  end;

OAB>constructor TDestroyOnException.Create();
OAB>begin
OAB>  raise Exception.Create('exception :TDestroyOnException.Create()');
OAB>  L := TStringList.Create;
OAB>end;

OAB>destructor TDestroyOnException.Destroy(); 
OAB>begin
OAB>  L.Free;
OAB>  WriteLn('Destroy'); 
OAB>end;

OAB>

Чем не прикалывает? ТЕм, что вывод на консоль подавляется до обработки исключения? Free проверяет указатель на nil, а в остальных случаях ты сам должен сделать эту проверку в деструкторе. Это азы. И inherited я бы советовал вызывать. Здесь-то не нать, а вот если потомок не TObject ...

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>скажу честно, я слегка озадачен...
OAB>хотя, это ведь TObject! его деструктор должен быть вызван, т.к. он был создан!

Ничего не понимаю... Деструктор предка ты сам должен вызвать из своего, через inherited. Правда, у TObject он пустой, так что можно обойтись

OAB>да...
OAB>вот здесь и кроется весь гемор того, что невозможно в делфях создать класс не от TObject...

В чем гимор?

OAB>хм... надо будет внимательно взглянуть в сторону VirtualPascal или чего-то подобного...

А, собственно, говоря, зачем? Чем не устраивает то, что есть?

Здравствуйте, s.ts, Вы писали:

ST>>>кстати, такое впечатление, ты расстроен тем, что программы писать становится все проще и проще ?

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

ST>отсутствие шаблонов компенсируется простотой и прозрачностью кода

Ну про шаблоны я тут вообще-то не писал...
А фигня в том, что дельфа не предусматривает авт. переменных (тут Oleg точные выводы написал рядом...)

ST>в общем, то, что применимо в C++ vs C#|Java применимо и в C++ vs Delphi

А вот нихрена!
В шарпе и жабе есть GC, а в дельфах не было и не подразумевается, так что уж не сходится...
Да и вон в шарп генериксы собираются всё добавить, а в дельфу как более старый язык всё никак даже не задумываются, что надо было бы...
Но это всё ИМХО, конечно (но "надо бы")

> Чем не прикалывает? ТЕм, что вывод на консоль подавляется до обработки исключения? Free проверяет указатель на nil, а в остальных случаях ты сам должен сделать эту проверку в деструкторе. Это азы.

это я прекрасно понимаю! но! давай чуток отойдем от реализации в делфи и подумаем: что такое деструктор не созданного объекта!?

>И inherited я бы советовал вызывать.
само собой

>Здесь-то не нать, а вот если потомок не TObject ...
а от чего!? в делфи все классы от TObject...

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, s.ts, Вы писали:

ST>отсутствие шаблонов компенсируется простотой и прозрачностью кода
ST>в общем, то, что применимо в C++ vs C#|Java применимо и в C++ vs Delphi

Угу, только в дельфях GC нет, да и прочей "безопасности"... Даже за памятью надо ручками следить. Так что до C#|Java она сильно не дотягивает.

P.S. Необходимость вызова деструктора предка ручками — это серьезно? Или я чего-то не так понял? Чего, и контсруктор предка тоже ручками всегда вызывать??? А чем это объясняется?

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>это я прекрасно понимаю! но! давай чуток отойдем от реализации в делфи и подумаем: что такое деструктор не созданного объекта!?

Ничего. Если ты его вызовешь, получишь AV. Но все дело-то в том, что вход в код конструктора происходит, когда объект уже создан. И скрытый параметр Self на него ссылается. Все в порядке

>>Здесь-то не нать, а вот если потомок не TObject ...
OAB>а от чего!? в делфи все классы от TObject...

Хм... Я хотел сказать, например, от TWinControl

Не надо забывать инициализировать предка

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, s.ts, Вы писали:

ST>>отсутствие шаблонов компенсируется простотой и прозрачностью кода
ST>>в общем, то, что применимо в C++ vs C#|Java применимо и в C++ vs Delphi

В>Угу, только в дельфях GC нет, да и прочей "безопасности"... Даже за памятью надо ручками следить. Так что до C#|Java она сильно не дотягивает.

А мне, например, нравится именно это. Терпеть не могу, когда система что-то делает, чем я не могу управлять. И что, если есть GS — то это так круто, что остальное уже и не катит?
Безопасность, на мой взгляд, как раз в том,

В>P.S. Необходимость вызова деструктора предка ручками — это серьезно? Или я чего-то не так понял? Чего, и контсруктор предка тоже ручками всегда вызывать??? А чем это объясняется?

Синтаксисом языка. Видно, что делается и как делается, сразу. Delphi самодеятельностью не занимается. Что такого собственно? Это так ужасно?

Здравствуйте, Romkin, Вы писали:

R>Здравствуйте, Владик, Вы писали:

В>>P.S. Необходимость вызова деструктора предка ручками — это серьезно? Или я чего-то не так понял? Чего, и контсруктор предка тоже ручками всегда вызывать??? А чем это объясняется?

R>Синтаксисом языка. Видно, что делается и как делается, сразу. Delphi самодеятельностью не занимается. Что такого собственно? Это так ужасно?

Ужасно то, что в отличие от плюсов он не даёт альтернатив (там можно делать "автоматические" переменные, а можно и не делать), т.е. в любом случае надо это ручками писать в отличие от объектов плюсов — жизнь их ограничена областью видимости...

Здравствуйте, Курилка, Вы писали:

К>Ужасно то, что в отличие от плюсов он не даёт альтернатив (там можно делать "автоматические" переменные, а можно и не делать), т.е. в любом случае надо это ручками писать в отличие от объектов плюсов — жизнь их ограничена областью видимости...

Может быть

Не знаю. Я старый дельфист и не знаю слов на С

Меня это как-то не тревожило. Чего действительно не хватает, так это inline функций и методов, да еще компиляции под определенный набор инструкций

Остальное — дело житейское. Кстати, я неправильно сказал, что Delphi не занимается самодеятельностью, занимается. Но в отношении указателей, она их упорно скрывает. Впрочем, как и Паскаль, традиция.
Кстати, некоторые предопределенные типы данных живут только в области видимости. Строки, динамические массивы и интерфейсы в основном. Кстати, все это — фактически указатели, сущность коих Delphi нагло скрывает.

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB> невозможно в делфях создать класс не от TObject...

Возможно.

Здравствуйте, Курилка, Вы писали:

К>Нифига, наоборот, что для того чтобы писать программы надо больше фигачить — допустим теже интерфейсы пихать для автоматических деструкторов, тогда как в плюсах это изначально так, другое дело, что в дельфе переменные есть по сути ссылки, из-за этого и грабли с деструкторами и пр.
Нету этого. Просто способ программирования, предлагаемый Delphi, несколько другой, нежели в плюсах.
Предполоагается, что прикладной программист вообще не создает новых классов. Кроме форм, генерящихся дизайнером. Это означает, что ему совершенно не надо знать ни о наследовани, ни об инкапсуляции, ни, упаси байт, о полиморфизме. Ему не надо заботиться ни о каких автоматических деструкторах — а зачем? Все компоненты, брошенные на форму, сами умрут когда надо.
Чтобы прикладные программеры могли делать это так просто, нужен некий подготовительный труд со стороны разработчиков компонентов. И там тоже все в порядке — основой управления временем жизни является отношение Owner/ChildComponent. Пока ваши классы укладываются в эту схему, их гарантированно убъют. Все случаи ручного управления созданием объектов сводятся к:

// object with a method scope:
procedure TBlaBla.Bla;
begin
  with TMyCoolClass.Create do 
    try
      // пошел полезный код.
    finally Free;
    end;
end;

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

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Курилка, Вы писали:

К>А вот нихрена!
К>В шарпе и жабе есть GC, а в дельфах не было и не подразумевается, так что уж не сходится...
К>Да и вон в шарп генериксы собираются всё добавить, а в дельфу как более старый язык всё никак даже не задумываются, что надо было бы...
К>Но это всё ИМХО, конечно (но "надо бы")
Ну во первых Борланд плюнул на Native и все силы кинул на Net и Java.
Так что в Delphi 8 есть все перечисленное тобой. А дженерики тоже будут, т.к. это стандарт Net пока 1.2 а в релизе 2.0.
Переходи на Net (как уже поступили очень многие). Только там ты прозрачности увидишь очень мало.

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>Если можно — пример пожалуйста....

object types

Хоть и не рекомендуются справкой, зато позволяют создать свой класс ненаследующий TObject.

Здравствуйте, kavlad, Вы писали:

K>object types
K>Хоть и не рекомендуются справкой, зато позволяют создать свой класс ненаследующий TObject.

И что в таком классе останется от класса?

Весь system, насколько я помню, завязан на TObject...

Здравствуйте, Владик, Вы писали:

В>И что в таком классе останется от класса?

Весь system, насколько я помню, завязан на TObject...

Ограничения, естественно, присутствуют

Здравствуйте, Владик, Вы писали:

В>И что в таком классе останется от класса?

Весь system, насколько я помню, завязан на TObject...
Есть KOL и packed object. А что такое класс в C++????

Здравствуйте, Serginio1, Вы писали:

В>>И что в таком классе останется от класса?

Весь system, насколько я помню, завязан на TObject...
S> Есть KOL и packed object.

KOL я знаю что такое, и TObject там вовсю используется. А что такое "packed object"?

S>А что такое класс в C++????

Гхм. Ну у вас и вопросы, неудобно даже

Какой сравнительный аспект тебя интересует?

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

В>>>И что в таком классе останется от класса?

Весь system, насколько я помню, завязан на TObject...
S>> Есть KOL и packed object.

В>KOL я знаю что такое, и TObject там вовсю используется. А что такое "packed object"?

PRect=^TRect;
  TRect = packed object
    public
      Top, Left, Right, Bottom: integer;
      Temp:Byte;
    private
        function GetWidth: integer;
        procedure SetWidth(AWidth: integer);
        Function GetAsString:String;
    function GetAsWidth: String;
    public
      property Width: integer read GetWidth write SetWidth;
      property AsString: String read GetAsString;


    end;

function TRect.GetAsString: String;
begin

 Result:='Left='+IntToStr(self.Left);
 Result:=Result+'; Right'+IntToStr(self.Right);
end;

function TRect.GetAsWidth: String;
begin

end;

function TRect.GetWidth;
begin
  Result:= Right-Left;
end;

procedure TRect.SetWidth(AWidth: integer);
begin
  Right:= Left+AWidth;
end;

procedure TForm1.Button4Click(Sender: TObject);
Var B:TRect;
    P:Pointer;
    d:Integer;
    rr:TInteger;
begin
    b.Left:=8;
    b.Top:=6;
    b.Right:=10;
    ShowMessage(IntToStr(b.Width));
    ShowMessage(b.AsString);
    ShowMessage(IntToStr(SizeOf(b)));
    ShowMessage(IntToStr(SizeOf(TInteger)));
    ShowMessage(IntToStr(Cardinal(@b.Left)));
    ShowMessage('===='+IntToStr(PRect(@b).Left));
    ShowMessage('PMyInteger(@b.Left).AsString='+PMyInteger(@b.Left).AsString);
    ShowMessage('PMyInteger(@b.Left)^.AsString='+PMyInteger(@b.Left)^.AsString);
    end;

Здравствуйте, Serginio1, Вы писали:

S>[pascal]
S>PRect=^TRect;
S> TRect = packed object

Инкапсуляция присутствует. А как же наследование и полиморфизм?

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

S>>[pascal]
S>>PRect=^TRect;
S>> TRect = packed object

В>Инкапсуляция присутствует. А как же наследование и полиморфизм?

TRect2= packed object(TRect)
TTop:Integer;
end;
А что ручками долго VMT прописать и сделать первым полем ссулку на нее????
Вообще то в Net структуры не имеют наследования. (Скорей неправильно)

Здравствуйте, Serginio1, Вы писали:

S> TRect2= packed object(TRect)
S> TTop:Integer;
S> end;
S> А что ручками долго VMT прописать и сделать первым полем ссулку на нее????

Закат солнца вручную (с) ?

Так вот, были бы у этих packed object'ов виртуальные методы, да конструкторы с деструкторами — получился бы какой-то аналог плюсовых классов

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

S>> TRect2= packed object(TRect)
S>> TTop:Integer;
S>> end;
S>> А что ручками долго VMT прописать и сделать первым полем ссулку на нее????

В>Закат солнца вручную (с) ?

В>Так вот, были бы у этих packed object'ов виртуальные методы, да конструкторы с деструкторами — получился бы какой-то аналог плюсовых классов

Вопрос а зачем они нужны?????
Только из-за размещения в стеке???? А оно нужно????
Заметь в Net структуры и объекты разделены. И сишная симантика является устаревшей.
Заметь и Борланд махнул рукой на Native. Зачем мыслить прошлым???

Здравствуйте, Serginio1, Вы писали:

S> Вопрос а зачем они нужны?????

S>Только из-за размещения в стеке???? А оно нужно????
S> Заметь в Net структуры и объекты разделены.

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

S>И сишная симантика является устаревшей.
S> Заметь и Борланд махнул рукой на Native. Зачем мыслить прошлым???

Речь то шла не о .NET

У NET есть альтернатива (в какой-то степени) — GC. У дельфей альтернативы нет.

P.S. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

S>> Вопрос а зачем они нужны?????

В>

S>>Только из-за размещения в стеке???? А оно нужно????
S>> Заметь в Net структуры и объекты разделены.

В>Исключительно в угоду эффективности, а не из каких-то глубоких идеологических соображений, как я понимаю. В плюсах такое разделение не нужно — там классы сами по себе достаточно эффективны

Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу а за счет гибкости и виртуальных конструкторов во много превышает возможности С++ классов. И именно из- за своей структуры в Net С++ классы дают unsafe код.

S>>И сишная симантика является устаревшей.
S>> Заметь и Борланд махнул рукой на Native. Зачем мыслить прошлым???

В>Речь то шла не о .NET

У NET есть альтернатива (в какой-то степени) — GC. У дельфей альтернативы нет.

У нативной. В Delphi 8 есть.
В>P.S. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?
Можно. Но иногда вызывать нужно в определенной последовательности. Вариантов много.
Особенно когда есть перекрестные ссылки. Но с этим хорошо справляются интерфейсы. Итд итп
Гибкость.

В>Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название.

Кстати, есть подозрение, что конструкторы/деструкторы там вызываются вполне адекватно. Есть знатоки, кто знает?

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

В>>>Исключительно в угоду эффективности, а не из каких-то глубоких идеологических соображений, как я понимаю. В плюсах такое разделение не нужно — там классы сами по себе достаточно эффективны

S>> Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу

В>Не смеши. Размещение в стеке не только заведомо эффективнее любого менеджера хипа, но и дает компилятору возможность оптимизировать работу с такими классами. Возвращаясь к сабжу — посмотри во что превращается стековый auto_ptr, от него вообще ничего не остается в результирующейм коде.
А оно мне надо. В основном это долго играющие объекты. И выгоды от стека нет. Так как и в С++ в основном это ссылки.

S>>а за счет гибкости

В>Какой такой гибкости?

S>>и виртуальных конструкторов во много превышает возможности С++ классов. И

В>Аналоги виртуальных конструкторов в плюсах есть (уже многократно обсуждалось, на любой вкус). Причем намного более безопасные в использовании.
Ну ну. Кстати в Net в Delphi виртуальные конструкторы и статические виртуальные методы сделаны в виде Метаклассов. Но старый механизм мне больше нравится.
S>>именно из- за своей структуры в Net С++ классы дают unsafe код.

В>Этого не понял.

Именно из- за того, что нет разницы между объектом и структурой.
S>>>> Заметь и Борланд махнул рукой на Native. Зачем мыслить прошлым???
В>>>Речь то шла не о .NET

У NET есть альтернатива (в какой-то степени) — GC. У дельфей альтернативы нет.
S>> У нативной. В Delphi 8 есть.

В>Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название.
Идеологически очень схож. Я лично перешел на Net и рад появлению Delphi 8.
В>>>P.S. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?
S>> Можно. Но иногда вызывать нужно в определенной последовательности.

В>Зачем в определенной последовательности? Последовательность вполне логична и очевидна. Сначала конструируется базовый класс, потом наследник. Разрушается наследник, потом базовый класс. Любое отклонение от этой схемы ни к чему кроме глюков не ведет. Причем даже пресловутые виртуальные конструкторы не являются препятствием для реализации такой схемы. Так почему тогда все-таки допускается безобразие с невызовом конструктора/деструктора предка?
Не всегда так. У меня было много ситуаций когда разрушать нужно было сначала в базовом классе, а затем уже в потомках.

S>>Вариантов много.
S>>Особенно когда есть перекрестные ссылки.

В>Не понял? Примерчик?

Например Хип организуется наследником, а заполняется и удаляется в базовым классом но через наследника, то сначала должны вызвать деструктор базового класса, а затем уже свой итд.
Есть объекты хэлперы которые наследуются от базовых классов но удалять внедренные объекты не нужно, так как эти объекты являются полями объекта для которого создается этот класс хэлпер, а только память под этот объект.
Сейчас на вскидку тяжело вспомнить. Но поверь таких ситуаций предостаточно.
S>>Но с этим хорошо справляются интерфейсы. Итд итп
S>> Гибкость.

В>Гибкость??? Где??? А вот глюков можно огрести — это вполне очевидно.
Ну их можно огрести где угодно. Во всяком случае именно в С++ их гораздо больше из-за еще большей гибкости.
Переходи на Net.

Здравствуйте, Владик, Вы писали:

R>>А мне, например, нравится именно это. Терпеть не могу, когда система что-то делает, чем я не могу управлять.

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

Я бы не назвал это механической работой. Деструктор вызывается в разных случаях из разных мест.

R>>Безопасность, на мой взгляд, как раз в том,

В>В чем?

В том, что неожиданностей нет

В>>>P.S. Необходимость вызова деструктора предка ручками — это серьезно? Или я чего-то не так понял? Чего, и контсруктор предка тоже ручками всегда вызывать??? А чем это объясняется?
R>>Синтаксисом языка.

В>Причем здесь синтаксис? Или если я не напишу вызов деструктора предка компилятор ругнется? Тогда претензий нет.

В некоторых случаях хинт/варнинг будет.

В>А если компилятор не ругнется, то тогда еще раз: в чем глубокий смысл возможности не вызова конструктора/деструктора предка? Мне кажется это абсолютно бессмысленным и заведомо ошибочным.

Иногда, как ни странно, надо. Точно тебе говорю

Пример сейчас привести не могу, но было где-то у меня.

Здравствуйте, Romkin, Вы писали:

R>Здравствуйте, Владик, Вы писали:

...

В>>Причем здесь синтаксис? Или если я не напишу вызов деструктора предка компилятор ругнется? Тогда претензий нет.

R>В некоторых случаях хинт/варнинг будет.

"В некоторых" случаях? Т.е. преднамеренная дыра для ликов? Т.е. это более зрелый язык???

Вот это интересно, я фигею...

В>>А если компилятор не ругнется, то тогда еще раз: в чем глубокий смысл возможности не вызова конструктора/деструктора предка? Мне кажется это абсолютно бессмысленным и заведомо ошибочным.

R>Иногда, как ни странно, надо. Точно тебе говорю

Пример сейчас привести не могу, но было где-то у меня.

Всё же есть мнение, что пример кривой

Здравствуйте, Romkin, Вы писали:

В>>Причем здесь синтаксис? Или если я не напишу вызов деструктора предка компилятор ругнется? Тогда претензий нет.
R>В некоторых случаях хинт/варнинг будет.

В некоторых???? И после этого ты рассуждаешь о "безопасности" и "неожиданностях"???

В>>А если компилятор не ругнется, то тогда еще раз: в чем глубокий смысл возможности не вызова конструктора/деструктора предка? Мне кажется это абсолютно бессмысленным и заведомо ошибочным.
R>Иногда, как ни странно, надо. Точно тебе говорю

Пример сейчас привести не могу, но было где-то у меня.

Я думаю когда ты попробуешь его привести, то сам поймешь, что ты не прав, и что пример по сути "кривой".

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

S>>>> Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу

S>> А оно мне надо. В основном это долго играющие объекты.

В>В основном где? В дельфях?

Еще бы, там других не бывает (packed object на роль полноценных классов не годятся).

S>> И выгоды от стека нет. Так как и в С++ в основном это ссылки.

В>Это тебе кто сказал?

Ну почему, представляю. Только не нужны они. Затраты на выделение и освобождения памяти из кучи минимальны. А Простота использавания больше.
В>[...]
S>> Ну ну. Кстати в Net в Delphi виртуальные конструкторы и статические виртуальные методы сделаны в виде Метаклассов. Но старый механизм мне больше нравится.

В>А чем отличается?

нативном Delphi как таковых метаклассов нет. Есть VMT которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)

S>>>>именно из- за своей структуры в Net С++ классы дают unsafe код.
В>>>Этого не понял.
S>> Именно из- за того, что нет разницы между объектом и структурой.

В>ИМХО, ты чего-то не понимаешь. Ну да ладно.
В Net нет долгоживущих ссылк, либо это объекты в куче, либо GC.Alloc ведущий к unsafe, либо работа со ссылками через fixed тоже ведущий к unsafe. Структуры же в Net это Value типы, без наследования.
В>[...]
В>>>Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название.
S>> Идеологически очень схож.

В>ИМХО, ты опять чего-то не понимаешь

Ну да ладно.

Идеалогичски это единая иерархия классов, компонентность. Вот почему дельфисты с легкостью переходят на Net и C#.
В>[...]
S>> Не всегда так. У меня было много ситуаций когда разрушать нужно было сначала в базовом классе, а затем уже в потомках.

В>Не верю. Это говорит лишь о кривом дизайне. Хотя можешь попробовать привести конкретный пример.

Возможно. Но иногда приходится городить огромный абстрактный базовый класс, и не все возможно не только предусмотреть, но и представит будущую логику, т.к. реализаций может быть огромное множество.
В>[...]
S>> Например Хип организуется наследником, а заполняется и удаляется в базовым классом но через наследника, то сначала должны вызвать деструктор базового класса, а затем уже свой итд.

В>Не понял. Чем в данном случае плох вызыв деструктора потомка до деструктора предка???
А втом, что Хип должен уничтожать наследник, или не уничтожать а передавать в другой объект.

S>> Есть объекты хэлперы которые наследуются от базовых классов но удалять внедренные объекты не нужно, так как эти объекты являются полями объекта для которого создается этот класс хэлпер, а только память под этот объект.

В>И чего? Не надо удалять — так не надо. Причем здесь "кривой" порядок вызова деструкторов?

S>> Сейчас на вскидку тяжело вспомнить. Но поверь таких ситуаций предостаточно.

В>Не верю. Ни разу даже желания не возникало уничтожить предка до наследника или делать что-то в конструкторе наследника до конструирования предка. Извращение какое-то. Неужели сам не осознаешь, что это криво и противоестественно? Желание получить виртуальный вызов функции наследника из конструктора предка, каюсь, возникало — но это легко обходится.

В>[...]
S>> Переходи на Net.

В>Как только будет поставлена соответсвующая задача — с удовольствием попробую, что это такое. Хотя не думаю, что открою для себя что-то принципиально новое — с джавой я успел поработать. И, надеюсь, к тому времени там появятся generics (а то точно буду плеваться

Почему они есть правда в Альфе версии, но вполне работоспособны, я на ней только и пишу (правда специальность у меня Программист 1С). И всем советую если есть возможность писать уже на видби.

Здравствуйте, Serginio1, Вы писали:

В>>Это тебе кто сказал?

S> Ну почему, представляю.

Чего ж тогда говоришь, что "долгоиграющих" больше?

S>Только не нужны они.

Аппетит приходит во время еды

В дельфе их нет, поэтому и необходимости в них не испытываешь (если не писал то этого на более других языках).

S>Затраты на выделение и освобождения памяти из кучи минимальны. А Простота использавания больше.

Дык, в чем простота-то? В необходимости делать Free и городить лестницы из try/finally? Спасибо конечно, но мне как-то проще объявить объект и использовать его, а не заботиться о его уничтожении и последствиях бросания исключений. А в качестве бонуса — еще и минимальные затраты на распределение памяти.

[...]
S> нативном Delphi как таковых метаклассов нет. Есть VMT которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)

Чем меня всегда поражали дельфисты, так это глубоким знанием недокументированных особенностей генерируемого компилятором кода

Вопрос не в этом. Впорос — почему тебе метаклассы .NET не понравились? Вопрос без подковырки, просто мне для общего развития

[...]
В>>ИМХО, ты чего-то не понимаешь. Ну да ладно.
S> В Net нет долгоживущих ссылк, либо это объекты в куче, либо GC.Alloc ведущий к unsafe, либо работа со ссылками через fixed тоже ведущий к unsafe. Структуры же в Net это Value типы, без наследования.

Ну и что? Я не вижу никакой связи между плюсовыми классами и классами/структурами .NET...

[...]
S> Идеалогичски это единая иерархия классов, компонентность.

Ну так и говори о иерархии и компонентности. Язык совершенно другой, причем лишенный таких ярко выраженных огрехов как в настоящей дельфе.

[...]
S> Возможно. Но иногда приходится городить огромный абстрактный базовый класс, и не все возможно не только предусмотреть, но и представит будущую логику, т.к. реализаций может быть огромное множество.

Гхм. Зачем городить большой абстрактный класс? И зачем предусматривать особенности реализауии? Цель должна быть обратная — абстрагироваться от этих самых особенностей. В любом случае по-прежнему непонятно, зачем вызывать деструктор этого класса до наследника?

[...]
В>>Не понял. Чем в данном случае плох вызыв деструктора потомка до деструктора предка???
S> А втом, что Хип должен уничтожать наследник, или не уничтожать а передавать в другой объект.

Ну и пусть уничтожает или не уничтожает. Зачем здесь вызывать деструктор предка до деструктора наследника?

[...]
S> Почему они есть правда в Альфе версии, но вполне работоспособны, я на ней только и пишу (правда специальность у меня Программист 1С). И всем советую если есть возможность писать уже на видби.

Что такое "видби"?

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

В>>>Это тебе кто сказал?

S>> Ну почему, представляю.

В>Чего ж тогда говоришь, что "долгоиграющих" больше?

S>>Только не нужны они.

В>Аппетит приходит во время еды

В дельфе их нет, поэтому и необходимости в них не испытываешь (если не писал то этого на более других языках).
Бог с ним. Только в Net и Яве они не использутся.

S>>Затраты на выделение и освобождения памяти из кучи минимальны. А Простота использавания больше.

В>Дык, в чем простота-то? В необходимости делать Free и городить лестницы из try/finally? Спасибо конечно, но мне как-то проще объявить объект и использовать его, а не заботиться о его уничтожении и последствиях бросания исключений. А в качестве бонуса — еще и минимальные затраты на распределение памяти.

Либо за тебя это делает компилятор и тоже объявляет Try/finally как и в Delphi как со строками интерфейсами и динамическими массивами, поэтому лучще их объвлять через Const (не забывая о пдсчете ссылок). Кроме того есть способы сократить эти трудозатраты и увеличить скорость выполнения.

На вкус и цвет ....

В>[...]
S>> нативном Delphi как таковых метаклассов нет. Есть VMT которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)

В>Чем меня всегда поражали дельфисты, так это глубоким знанием недокументированных особенностей генерируемого компилятором кода

В красоте и компактности, нативный вариант лучше. А нетовский это пляска по чужую дудку. Но с точки зрения программирования по барабану.
В>[...]
В>>>ИМХО, ты чего-то не понимаешь. Ну да ладно.
S>> В Net нет долгоживущих ссылк, либо это объекты в куче, либо GC.Alloc ведущий к unsafe, либо работа со ссылками через fixed тоже ведущий к unsafe. Структуры же в Net это Value типы, без наследования.

В>Ну и что? Я не вижу никакой связи между плюсовыми классами и классами/структурами .NET...
По тому что нет этой связи.

В>[...]
S>> Идеалогичски это единая иерархия классов, компонентность.

В>Ну так и говори о иерархии и компонентности. Язык совершенно другой, причем лишенный таких ярко выраженных огрехов как в настоящей дельфе.

Язык как раз тот же. Кстаи на данном этапе совместим на 90%. Но хотелось бы большего.
В>[...]
S>> Возможно. Но иногда приходится городить огромный абстрактный базовый класс, и не все возможно не только предусмотреть, но и представит будущую логику, т.к. реализаций может быть огромное множество.

В>Гхм. Зачем городить большой абстрактный класс? И зачем предусматривать особенности реализауии? Цель должна быть обратная — абстрагироваться от этих самых особенностей. В любом случае по-прежнему непонятно, зачем вызывать деструктор этого класса до наследника?
Устал объяснять. Может сам столкнешься.
В>[...]
В>>>Не понял. Чем в данном случае плох вызыв деструктора потомка до деструктора предка???
S>> А втом, что Хип должен уничтожать наследник, или не уничтожать а передавать в другой объект.

В>Ну и пусть уничтожает или не уничтожает. Зачем здесь вызывать деструктор предка до деструктора наследника?
Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

В>[...]
S>> Почему они есть правда в Альфе версии, но вполне работоспособны, я на ней только и пишу (правда специальность у меня Программист 1С). И всем советую если есть возможность писать уже на видби.

В>Что такое "видби"?
Whidbey новая студия от M$ с поддержкой дженериков основанной на 1.2 нетфреймворк.

Здравствуйте, Serginio1, Вы писали:

В>>Аппетит приходит во время еды

В дельфе их нет, поэтому и необходимости в них не испытываешь (если не писал то этого на более других языках).
S> Бог с ним. Только в Net и Яве они не использутся.

Я ж говорю — там есть альтернатива в виде GC (со своими рулезами и недостатками), у дельфи никакой альтернативы нет. Исключительно ручки программиста. И не надо песен про наглядность и удобство дельфи. Наглядность и удобство кончается в обжект инспекторе. Код — громоздкий и неудобный.

[...]
В>>Дык, в чем простота-то? В необходимости делать Free и городить лестницы из try/finally? Спасибо конечно, но мне как-то проще объявить объект и использовать его, а не заботиться о его уничтожении и последствиях бросания исключений. А в качестве бонуса — еще и минимальные затраты на распределение памяти.

S> Либо за тебя это делает компилятор

Да, за меня это делает компилятор. За что ему большое спасибо. И Страуструпу тоже

А как следствие — от компилятора не требуется специальная поддержка строк, интерфейсов и прочих динамических массивов. Все делается средствами языка. Вот это я и называю гибкостью языка, а не произвольный порядок вызова конструкторов/деструкторв

[...]
В>>Ну так и говори о иерархии и компонентности. Язык совершенно другой, причем лишенный таких ярко выраженных огрехов как в настоящей дельфе.
S> Язык как раз тот же. Кстати на данном этапе совместим на 90%. Но хотелось бы большего.

Хотелось бы ручками делать Free?

Так что там, кстати, с порядком вызова деструкторов?

А они там вообще есть?

На 90% совместим, говоришь?

[...]
зачем вызывать деструктор этого класса до наследника?
S> Устал объяснять. Может сам столкнешься.

Сомневаюсь

Теорию осмысленности такого поведения ты мне не смог объяснить, пример привести тоже. Очевидно потому, что все примеры, когда ты использовал эту "особенность" не выдерживают критики с точки зрения дизайна.

[...]
S> Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

Ты не путай меня, все равно не отвертишься

Какие еще ссылки на объекты базового класса? Давай код.

Здравствуйте, Владик, Вы писали:
В>P.S. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?
Да, можно. Аргументируется это тем, что на самом деле это не конструкторы/деструкторы в смысле С++. У них другая семантика. Та работа, которая возлагается на конструктор класса в С++, выполняется статическим методом TObject.InitInstance. А то, что называется конструктором в Delphi, идеологически ближе к виртуальным инициализаторам. С деструктором класса ситуация аналогичная — поскольку это финализатор, вызов предка является делом вкуса.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Sinclair, Вы писали:

S>Да, можно. Аргументируется это тем, что на самом деле это не конструкторы/деструкторы в смысле С++. У них другая семантика. Та работа, которая возлагается на конструктор класса в С++, выполняется статическим методом TObject.InitInstance. А то, что называется конструктором в Delphi, идеологически ближе к виртуальным инициализаторам. С деструктором класса ситуация аналогичная — поскольку это финализатор, вызов предка является делом вкуса.

Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов? Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?

Здравствуйте, Владик, Вы писали:

В>Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов?
Потому, что "нормальные" деструкторы/конструкторы нельзя сделать виртуальными. Для упрощения компонентной модели в язык принудительно ввели автоматическую реализацию паттерна "абстрактная фабрика", которая и потребовала таких решений. Да, упрощение языка имеет свою цену — например, автоматических объектов в Delphi нет. Как, впрочем, и в Pascal
В>Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?
Нет никакой кривизны в таком решении. Нельзя смотреть на мир через призму объектной модели единственного языка. С точки зрения ООП, конструктор вообще не является необходимым элементом — вполне можно обходиться и без него.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Владик, Вы писали:

В>>Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов?
S>Потому, что "нормальные" деструкторы/конструкторы нельзя сделать виртуальными.

Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые. Было бы желание. Не говоря о том, что можно было просто заплатку на компилятор налепить — требовать (от программиста) обязательного вызова конструкторов/деструкторов базовых классов (как в джаве). И "наглядность" никуда не денется и вероятность глюков меньше.

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

Не требует она таких решений. Она требует лишь полной инициализации VMT до вызова конструктора базового класса.

S>Да, упрощение языка имеет свою цену — например, автоматических объектов в Delphi нет. Как, впрочем, и в Pascal

Принципиального упрощения я тоже здесь не вижу. Делов-то — вставить по умолчанию вызов конструктора/деструктора базового класса.

В>>Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?
S>Нет никакой кривизны в таком решении. Нельзя смотреть на мир через призму объектной модели единственного языка. С точки зрения ООП, конструктор вообще не является необходимым элементом — вполне можно обходиться и без него.

Можно. Зачем тогда сделали "подобие"?

Здравствуйте, Владик, Вы писали:

В>Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые.

Цена этому совмещению — то, что в билдере несозиожно (насколько мне известно — пусть меня поправят, если я ошибаюсь),
напрямую работать с дельфийскими метаклассами.
Приходится отдавать их, как чёрный ящик, функциям, написанным на паскале (напр TApplication.CreateForm),
которые выполняют работу, которую выполнить на Сях нельзя как раз из-за
концепции их конструкторов.

Как, например, в билдере записать такую простейшую дельфийскую ф-ю?

function CreateComp(AClass: TComponentClass; AOwner: TComponent): TComponent; 
begin
  Result := AClass.Create(AOwner);
  // Это краеугольный камень визуальности и сериализации Дельфей
end;

Здравствуйте, Аноним, Вы писали:

В>>Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые.
А>Цена этому совмещению — то, что в билдере несозиожно (насколько мне известно — пусть меня поправят, если я ошибаюсь), напрямую работать с дельфийскими метаклассами.

Нет. Невозможность в том, что борланд не удосужился сделать синтаксис
для ручного вызова конструктора в билдере. Паскальные "заглушки" нужны только для того, чтобы вызывать этот пресловутый Create, который "мапится" на плюсовый конструктор соответствующего класса. Можно обойтись и без паскаля, если напрямую залезть в VMT (пример где-то пробегал).

Здравствуйте, Владик, Вы писали:

В>Здравствуйте, Serginio1, Вы писали:

В>>>Аппетит приходит во время еды

В дельфе их нет, поэтому и необходимости в них не испытываешь (если не писал то этого на более других языках).
S>> Бог с ним. Только в Net и Яве они не использутся.

В>Я ж говорю — там есть альтернатива в виде GC (со своими рулезами и недостатками), у дельфи никакой альтернативы нет. Исключительно ручки программиста. И не надо песен про наглядность и удобство дельфи. Наглядность и удобство кончается в обжект инспекторе. Код — громоздкий и неудобный.

Да меня на данном этапе Native Delphi вообще не волнует так же как и Борланда.
В>[...]
В>>>Дык, в чем простота-то? В необходимости делать Free и городить лестницы из try/finally? Спасибо конечно, но мне как-то проще объявить объект и использовать его, а не заботиться о его уничтожении и последствиях бросания исключений. А в качестве бонуса — еще и минимальные затраты на распределение памяти.

S>> Либо за тебя это делает компилятор

В>Да, за меня это делает компилятор. За что ему большое спасибо. И Страуструпу тоже

Это гибкость не языка а компилятора.

В>[...]
В>>>Ну так и говори о иерархии и компонентности. Язык совершенно другой, причем лишенный таких ярко выраженных огрехов как в настоящей дельфе.
S>> Язык как раз тот же. Кстати на данном этапе совместим на 90%. Но хотелось бы большего.

В>Хотелось бы ручками делать Free?

Так что там, кстати, с порядком вызова деструкторов?

А они там вообще есть?

На 90% совместим, говоришь?

А Free тебе по любому вызывать придется для освобождения системных ресурсов.
С вызовами деструкторов все так же как и в Delphi.

В>[...]
В>зачем вызывать деструктор этого класса до наследника?
S>> Устал объяснять. Может сам столкнешься.

В>Сомневаюсь

Теорию осмысленности такого поведения ты мне не смог объяснить, пример привести тоже. Очевидно потому, что все примеры, когда ты использовал эту "особенность" не выдерживают критики с точки зрения дизайна.
Иногда дизайн на все случаи жизни не предусмотреть, а взять некий класс и с минимальными потребностями переделать по себя это легче. Но иногда возникают проблемы с порядком а иногда и вообще не вызывать деструктор предка, если все нужные действия предусмотреть в наследнике.
В>[...]
S>> Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

В>Ты не путай меня, все равно не отвертишься

Какие еще ссылки на объекты базового класса? Давай код.
Не хочу искать.

Здравствуйте, Serginio1, Вы писали:

S> Да меня на данном этапе Native Delphi вообще не волнует так же как и Борланда.

И это правильно

[...]
S> Это гибкость не языка а компилятора.

Без комментариев...

[...]
В>>Хотелось бы ручками делать Free?

Так что там, кстати, с порядком вызова деструкторов?

А они там вообще есть?

На 90% совместим, говоришь?

S> А Free тебе по любому вызывать придется для освобождения системных ресурсов.
S>С вызовами деструкторов все так же как и в Delphi.

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

[...]
S>Но иногда возникают проблемы с порядком а иногда и вообще не вызывать деструктор предка, если все нужные действия предусмотреть в наследнике.

Ужас какой... И такое вытворяют на языке, прародителем которого считают Вирта...

В>>[...]
S>>> Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

В>>Ты не путай меня, все равно не отвертишься

Какие еще ссылки на объекты базового класса? Давай код.
S> Не хочу искать.

И не ищи. Забудь как страшный сон.

От:	kavlad	http://www.wavesoft.ru
Дата:	24.02.04 13:14
Оценка:	14 (2)

	От:	Romkin
	Дата:	25.02.04 15:12
	Оценка:	4 (1)

От:	Курилка	http://kirya.narod.ru/
Дата:	25.02.04 13:39
Оценка:	-1

	От:	Oleg A. Bachin
	Дата:	25.02.04 14:28
	Оценка:	+1

От:	Курилка	http://kirya.narod.ru/
Дата:	25.02.04 14:29
Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	24.02.04 15:46
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	26.02.04 09:48
Оценка: