AfterConstruction, beforedestruction у record

← →
oxffff © (2011-04-06 15:49) [0]

Приветствую, всех.

Многи финты С++ основаны на автоматическом вызове деструктора у записей в С++.

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

Занимаясь развитием своего языка YAR, мне бы не хотелось вводить
перегрузку оператора присваивания и конструктор копий, но тем не менее хотелось бы добавить финты С++.

Ваше мнение о введении AfterConstruction и beforedestruction у записей.
То есть это просто методы не более. В них не нужно ничего освобождать и инициализировать. Если они есть у типа, компилятор проставит их вызовы в начало и конец области видимости экземпляра.

Мне нравится. А что думаете Вы?

← →
Kerk © (2011-04-06 15:54) [1]

Указатель на такую запись как будет работать?

← →
oxffff © (2011-04-06 15:58) [2]

> Kerk © (06.04.11 15:54) [1]
> Указатель на такую запись как будет работать?

?

Финализироваться(аналог dispose) с вызовом beforedestruction.

← →
Mystic © (2011-04-06 16:49) [3]

Я думаю, что Ada рулит:
http://ada-ru.selfip.org:88/V-0.4w/part_1/ch_14.html

← →
DiamondShark © (2011-04-06 16:51) [4]

> Мне нравится. А что думаете Вы?

Мы думаем, что пора прекратить маяться ерундой по принципу: "С миру по фиче -- голому язык программирования", а начать собирать use case для предполагаемых фич.

Какие у тебя результаты по анализу применения деструкторов записей в С++?
Какие у тебя мысли по поводу того, что в Дельфи они никому в пень не тарахтели?

Если тебе хотелось бы их добавить, значит ты сможешь внятно ответить на вопрос: "С какой целью?".

← →
oxffff © (2011-04-06 17:03) [5]

> Mystic © (06.04.11 16:49) [3]
> Я думаю, что Ada рулит:
> http://ada-ru.selfip.org:88/V-0.4w/part_1/ch_14.html

Почитаю.

← →
han_malign (2011-04-06 17:21) [6]

Что-то я не увидел отличий от обычных(C++) конструктора/деструктора...
"Сложности" возникают только при реализации умных указателей(подразумевается любой захват любого ресурса) - и от этого ты никуда и никак не денешься...

З.Ы. Ты еще забыл об explicit...

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

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

← →
Kerk © (2011-04-06 17:38) [7]

Не удобнее ли в таких случаях классы использовать?

← →
DiamondShark © (2011-04-06 17:52) [8]

> han_malign (06.04.11 17:21) [6]
> - ну просто абсолютно не нужны - каждый обязан явно инициализировать
> и зачищать статически размещенные структуры - если он этого
> не делает - то сам себе кретин...

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

О том, что члены с управляемым временем жизни инициализируются и финализируются в Дельфи автоматически, ты, судя по твоему коменту, вообще не знал.

← →
han_malign (2011-04-06 18:13) [9]

> Можешь без истерик

- я просто подстраиваюсь под вашу безапелляционную риторику.

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

- ну надо же...
Что и TRTLCriticalSection - тоже? Ну или хотя бы TCriticalSection? Или временем жизни этой и подобных структур не надо управлять?

← →
Kerk © (2011-04-06 18:19) [10]

> han_malign (06.04.11 18:13) [9]

Типы с управляемым временем жизни - это не те, временем жизни которых нужно управлять.

← →
TUser © (2011-04-06 19:53) [11]

> Kerk © (06.04.11 17:38) [7]
>
> Не удобнее ли в таких случаях классы использовать?
>

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

С этой точки зрения проще расширяемый record с возможностью добавить еще и методы. То есть наследование, инкапсуляция - пож-та, но без лишних тормозов. Насколько я понимаю, это реализовано в Обероне и старших версиях Делфи.

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

Taaa = record
N: integer;
end;

Tbbb = record (Taaa)
procedure inc;
end;

должно быть эквивалентно

Tbbb = record
N: integer;
end;

Pbbb = ^Tbbb;

procedure inc (bbb: Pbbb);

Имхо, разумеется.

← →
TUser © (2011-04-06 19:55) [12]

