Встречаем Record Helper

← →
oxffff © (2007-03-11 13:30) [0]

Согласно
http://forum.ixbt.com/topic.cgi?id=26:33495-8
и
http://forum.sources.ru/index.php?showtopic=143384

Можно объявлять и Record Helper.

Помощь молчит по этому поводу.

← →
oxffff © (2007-03-11 13:31) [1]

Вот пример.
(C) Взято из http://forum.ixbt.com/topic.cgi?id=26:33495-8

TRectHelper = Record Helper For TRect

Function GetWidth : Integer; Inline;
Function Getheight : Integer; Inline;

Property Width : Integer Read GetWidth;
Property Height : Integer Read GetHeight;

End;

← →
Kerk © (2007-03-11 13:55) [2]

Ну и бредятина

← →
oxffff © (2007-03-11 14:05) [3]

> Kerk © (11.03.07 13:55) [2]
> Ну и бредятина

?
Поясни

← →
Kerk © (2007-03-11 14:09) [4]

> [3] oxffff © (11.03.07 14:05)

Нафига такие извраты? Тогда б уж object не убирали

← →
oxffff © (2007-03-11 14:19) [5]

> Kerk © (11.03.07 14:09) [4]
> > [3] oxffff © (11.03.07 14:05)
>
> Нафига такие извраты? Тогда б уж object не убирали

Кстати и все таки есть плюс. Как я не противился в других ветках.
Что касаемо реализации.

Object мог запутать.
Поскольку к нему можно было применить Typeof для получения VTB.

А виртульные методы в record не объявишь.

Это удобная настройка над TRect. Тот же scope.

Вместо того чтобы

function Width(Rect:Trect):integer;

пишешь rect.Width, что в принципе удобно.
Поскольку тот же scope и псевдо-методы классифицируются.
Хотя дело вкуса.

← →
Аноним (2007-03-11 18:00) [6]

> Kerk ©

Ты не прав. Штука действительно классная. Другое дело, что компилятор таки глючит на многих новых расширениях синтаксиса, в том числе и на рекорд-хелперах.

← →
Суслик © (2007-03-11 18:31) [7]

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

> Ты не прав. Штука действительно классная. Другое дело, что
> компилятор таки глючит на многих новых расширениях синтаксиса,
> в том числе и на рекорд-хелперах.

а чтобы компилтор не глючил нужно репорты писать.

-------
кстати в новой версии очень неплохо пофиксили ошибки, связанные с advanced records. Самая мерзкая - что нельзя было вызывать метод у записи, которая возвращена в результате функции:

getRecord().SomeMethod().

очень часто (не всегда) это приводит к internal error с1624.

← →
jack128 © (2007-03-11 20:34) [8]

oxffff © (11.03.07 13:30)
Можно объявлять и Record Helper.
И можно было объявлять с момента выхода D2006

← →
Игорь Шевченко © (2007-03-11 20:41) [9]

А нафига ?

Мне кто-нибудь может объяснить, в чем полезность этой фичи ?

← →
просто так (2007-03-11 21:07) [10]

моск отцов из борланд плодит "гениальные" идеи

← →
oxffff © (2007-03-11 21:28) [11]

> jack128 © (11.03.07 20:34) [8]
> oxffff © (11.03.07 13:30)
> Можно объявлять и Record Helper.
> И можно было объявлять с момента выхода D2006

Но help про них умалчивает.

← →
Petr V.Abramov (2007-03-11 23:55) [12]

> oxffff © (11.03.07 21:28) [11]
если хелп умалчивает, это может значить одно из:
1. нельзя
2. потом не жалуйся

← →
Юрий Зотов © (2007-03-12 00:01) [13]

> Игорь Шевченко © (11.03.07 20:41) [9]

> в чем полезность этой фичи ?

ИМХО, в том же, в чем и хелперов классов. Положим, я юзаю некую библиотеку, в которой используется некий Record. Но мне по каким-то причинам требуется расширить его функциональность. Пишу хелпер.

← →
oxffff © (2007-03-12 00:03) [14]

> ИМХО, в том же, в чем и хелперов классов. Положим, я юзаю
> некую библиотеку, в которой используется некий Record. Но
> мне по каким-то причинам требуется расширить его функциональность.
> Пишу хелпер.

Прошу вас в соседнию ветку
Вот завел себе блог (Суслик 12.03.07 00:02)

← →
Игорь Шевченко © (2007-03-12 00:06) [15]

Юрий Зотов © (12.03.07 00:01) [13]

