Здравствуйте, 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;
Здравствуйте, Владик, Вы писали:
В>Здравствуйте, 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. Так мне так и не ответили — в дельфях действительно можно не вызывать конструкторы/деструкторы предков? И если да, то как такое... гхм... безобразие аргументируется?
Можно. Но иногда вызывать нужно в определенной последовательности. Вариантов много.
Особенно когда есть перекрестные ссылки. Но с этим хорошо справляются интерфейсы. Итд итп
Гибкость.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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 прекрасный менеджер памяти невелирует эту разницу
В>Не смеши. Размещение в стеке не только заведомо эффективнее любого менеджера хипа, но и дает компилятору возможность оптимизировать работу с такими классами. Возвращаясь к сабжу — посмотри во что превращается стековый 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.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Эффективны за счет монолитных структур и стека. В Delphi прекрасный менеджер памяти невелирует эту разницу
S> А оно мне надо. В основном это долго играющие объекты.
В основном где? В дельфях? Еще бы, там других не бывает (packed object на роль полноценных классов не годятся).
S> И выгоды от стека нет. Так как и в С++ в основном это ссылки.
Это тебе кто сказал? Количество автоматических объектов в плюсовой программе на порядки превосходит количесвто динамических. Ты даже не представляешь, сколько много может быть автоматических объектов на все случаи жизни
[...] S> Ну ну. Кстати в Net в Delphi виртуальные конструкторы и статические виртуальные методы сделаны в виде Метаклассов. Но старый механизм мне больше нравится.
А чем отличается?
S>>>именно из- за своей структуры в Net С++ классы дают unsafe код. В>>Этого не понял. S> Именно из- за того, что нет разницы между объектом и структурой.
ИМХО, ты чего-то не понимаешь. Ну да ладно.
[...] В>>Не смешно. Delphi 8 это идеологически совершенно другой язык (ты правда этого еще не понял?). От дельфи там только синтаксис и название. S> Идеологически очень схож.
ИМХО, ты опять чего-то не понимаешь Ну да ладно.
[...] S> Не всегда так. У меня было много ситуаций когда разрушать нужно было сначала в базовом классе, а затем уже в потомках.
Не верю. Это говорит лишь о кривом дизайне. Хотя можешь попробовать привести конкретный пример.
[...] S> Например Хип организуется наследником, а заполняется и удаляется в базовым классом но через наследника, то сначала должны вызвать деструктор базового класса, а затем уже свой итд.
Не понял. Чем в данном случае плох вызыв деструктора потомка до деструктора предка???
S> Есть объекты хэлперы которые наследуются от базовых классов но удалять внедренные объекты не нужно, так как эти объекты являются полями объекта для которого создается этот класс хэлпер, а только память под этот объект.
И чего? Не надо удалять — так не надо. Причем здесь "кривой" порядок вызова деструкторов?
S> Сейчас на вскидку тяжело вспомнить. Но поверь таких ситуаций предостаточно.
Не верю. Ни разу даже желания не возникало уничтожить предка до наследника или делать что-то в конструкторе наследника до конструирования предка. Извращение какое-то. Неужели сам не осознаешь, что это криво и противоестественно? Желание получить виртуальный вызов функции наследника из конструктора предка, каюсь, возникало — но это легко обходится.
[...] S> Переходи на Net.
Как только будет поставлена соответсвующая задача — с удовольствием попробую, что это такое. Хотя не думаю, что открою для себя что-то принципиально новое — с джавой я успел поработать. И, надеюсь, к тому времени там появятся generics (а то точно буду плеваться
Здравствуйте, Владик, Вы писали:
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 которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)
В>Чем меня всегда поражали дельфисты, так это глубоким знанием недокументированных особенностей генерируемого компилятором кода Вопрос не в этом. Впорос — почему тебе метаклассы .NET не понравились? Вопрос без подковырки, просто мне для общего развития
В красоте и компактности, нативный вариант лучше. А нетовский это пляска по чужую дудку. Но с точки зрения программирования по барабану. В>[...] В>>>ИМХО, ты чего-то не понимаешь. Ну да ладно. 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Весь system, насколько я помню, завязан на TObject... 
Пример сейчас привести не могу, но было где-то у меня.