> Потому как это не просто запись, а конструктор, который
> при создании вызывает смотрите сколько кода.

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

← →
Kerk © (2011-04-06 20:11) [13]

> Имхо: классы, в том виде, в каком они нам известны в Delphi,
> смущают громоздкостью. Потому как это не просто запись,
> а конструктор, который при создании вызывает смотрите сколько
> кода. Поэтому, если я пишу, допустим, текстовый редактор,
> то каждая буква у меня не будет объектом, хотя, возможно,
> это и идеологически правильно с точки зрения ООП (объект
> реального мира = объект в программе).

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

← →
Ega23 © (2011-04-06 20:19) [14]

Да и не так уж у класса много кода...

← →
_Юрий (2011-04-06 20:52) [15]

>TUser ©
> то каждая буква у меня не будет объектом

Жалко по 4 лишних байта на букву? Около 20 мегабайт при загрузке "войны и мира" и гигабайтах оперативки ?)

← →
Ega23 © (2011-04-06 21:11) [16]

> Поэтому, если я пишу, допустим, текстовый редактор, то каждая
> буква у меня не будет объектом

А буква и не должна быть объектом, объектом должен быть Token. А это либо символ, либо совокупность символов (слово), либо ещё какая-нить фигня, типа управляющих символов.

← →
TUser © (2011-04-06 21:19) [17]

> А буква и не должна быть объектом, объектом должен быть
> Token.

от задачи зависит

← →
DiamondShark © (2011-04-06 22:02) [18]

> han_malign (06.04.11 18:13) [9]
> я просто подстраиваюсь

И так и не ответил на вопрос: "Зачем нужны неявно инициализированные структуры"?

> Что и TRTLCriticalSection - тоже? Ну или хотя бы TCriticalSection?
> Или временем жизни этой и подобных структур не надо управлять?

Во-первых, > Kerk © (06.04.11 18:19) [10]

Во-вторых, чисто так, ради интереса: много у тебя TRTLCriticalSection со временем жизни в процедуру?

Ты, когда "просто подстраиваешься", голову выключаешь?

← →
Kerk © (2011-04-06 22:08) [19]

Просветите меня по поводу записей, я все еще на старых Delphi сижу.

Вот раньше можно было делать что-то типа:

TSomeRec = record (или packed record) A, B: Integer end; ... var SomeRecFile = file of TSomeRec; ... //ну дальше понятно

А что теперь будет, если я в эту запись засуну метод?

← →
Германн © (2011-04-06 22:14) [20]

> А что теперь будет, если я в эту запись засуну метод?
>

Имхо то же самое.

← →
Игорь Шевченко © (2011-04-06 22:27) [21]

например, будет вот так:

THSDateRangeRec = record public DateFrom: TDateTime; DateTill: TDateTime; function IsValid (EmptyAllowed: Boolean): Boolean; function ContainsDate (const Value: TDateTime): Boolean; end; { THSDateRangeRec } function THSDateRangeRec.ContainsDate(const Value: TDateTime): Boolean; begin Result := (DateFrom <= Value) and (Value <= DateTill); end; function THSDateRangeRec.IsValid(EmptyAllowed: Boolean): Boolean; begin if not EmptyAllowed then Result := (DateFrom <> 0) and (DateTill <> 0) and (DateFrom <= DateTill) else Result := (DateFrom = 0) or (DateTill = 0) or (DateFrom <= DateTill); end;

← →
Kerk © (2011-04-06 22:36) [22]

> Игорь Шевченко © (06.04.11 22:27) [21]

Вопрос был не об этом :)
Вопрос в том, что будет с file of THSDateRangeRec

← →
Игорь Шевченко © (2011-04-06 22:38) [23]

> Вопрос в том, что будет с file of THSDateRangeRec

Все хорошо будет с файлом. Два поля в каждой записи

← →
Kerk © (2011-04-06 22:41) [24]

Ясно, значит методы игнорируются. А SizeOf(THSDateRangeRec) что вернет?

← →
Игорь Шевченко © (2011-04-06 22:50) [25]

> Ясно, значит методы игнорируются. А SizeOf(THSDateRangeRec)
> что вернет?

Как и следует ожидать