процедуру напиши

← →
oxffff © (2007-03-12 00:07) [16]

> Игорь Шевченко © (12.03.07 00:06) [15]
> Юрий Зотов © (12.03.07 00:01) [13]
>
> процедуру напиши

Нет helper
:)

← →
Юрий Зотов © (2007-03-12 00:09) [17]

> Игорь Шевченко © (12.03.07 00:06) [15]

Тогда и ООП на фиг не нужно. Любую программу можно написать и на процедурном подходе - но иногда ООП позволяет сделать это проще и удобнее. То же и здесь.

← →
Юрий Зотов © (2007-03-12 00:12) [18]

> oxffff © (12.03.07 00:03) [14]

Я там был. Ну да, возможны баги - ну и что? Одно дело - принципиальная возможность, другое - баг в ее реализации.

← →
oxffff © (2007-03-12 00:16) [19]

> Юрий Зотов © (12.03.07 00:12) [18]
> > oxffff © (12.03.07 00:03) [14]
>
> Я там был. Ну да, возможны баги - ну и что? Одно дело -
> принципиальная возможность, другое - баг в ее реализации.
>

В этой ветки уже обсуждают целесообразность применения
class helper

← →
Игорь Шевченко © (2007-03-12 00:20) [20]

Юрий Зотов © (12.03.07 00:09) [17]

> Тогда и ООП на фиг не нужно.

А что ООП - это жупел что ли ? Или серебряная пуля ? Вовсе нет.
Юра, покажи мне пример, когда helper для record"а будет проще и удобнее, чем процедура, работающая с этим рекордом.

Вот честное слово, интересно мне.

← →
Юрий Зотов © (2007-03-12 00:22) [21]

Вдогонку. Честно говоря, я вообще не вполне понимаю, зачем понадобились рекорды с методами. По сути, это статические объекты - и уж если в них возникла нужда, так не проще было ввести что-то вроде описателя static:
type TMyClass = class(...) ... end; var MyClass: TMyClass; static;
И все. Компилятор просто строит код создания объекта при входе в область видимости переменной MyClass его автоматического убиения при выходе из этой области. Остальное (VMT, RTTI и пр.) - не меняется.

← →
oxffff © (2007-03-12 00:26) [22]

> Юрий Зотов © (12.03.07 00:22) [21]
> Вдогонку. Честно говоря, я вообще не вполне понимаю, зачем
> понадобились рекорды с методами. По сути, это статические
> объекты - и уж если в них возникла нужда, так не проще было
> ввести что-то вроде описателя static:
>
> type
> TMyClass = class(...)
> ...
> end;
>
> var
> MyClass: TMyClass; static;
>
> И все. Компилятор просто строит код создания объекта при
> входе в область видимости переменной MyClass его автоматического
> убиения при выходе из этой области. Остальное (VMT, RTTI
> и пр.) - не меняется.

Зачем так усложнять. Перегружаешь NewInstance и FreeInstance.
В куче выделяешь псевдо стек. И свой esp в переменной.

← →
Юрий Зотов © (2007-03-12 00:28) [23]

> Игорь Шевченко © (12.03.07 00:20) [20]

> А что ООП - это жупел что ли ?

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

> пример, когда helper для record"а будет проще и удобнее, чем процедура,
> работающая с этим рекордом.

Инкапсуляция, Игорь. Код лучше структурируется, легче читается и т.д. А пример ты и сам легко напишешь.

← →
oxffff © (2007-03-12 00:30) [24]

>Вдогонку. Честно говоря, я вообще не вполне понимаю, зачем
> понадобились рекорды с методами. По сути, это статические
> объекты

Естественно ноги растут из .NET struct c методами и интерфейсами. Только понятно, что в самой области памяти занимаемой структурой нет никаких сслылок аля всех тех которые по отрицательному смещению от VTB.
Да и не нужны они, поскольку нет наследования для структур. Поэтому тип известен на этапе компиляции и однозначно можно вызвать метод или получить интерфейс для этого типа.

← →
Petr V.Abramov (2007-03-12 00:31) [25]

> Юрий Зотов © (12.03.07 00:28) [23]
Юр, а какова, на твой взгляд, принципиальная разница между объектом и рекордом с мЕтодами? На мой взгляд, фигней люди занимаются.

← →
Юрий Зотов © (2007-03-12 00:32) [26]

> oxffff © (12.03.07 00:26) [22]

Имелось в виду - на уровне языка. Ручками-то, яснь пень, можно сделать что угодно - но уж если разработчикам вдруг захотелось ввести в сам язык статические объекты - так зачем было делать их именно на базе record? Вот это непонятно.

