Здравствуйте, 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...

Здравствуйте, 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;

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

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

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

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

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

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

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

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

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

В чем?

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

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

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

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

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

К>А вот нихрена!
К>В шарпе и жабе есть 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++????