← →
DiamondShark © (2011-04-07 01:26) [26]

Турбопаскалевский object живее всех живых.

← →
oxffff © (2011-04-07 09:24) [27]

RAII

http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.html
Но создавать еще два дополнительных объекта для финализации накладно.

← →
Компромисс (2011-04-07 12:10) [28]

Насчет символов в качестве объектов:

A classic example usage of the flyweight pattern is the data structures for graphical representation of characters in a word processor. It might be desirable to have, for each character in a document, a glyph object containing its font outline, font metrics, and other formatting data, but this would amount to hundreds or thousands of bytes for each character. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character (in the document and/or the page) would need to be stored internally.

http://en.wikipedia.org/wiki/Flyweight_pattern

← →
jack128_ (2011-04-07 13:53) [29]

> http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.
> html
> Но создавать еще два дополнительных объекта для финализации
> накладно

можно обойтись одним.

← →
jack128_ (2011-04-07 14:05) [31]

> По-моему, оно читаемости только вредит.

в том виде, который по ссылке - конечно вредит.

а так:

var Obj: TMyObject; begin Obj := TMyObject.Create(...); Obj.AutoDestroy(); .... end;

или так:

var Obj: TSharedPtr<TMyObject>; begin Obj := TMyObject.Create(...); Obj.Value.SameMethod(); .... end;

?

Все-таки, если в Delphi нет сборщика мусора, стоит с этим смириться, а не пытаться ковылять на костылях. IMHO.

← →
Sapersky (2011-04-07 14:40) [33]

Ну как сказать, те же автоматически финализируемые типы есть.
Теоретически можно прикрутить этот же механизм (с возможностью выбора - ручное/автоосвобождение) к обычным классам. Вроде бы принципиальных препятствий нет... или я не вижу?
Copy-on-write и прочих изощрений не надо, просто счётчик ссылок, как у дин. массива.
В общем, конечно, это не "серебрянная пуля" (опять же, не слышал чтобы сишный аналог - smart_ptr/auto_ptr, или как его там - произвёл какую-то революцию), но было бы приятно.

← →
Sapersky (2011-04-07 14:48) [34]

Вроде бы принципиальных препятствий нет

Не считая, конечно, такой мелочи, что прикручивать должен разработчик компилятора/RTL :)

← →
_Юрий (2011-04-07 19:09) [35]

> Все-таки, если в Delphi нет сборщика мусора, стоит с этим
> смириться, а не пытаться ковылять на костылях. IMHO.

может быть, автоматическое уничтожение потомков TInterfacedObject - тоже костыли?

А разве нет? Правда тут выбора не было, надо же было как-то работу с COM поддерживать. Вот, например, попробуй положить некоторое количество потомков TInterfacedObject в TObjectList и посмотреть что будет.

TInterfacedObject ведь потомок TObject, правильно? Значит теоретически, он в этот лист должен бы лечь без проблем :)

> Вот, например, попробуй положить некоторое количество потомков
> TInterfacedObject в TObjectList и посмотреть что будет.

Бурный смех в зале

← →
_Юрий (2011-04-07 19:56) [38]

> Вот, например, попробуй положить некоторое количество потомков
> TInterfacedObject в TObjectList и посмотреть что будет.

попробуй несколько экземпляров непотомков TInterfacedObject положить в два TObjectList"а.

Или попробуй вызвать memo1.lines.Free;
Кругом одни костыли! Боже как страшно жить

> _Юрий (07.04.11 19:56) [38]

Хорошо, попробуем на примере.

Допустим, у нас есть класс TMyClass. Для чистоты эксперимента специально не сообщаю от чего он наследован и что у него внутри.

Теперь ситуация №1. Мы видим код
var MyClass: TMyClass; begin //... MyClass.MyProp.Free; //...

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

Теперь ситуация №2.
function TForm1.CreateMyClass: TObject; begin Result := TMyClass.Create; end;
Ответь мне, пожалуйста, в этом коде есть ошибка?

> может быть, автоматическое уничтожение потомков TInterfacedObject
> - тоже костыли?

А где есть автоматическое уничтожение потомков TInterfacedObject?

AfterConstruction, beforedestruction у record Найти похожие ветки