← →
Petr V.Abramov (2007-03-12 00:33) [27]

> oxffff © (12.03.07 00:30) [24]
не видел [24], пока писАл :)

← →
oxffff © (2007-03-12 00:35) [28]

To Юрий Зотов ©
Зачем record VMT ведь наследования нет.

← →
Petr V.Abramov (2007-03-12 00:38) [29]

> Зачем record VMT ведь наследования нет.
Да люди, которые библиотеку разрабатывали, ушли или в другие места, или в запой. А которые компилятор делают - им до сих пор не надоело :)))

← →
Юрий Зотов © (2007-03-12 00:41) [30]

> oxffff © (12.03.07 00:35) [28]

Не понял. Где я говорил про record VMT?

← →
Игорь Шевченко © (2007-03-12 00:41) [31]

Юрий Зотов © (12.03.07 00:28) [23]

Так я в соседней ветке как раз об удобстве чтения ситуация вида Memo.Lines.DoWork и писал - неудобно, когда вдруг встречаются неожиданные методы.

← →
oxffff © (2007-03-12 00:46) [32]

> Не понял. Где я говорил про record VMT?

ОК. Я не правильно распознал контекст.

Что касаемо

> MyClass: TMyClass; static;

Тогда появиться конструктор по умолчанию.
Вообщем а у конструктора с параметрами не будет знать, как объекту выделена память.
Придется по мимо регистра dl, и флаг выделения памяти указывать.
Усложнится компилятор.

← →
oxffff © (2007-03-12 00:48) [33]

Также и с деструктором.
dl и флаг выделения памяти.

← →
Юрий Зотов © (2007-03-12 00:50) [34]

> Юрий Зотов © (12.03.07 00:28) [23]

Понятие "неожиданный" относительно. Дело документированности и привычки. Тебя же не смущает Memo.Lines.SaveToFile? Нет, потому что этот метод документирован, не раз тобой юзался и ты к нему привык. А поюзаешь какой-нибудь хелпер, так и Memo.Lines.DoWork тоже тебя не смутит.

ИМХО, хелперы - штука мощная. Фактически, позволяет сделать нечто вроде множественного наследования. Кому как, а мне далеко не раз не хватало чего-то подобного.

← →
oxffff © (2007-03-12 00:52) [35]

>Фактически, позволяет сделать нечто вроде множественного наследования

Ancestor list - это опечатка. Только один helper родитель

← →
Юрий Зотов © (2007-03-12 00:56) [36]

[34] было ответом на [31].

> oxffff © (12.03.07 00:46) [32]

Само собой, появится. И компилятор тоже усложнится. Но, ИМХО, он усложнился бы меньше, чем если учить его работать с хитрыми рекордами.

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

← →
Petr V.Abramov (2007-03-12 00:59) [37]

> ИМХО, хелперы - штука мощная. Фактически, позволяет сделать нечто вроде множественного наследования.
а почему бы не сделать множественное наследование, как у врагов?
а вот когда это "вроде" найдет отражение в батонокидательстве, тогда будет ПРИНЦИПИАЛЬНО новое.
А пока - ничего. Вот в MS студии сделали property binding - ниче нового, но это то, что руками делалось. А в d.net - ну чего такого, что принципиально скорость ПРИКЛАДНОЙ разработки повысит?

← →
Юрий Зотов © (2007-03-12 01:00) [38]

> oxffff © (12.03.07 00:52) [35]

Тоже не понял.

← →
oxffff © (2007-03-12 01:03) [39]

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

MyClass: TMyClass; static;

Конструктор вызывает classCreate, который выделяет память.
Поэтому у конструктора должна быть информация выделять память или нет для NonStatic и для Static объектов.

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

← →
oxffff © (2007-03-12 01:07) [40]

> Юрий Зотов © (12.03.07 01:00) [38]
> > oxffff © (12.03.07 00:52) [35]
>
> Тоже не понял.

type
identifierName = class helper [(ancestor list)] for classTypeIdentifierName
memberList
end;

← →
oxffff © (2007-03-12 01:10) [41]

Вообщем не смешаете вы таким образом Stack и Ref семантику

← →
jack128 © (2007-03-12 01:16) [42]

oxffff © (12.03.07 0:52) [35]
Ancestor list - это опечатка.
Или баг в реализации компилира ;-)
Хотя по зрелому размышлению я таки пришел к выводу, что тут нужно думать, стоит ли такую фишку делать. Нужно смотреть, как, например, в С++ решаются конфликты имен при множественном наследовании..

oxffff © (12.03.07 0:26) [22]
Зачем так усложнять. Перегружаешь NewInstance и FreeInstance.
В куче выделяешь псевдо стек. И свой esp в переменной.
Не. Тогда те придется самому вызывать деструктор. А это - лень. Хочется, чтоб все само вызывалость :-) Как с С++

Юрий Зотов © (12.03.07 0:22) [21]
var
MyClass: TMyClass; static;
А если у клааса перекрыт NewInstance - что делать? Вс равно в стеке выделять память? А не порушится ничего из-за этого?
oxffff © (12.03.07 1:10) [41]
Вообщем не смешаете вы таким образом Stack и Ref семантику
+1 :-)

← →
euru © (2007-03-12 01:19) [43]

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

← →
oxffff © (2007-03-12 01:21) [44]

> jack128 © (12.03.07 01:16) [42]
> oxffff © (12.03.07 0:52) [35]
> Ancestor list - это опечатка.
> Или баг в реализации компилира ;-)

> С++ решаются конфликты имен при множественном наследовании

Нет пусть будет одиночное наследование, abstract base class пусть останется С++.
:)

← →
Юрий Зотов © (2007-03-12 01:22) [45]

> oxffff © (12.03.07 01:03) [39]

> Конструктор вызывает classCreate

Нет. Сам по себе - не вызывает. Код вызова classCreate вставляет компилятор в пролог конструктора, если тот был вызван, как классовый метод (и не вставляет, если как обычный).

> у конструктора должна быть информация выделять память или нет

Зачем? Пусть все остается, как есть. Просто компилятор при входе в область видимости static-переменной сам вызовет конструктор, как классовый метод - и память будет выделена. Соответственно при выходе их этой области компилятор сам вставит вызов Free - и память будет освобождена.

Впрочем, есть и совсем простой вариант - сразу выделить память под static-объект не в хипе, а в основной области.

> Static "переменной вы ничего не присвоите

Само собой. Но почему бы компилятору это не контролировать? Он же контролирует присвоение констант, а это то же самое.

← →
oxffff © (2007-03-12 01:24) [46]

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

Достоинство record в его light in weight.
Конструктору по умолчанию и отсутствии деструктора.

← →
oxffff © (2007-03-12 01:31) [47]

> Нет. Сам по себе - не вызывает. Код вызова classCreate вставляет
> компилятор в пролог конструктора, если тот был вызван, как
> классовый метод (и не вставляет, если как обычный).

dl влияет на вызов ClassCreate и на AfterConstruction.

> > у конструктора должна быть информация выделять память
> или нет
>
> Зачем? Пусть все остается, как есть. Просто компилятор при
> входе в область видимости static-переменной сам вызовет
> конструктор, как классовый метод - и память будет выделена.
> Соответственно при выходе их этой области компилятор сам
> вставит вызов Free - и память будет освобождена.

Какой конструктор? По умолчанию? Удобно? Нет.

>Впрочем, есть и совсем простой вариант - сразу выделить память под >static-объект не в хипе, а в основной области.

Если переменная глобальна, то просто.
А если локальна, как определить достижимость метода в котором объявлена.

Скажите если ли в этом смысл.

← →
GrayFace © (2007-03-12 01:34) [48]

oxffff © (12.03.07 0:26) [22]
Зачем так усложнять. Перегружаешь NewInstance и FreeInstance.
В куче выделяешь псевдо стек. И свой esp в переменной.
Зачем так усложнять?
type TMyObj = class(TObject) protected class function NewInstance: TObject; override; procedure FreeInstance; override; public constructor Create(Address:Pointer); end; constructor TMyObj.Create(Address: Pointer); begin end; procedure TMyObj.FreeInstance; begin CleanupInstance; end; class function TMyObj.NewInstance: TObject; asm mov edx, ecx call InitInstance end;
Только при наследовании от такого класса надо сохранять Address первым аргументом.

← →
oxffff © (2007-03-12 01:35) [49]

> > Static "переменной вы ничего не присвоите

Более того ее саму будет опасность присваивать.
Потому, что приемник не будет знать как она выделена.
Да и семаника будет Ref и value.

← →
oxffff © (2007-03-12 01:38) [50]

> GrayFace © (12.03.07 01:34) [48]
> oxffff © (12.03.07 0:26) [22]
> Зачем так усложнять. Перегружаешь NewInstance и FreeInstance.
>
> В куче выделяешь псевдо стек. И свой esp в переменной.
> Зачем так усложнять?
> type
> TMyObj = class(TObject)
> protected
> class function NewInstance: TObject; override;
> procedure FreeInstance; override;
> public
> constructor Create(Address:Pointer);
> end;
>
> constructor TMyObj.Create(Address: Pointer);
> begin
> end;
>
> procedure TMyObj.FreeInstance;
> begin
> CleanupInstance;
> end;
>
> class function TMyObj.NewInstance: TObject;
> asm
> mov edx, ecx
> call InitInstance
> end;
> Только при наследовании от такого класса надо сохранять
> Address первым аргументом.

Ну. Ну.
Только не забудьте в конструктор передать адресс экземпляра.

← →
jack128 © (2007-03-12 01:38) [51]

oxffff © (12.03.07 1:24) [46]
отсутствии деструктора.
есть. И конструкторы и деструкторы. Называются _InitializeRecord и _FinalizeRecord соответственно. Говорят в qc просят возможность их переопределить

← →
jack128 © (2007-03-12 01:40) [52]

jack128 © (12.03.07 1:38) [51]
Говорят, в qc просят дать возможность их переопределять

← →
oxffff © (2007-03-12 01:40) [53]

> > constructor Create(Address:Pointer);

Не заметил.
Ну наверно с псевдостеком и псевдо esp. Будет проще и выразительней.

← →
oxffff © (2007-03-12 01:45) [54]

> _InitializeRecord и _FinalizeRecord соответственно

Это очень полезные compiler magic функции и не только для record. и для класса(TObject.CleanupInstance) и для всех локальных переменных Посмотрите еще есть _FinalizeArray

Соотвественно о деструкторе в record

Records are constructed automatically, using a default no-argument constructor, but classes must be explicitly constructed. Because records have a default no-argument constructor, any user-defined record constructor must have one or more parameters.
Record types cannot have destructors.

← →
GrayFace © (2007-03-12 01:52) [55]

euru © (12.03.07 1:19) [43]
Я до сих пор не могу понять, какие проблемы может вызвать наличие у рекорда возможностей наследования и виртуальных функций?
Под виртуальные функции надо VMT инициализировать, хотя переменнные с счетчиками ссылок инициализируются нулями и ничего. Наследование - сам не понимаю, почему его в C# запретили.

oxffff © (12.03.07 1:40) [53]
Ну наверно с псевдостеком и псевдо esp. Будет проще и выразительней.
Псевдостек - это что? Это чем-то отличается от кучи?

← →
oxffff © (2007-03-12 01:55) [56]

> Псевдостек - это что? Это чем-то отличается от кучи?

Аналог работы с регистром ESP. Только память уже выделана.
Что быстрее Getmem(a,100) или sub esp,100? :)

← →
oxffff © (2007-03-12 01:56) [57]

Пора спать. Всем спокойной ночи.

← →
euru © (2007-03-12 02:02) [58]

> oxffff © (12.03.07 01:24) [46]
> Достоинство record в его light in weight. Конструктору по
> умолчанию и отсутствии деструктора.
Так у object всё это было.

← →
euru © (2007-03-12 02:06) [59]

> GrayFace © (12.03.07 01:52) [55]
> Под виртуальные функции надо VMT инициализировать, хотя
> переменнные с счетчиками ссылок инициализируются нулями
> и ничего.
Но ведь работало же это всё с типами object в TurboPascal, начиная с версии 5.5. Мне что-то нигде не встречалась информация о концептуальной неправильности такого подхода.

← →
GrayFace © (2007-03-12 02:29) [60]

oxffff © (12.03.07 1:55) [56]
Аналог работы с регистром ESP.
Как ты себе это представляешь? Если бы это было так просто, GetMem работал бы именно так.

euru © (12.03.07 2:06) [59]
Но ведь работало же это всё с типами object в TurboPascal, начиная с версии 5.5. Мне что-то нигде не встречалась информация о концептуальной неправильности такого подхода.
Да я тоже в этом ничего страшного не вижу.

Юрий Зотов © (12.03.07 0:22) [21]
var
MyClass: TMyClass; static;
Плохо то, что первые 4 байта всегда будут забиты. Деструктор всегда есть, значит при объявлении такого объекта в локальной переменной компилятор обязан будет создать try..finally с вызовом деструктора, который, может быть, совсем не нужен.

← →
jack128 © (2007-03-12 10:19) [61]

GrayFace © (12.03.07 2:29) [60]
который, может быть, совсем не нужен.
всегда нужен. Еще раз, деструкторы вызваются для всех записей, и в этом смысле классы ничем не отличаются от записей. Единственная разница, что у классов деструктор должен быть виртуальный, а у записей - он статический.

← →
oxffff © (2007-03-12 10:22) [62]

> Как ты себе это представляешь? Если бы это было так просто,
> GetMem работал бы именно так.

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

← →
oxffff © (2007-03-12 10:23) [63]

> Еще раз, деструкторы вызваются для всех записей, и в этом
> смысле классы ничем не отличаются от записей

В классическом понимании нет.
oxffff © (12.03.07 01:45) [54]

← →
jack128 © (2007-03-12 10:26) [64]

oxffff © (12.03.07 10:23) [63]
В классическом понимании нет.
ой, да ладно. Для освобождения ресурсов связанных с записями и объектами вызвается некий код. Как он называется - дело десятое, в общем то...

← →
oxffff © (2007-03-12 10:28) [65]

У записи нет деструктора. Компилятор финализирует записи, объекты, набор переменных для типов.
tkVariant
tkArray:
tkRecord:
tkInterface:
tkDynArray:

Смотри здесь ничего нет про классы.

← →
Игорь Шевченко © (2007-03-12 10:30) [66]

Юрий Зотов © (12.03.07 00:50) [34]

SaveToFile документирован разрабтчиком класса TMemoStrings, вообще-то. Если не трудно, почитай соседнюю ветку, чтобы мне два раза не писать одно и то же

← →
oxffff © (2007-03-12 10:31) [67]

> ой, да ладно.

Это не декструтор.
Посмотри _FinalizeArray вызывается и для объектов, набора переменных, записи. Это универсальный псевдо-деструктор, который освобождает ресурсы встроенных типов.

← →
oxffff © (2007-03-12 10:35) [68]

> oxffff © (12.03.07 10:22) [62]
>
> > Как ты себе это представляешь? Если бы это было так просто,
>
> > GetMem работал бы именно так.
>
> Представляю себе нормально.
> Посмотри как выделяется память для локальных переменных.
>
> Реализуй тот же подход, используя предвыделенный объект
> памяти в куче.

предвыделенный объект = кусок памяти >1МВ

← →
REA (2007-03-12 10:46) [69]

Тогда давайте сделаем вcе классами:

s := (x.sin * y.cos).ToStr;

И class helper-ы еще чтобы дописывать чужие классы без наследования.

← →
euru © (2007-03-12 11:28) [70]

> REA (12.03.07 10:46) [69]
А что в этом выражении крамольного? (То, что это не будет работать в текущих версиях Delphi, я знаю.)

← →
oxffff © (2007-03-12 12:06) [71]

> euru © (12.03.07 11:28) [70]
>
> > REA (12.03.07 10:46) [69]
> А что в этом выражении крамольного? (То, что это не будет
> работать в текущих версиях Delphi, я знаю.)

Торопитесь.

SingleWrapper=packed record
value:Single;
function Sin:SingleWrapper;
function Cos:SingleWrapper;
function ToStr:string;
constructor create(Value:single);
class operator Multiply(a,b:SingleWrapper):SingleWrapper;
end;

{ SingleWrapper }

function SingleWrapper.Cos: SingleWrapper;
begin
Result.value:=System.cos(value);
end;

constructor SingleWrapper.create(Value: single);
begin
self.value:=Value;
end;

class operator SingleWrapper.Multiply(a, b: SingleWrapper): SingleWrapper;
begin
Result.value:=a.value*b.value;
end;

function SingleWrapper.Sin: SingleWrapper;
begin
Result.value:=System.sin(value);
end;

function SingleWrapper.ToStr: string;
begin
result:=FloatToStr(value);
end;

procedure TForm1.Button1Click(Sender: TObject);
var x,y:SingleWrapper;
s:string;
begin
x.create(1);
y.create(2);
s:=(x.Sin*y.Cos).ToStr;
showmessage(s);
end;

← →
Юрий Зотов © (2007-03-12 12:07) [72]

> Игорь Шевченко © (12.03.07 10:30) [66]

Игорь, я читал. Согласен с мнением, что, уж если я использую чью-либо библиотеку/модуль, то, соответственно, должен ее освоить. То есть, разработчик должен ее каким-то образом документировать, а я должен эту документацию изучить. Чтобы и использовать ее грамотно, и не падать в обморок от Memo.Lines.DoWork.

Собственно, то же самое относится и к VCL.

← →
euru © (2007-03-12 12:23) [73]

> oxffff © (12.03.07 12:06) [71]

:) Точно. Поторопился. Но меня больше интересовал вопрос, что крамольного, если такую возможность будет поддерживать компилятор.

Что-то типа

var x, y: Double; s: String; begin s := (sin(x) * cos(y)).ToString; end;

← →
Аноним (2007-03-12 12:27) [74]

Memo1.Lines.AddFmt("Позиция номер %d", [i]);

Вариантов избежать обморока совсем никаких?

Юрий Зотов © (12.03.07 12:07) [72]

> Собственно, то же самое относится и к VCL.

Только что к VCL уже все написано, и ожидаешь от встреченных в коде мест использования VCL штатного и описанного поведения. А то десять разработчиков напишут двадцать хелперов, половина из них в школе албанский изучало вместо английского, и будут методы Memo.Lines.DelayWork

Нафиг такое счастье

> Игорь Шевченко © (12.03.07 12:32) [75]

1. Игорь, ты используешь хоть какие-нибудь сторонние библиотеки?

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

2. Ты доверяешь тем библиотекам, которые используешь?

Вероятно, тоже да. Иначе бы не использовал.

3. Ты знакомишься с документацией (хелпами, исходниками и т.д.) к этим библиотекам?

Вероятно, тоже да. Иначе не смог бы их использовать.

4. Ты не удивляешься тому, что в какой-то библиотеке некий класс наследуется от стандартного, но при этом модифицирует или расширяет поведение предка?

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

5. Ты смотришь в документации (хелпах, исходниках и т.д.), что именно, как именно и для чего именно этот класс-наследник модифицирует/расширяет?

Вероятно смотришь. Чтобы использовать осмысленно и грамотно.

6. Ты НЕ используешь библиотеки, которым НЕ доверяешь?

Вероятно, нет. Потому что это опасно. Глюков хватает и без того.

===============================

Теперь совершенно стандартная ситуация: ты нуждаешься в некоем функционале. Ты нашел библиотеку, которая его реализует. Ты посмотрел ее код, ее документацию и увидел, что все это написано грамотно (или неграмотно) и доверять авторам можно (или нельзя). Цена библиотеки и качество ее поддержки тебя тоже вполне устраивают (или не устраивают). И в итоге ты принял решение, что будешь (или не будешь) ее использовать.

Теперь скажи - что меняется от того, есть ли в этой библиотеке хелперы, или их нет?

Ни-че-го. Спор, извини, ни о чем.

А албанский имеет отношение к ламерам, а не к хелперам. Между собой же эти два понятия НИКАК не связаны. Не передергивай, пожалуйста.

Юрий Зотов © (12.03.07 13:01) [76]

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

> А албанский имеет отношение к ламерам, а не к хелперам.
> Между собой же эти два понятия НИКАК не связаны. Не передергивай,
> пожалуйста.

А я не передергиваю. Какой человеческий материал имеется, с тем и приходится работать.

> Игорь Шевченко © (12.03.07 13:08) [77]

> Я вижу, что пишут люди.

Очевидно, люди бывают разные.

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

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

> А я не передергиваю. Какой человеческий материал имеется, с тем и
> приходится работать.

Очевидно, хелперы тут все же ни при чем. Ну не виноваты они в твоем человеческом материале, чего ты на них так взъелся?

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

==========================

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

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

Странно как-то.

Ты извини, но спор я прекращаю. Просто не вижу предмета.

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

Юрий Зотов © (12.03.07 13:25) [78]

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

Ну не вижу я удобства. Неудобство вижу - код становится более неочевидным, пример неочевидного кода показал Jack128

Сами Борланды пишут, что не следует использовать это средство для дизайна.

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

А если я захочу написать
a:=TMyClass.Create; b:=TMyClass.Create; a.Destroy; b.Destroy;
Твой подход не сможет освободить память.
А еще огромное достоинство record-ов - возможность поместить в массив, другой record и т.п. У тебя этой возможности не будет. И передаваться объект будет по ссылке (как, правда, и в моем коде). В общем никаких отличий, от теперешнего class"а.

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

2Юра Зотов по поводу примера с TObject; static;
А как ты будешь данный статик указывать для результата функции?
Т.е. если и делать на базе классов, то это статичность нужно указывать не в месте использования данного класса, а в декларации класса.

еще

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

to Суслик © (12.03.07 19:57) [84]:
>вы бы устраивали такие войны в новостных группах CodeGear"а - тогда бы
>хоть знали, что в россии люди оказывается живут, да еще со своим
>мнением.

Дим, для устраивания войн там, не у всех тут хватает знания английского. У меня, вот, не хватает. Не, читать-то я могу...

> [85] vuk © (12.03.07 20:16)
>
> Дим, для устраивания войн там, не у всех тут хватает знания
> английского. У меня, вот, не хватает. Не, читать-то я могу...

За пользы дельфи куда больше будет! :)

ЗЫ У меня английский тоже фиговый. Меньше эмоция, больше прагматизма.

> А если я захочу написать
> a:=TMyClass.Create;
> b:=TMyClass.Create;
> a.Destroy;
> b.Destroy;
> Твой подход не сможет освободить память.

С чего ты взял.
Переопредели NewInstance и FreeInstance.
И то и другое гарантированно вызывается в твоем коде.

oxffff © (12.03.07 20:21) [87]
Переопредели NewInstance и FreeInstance.
И то и другое гарантированно вызывается в твоем коде.
Я не о NewInstance и FreeInstance, а о псевдостеке. Не получится, чтобы после этих нехитрых действий псевдоESP равнялся исходному. Или я что-но не понимаю в твоей идее?

> Не получится, чтобы после этих нехитрых действий псевдоESP
> равнялся исходному. Или я что-но не понимаю в твоей идее?
>

Именно так.

to Суслик © (12.03.07 20:21) [88]:
>Ты, кстати, репорты вполне нормально пишешь. Очень даже понятно о чем
>написано.
Знаешь, репорты писать и в форуме общаться - это несколько разный уровень. В репортах я старался как можно меньше слов употребить. :))

> > Не получится, чтобы после этих нехитрых действий псевдоESP
>
> > равнялся исходному. Или я что-но не понимаю в твоей идее?
>
> >
>
>
> Именно так.

Правда разрушать нужно в обратной последовательности от создания.

oxffff © (12.03.07 22:05) [92]
Правда разрушать нужно в обратной последовательности от создания.
Ясно. Значит это исключительно аналог выделения в стеке и долгое время такой объект хранить нельзя. Смысла как-то не вижу.

Суслик © (12.03.07 19:57) [84]

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

Может лучше CodeGear сюда пригласить ? Поучаствовать...:)

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

В случае же с хелперами, я категорически против легализации этих костылей. Данная политика развития P++ мне крайне не нравится.

← →
Аноним (2007-03-13 10:06) [96]

> ZeroDivide ©

> позволяющие сделать одно и тоже, но разным синтаксисом.

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

Запретить! (что-нибудь из двух).

PS
Разруха - она в головах, костыли там же

← →
REA (2007-03-13 11:07) [97]

Неудобство функций в том, что их надо помнить. В случае с helper-ом можно было бы нажать точку (или F1) и получить список с описанием всех функций, применимых к данному типу (не только записи).
Еще удобнее все делать классами, но этого производительнольность процессоров (устройство памяти и т.д.) пока не позволяет. Тут правда встает вопросик - что делать с функциями, которые имеют на входе несколько типов?

> REA (13.03.07 11:07) [97]
> Еще удобнее все делать классами, но этого производительнольность
> процессоров (устройство памяти и т.д.) пока не позволяет.
А как же Java, C#, в которых только классы?

← →
REA (2007-03-13 13:37) [99]

Java работает неторопливо, а C# видимо неплохой язык, но опять же не уверен, что на больших объемах информации обработка обычных типов и классов покажет сравнимые характеристики по скорости и объему памяти.

> REA (13.03.07 13:37) [99]
не уверен -- не говори.

Разместили
Feature Matrix для 2007 WIN32

http://www.codegear.com/LinkClick.aspx?fileticket=i0Upr%2fSmdsc%3d&tabid=236&mid=808

← →
REA (2007-03-14 11:15) [102]

Насколько я понял в C# все такие обычные типы есть, а не все классы

REA (14.03.07 11:15) [102]

Все классы. Все растут от System.Object

← →
REA (2007-03-14 11:51) [104]

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

> [101] oxffff © (13.03.07 23:07)
> Разместили
> Feature Matrix для 2007 WIN32
>
> http://www.codegear.com/LinkClick.aspx?fileticket=i0Upr%2fSmdsc%3d&tabid=236&mid=808

вроде ничего не забыли :)
все сказали

Серьезные ребята :)
Да и уже постарели на два года
http://dn.codegear.com/article/33109

Встречаем Record Helper Найти похожие ветки