Я Написал Книжку по Делфи, хотел бы узнать Ваше мнение и отзывы

← →
asail © (2014-02-27 18:02) [360]

> Inovet © (27.02.14 17:52) [357]
> Да, самое главное забыл!!! Хочу, чтобы в Делфи можно было
> объявлять переменные везде.

Э, батенька... Бросайте вы эту дельфю и пополняйте армию сишников, а нас попрошу не трогать! :)

← →
clickmaker © (2014-02-27 18:06) [361]

> Хочу, чтобы в Делфи можно было объявлять переменные везде

так си-билдер вроде ж не отменили

← →
Inovet © (2014-02-27 18:10) [362]

Удалено модератором

← →
И.Я. Блямблин (2014-02-27 18:10) [363]

> А оба и реализованны. Читай классы TestClass1 и TestClass2
> реализуют интерфейсы TestCall и TestCall2.

Дык эти интерфейсы совершенно идентичны! Оба содержат один метод Test.
А давай я напишу пяток методов у каждого класса и начну их в процедурах вызывать по одному-два-три, да еще в процедурах (о ужас) с разными именами? У тебя вообще получается что эти объекты реализуют бесконечное множество инетрфейсов. Именовать не замучаешься?
От того что ты обозвал процедуру интерфейсом, (о котором объекты ни сном ни духом что они его реализуют) она интерфейсом не станет. Ибо написано: процедура.
И не надо пихать дельфийский код, там как раз при изменении интерфейса меняется объект, его реализующий. А тут сколько хошь процедур пиши - объекту до этого полиморфично, код-то его остается как был.

← →
asail © (2014-02-27 18:25) [364]

> Дык эти интерфейсы совершенно идентичны! Оба содержат один
> метод Test.

Ну и что? Хоть мульен идентичных интерфейсов будет... Никто не запрещает.
Кстати и в Д тоже:
type IMyIntf = interface procedure Test; end; IMyIntf2 = interface procedure Test; end; TMyClass = class(TInterfacedObject, IMyIntf, IMyIntf2) procedure Test; end;

> От того что ты обозвал процедуру интерфейсом, (о котором
> объекты ни сном ни духом что они его реализуют) она интерфейсом
> не станет. Ибо написано: процедура.

А я не виноват, что эти процедуры ведут себя именно как интерфейсы. И именно это их поведение и обеспечивает полиморфность метода Test для обоих классов (это я так, напоминаю контекст дискуссии).

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

Сам меняется? Не верю... :)

← →
И.Я. Блямблин (2014-02-27 18:54) [365]

> А я не виноват, что эти процедуры ведут себя именно как
> интерфейсы. И именно это их поведение и обеспечивает полиморфность
> метода Test для обоих классов (это я так, напоминаю контекст
> дискуссии).

Где ты встречал интерфейсы, которые вызывают методы? Эти сущности всегда назывались функциями.
Вот тебе еще примерчик, на питоне:
class Foo: def __init__(self): #constructor self.a = "foooo" class Bar: def test(self): #method print(self.a) def test(self): #function print(self.a) Foo.test = test def calltest(obj): obj.test() def main(): foo = Foo() bar = Bar() bar.a = "barrr!" calltest(foo) calltest(bar) test(bar) if __name__ == "__main__": main()
Печатает, понятно,
foooo
barrr!
barrr!
и ищи свои интерфейсы как хочешь :)
Вот ты вбил себе в голову что у интерфейса обязательно должно быть имя, и теперь тянешь за уши реальность.

← →
Дмитрий Белькевич (2014-02-27 19:35) [366]

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

Ни разу с ним проблем не было (я бы даже сказал - на редкость). Костыль? Не знаю. Не вижу смысла параноидально следить за тем, что бы double free не было.

[348]

a := b := c := d := 0;

не знаю даже, может быть и удобно...

тогда уже лучше что-то типа:

a, b, c, d := 0;

чё уж стеняться...

← →
Дмитрий Белькевич (2014-02-27 19:41) [367]

Кстати, именно FreeAndNil помогает глюки проявлять. Вот то, что я писал выше. Я понимаю, что все мега-гуру пишут софт уровня операционок на коленке без одной ошибки. Мы вот, простые смертные программисты пишем софт с ошибками и делаем всё возможное, что бы их было как можно меньше. И, как раз, FreeAndNil этому бывает сильно помогает. Это не считая других плюшек.

← →
Игорь Шевченко © (2014-02-27 21:27) [368]

Дмитрий Белькевич (27.02.14 19:41) [367]

> Я понимаю, что все мега-гуру пишут софт уровня операционок
> на коленке без одной ошибки.

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

← →
Rouse_ © (2014-02-27 21:44) [369]

> Игорь Шевченко © (27.02.14 21:27) [368]
> Мега-гуру пишут понятный код, в котором использование объектов
> очевидно и прозрачно. В том числе вызовы Free.

http://delphisorcery.blogspot.ru/2014/02/packages-and-initialization.html

← →
Rouse_ © (2014-02-27 21:54) [370]

> Игорь Шевченко © (27.02.14 18:02) [359]
> http://www.nickhodges.com/post/Using-FreeAndNil.aspx

После этого: "Setting a pointer to nil doesn’t get you anything." читать дальше бессмысленно.

← →
Romkin © (2014-02-27 22:22) [371]

Угумс.
“If your code requires you to use FreeAndNil to reveal and easily find bugs, then your design is wrong. Good, clean code never feels the need to worry about errant pointers.”

← →
Inovet © (2014-02-27 22:44) [372]

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

← →
Kerk © (2014-02-27 23:05) [373]

> Rouse_ © (27.02.14 21:44) [369]

Еще один пример кривого кода.

> Romkin © (27.02.14 22:22) [371]

+1
Больно смотреть на то, что людям вместо того, чтоб лишний раз подумать, проще понапихать везде FreeAndNil.

← →
Rouse__ (2014-02-27 23:14) [374]

Зачем писать глупости? :) Кривой код можно найти везде - зависит от подхода. Даже goto некоторыми апологетами чистоты языка применяется. А вот по поводу думать -согласен, только думать нужно правильно, чтобы понимать что freeandneel как и free абсолютно логичные конструкции при их правильном применении

← →
Kerk © (2014-02-27 23:18) [375]

> Rouse__ (27.02.14 23:14) [374]

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

← →
Rouse__ (2014-02-27 23:19) [376]

Впрочем истинным апологетам чистоты языка советую перейти от вызова Free напрямую к Destroy - ведь зачем вам нужны излишние затраты на проверке объекта с nil

← →
Kerk © (2014-02-27 23:20) [377]

Но вообще все эти разговоры про FreeAndNil поднадоели. Люди делятся на два типа: тех, кто знает о FreeAndNil и тех, кто пользуется ей всегда и всем советует. Это уже утомляет :)

Вот здесь я по этому поводу недавно высказывался, добавить нечего, ничего нового не придумал
http://programmingmindstream.blogspot.ru/2014/01/freeandnil.html?showComment=1389850400770#c8979317681113318928

← →
Rouse__ (2014-02-27 23:22) [378]

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

← →
Kerk © (2014-02-27 23:28) [379]

> Rouse__ (27.02.14 23:19) [376]
>
> Впрочем истинным апологетам чистоты языка советую перейти
> от вызова Free напрямую к Destroy - ведь зачем вам нужны
> излишние затраты на проверке объекта с nil

А вот это как раз легко объяснить:
TTestClass = class private FList: TStringList; public constructor Create; destructor Destroy; override; end; constructor TTestClass.Create; begin raise Exception.Create("Error Message"); FList := TStringList.Create; end; destructor TTestClass.Destroy; begin FList.Destroy; inherited; end;

При попытке создания этого класса будет 2 эксепшена. А если Destroy заменить на Free, то только один.

← →
Дмитрий Белькевич (2014-02-27 23:38) [380]

>Ну мы же взрослые люди, не будем пытаться закрывать уши ладошками и зажмуриваться вместо того, чтобы честно поймать свой эксепшен и НА САМОМ ДЕЛЕ РЕШИТЬ ПРОБЛЕМУ

Не знаю, почему FreeAndNil выдаётся за сокрытие экцепшнов. Они мне как раз помогают исключения "проявлять". Без них иногда случались обращения к разрушенным объектам (что, понятно, абсолютное зло). А вот с ними к разрушенным объектам обращаться не получается - потому как появляется AV, что и нужно.

← →
ухты (2014-02-27 23:38) [381]

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

← →
Дмитрий Белькевич (2014-02-27 23:48) [382]

>FreeAndNil такаяже процедура как и другие, чего в ней такого не такого?

Холивары они такие - бессмысленные и беспощадные :)

← →
Rouse__ (2014-02-27 23:48) [383]

Ром - это не чистый код, тыж сам чуть выше дал камент про кривой код :)

← →
ухты (2014-02-27 23:49) [384]

особенно assign, вот уж где странные процедуры :)

← →
картман © (2014-02-27 23:58) [385]

> Kerk © (27.02.14 23:20) [377]
> http://programmingmindstream.blogspot.ru/2014/01/freeandnil.
> html?showComment=1389850400770#c8979317681113318928

статья с надрывом

← →
Компромисс1 © (2014-02-28 00:02) [386]

Интересный спор.
FreeAndNil прячет ошибки повторного вызова деструктора, Free прячет ошибки обращения к уже удаленному объекта, Destroy не работает при исключении в конструкторе.
По-моему, оптимальным будет использование Free в деструкторе для удаления полей, и CheckedFreeAndNil (новый метод, который выдает исключение при nil параметре, иначе вызывая FreeAndNil) для всех остальных случаев.
Получим, что и поля нормально освобождаются, и все исключения видим.
Код типа
try obj := MyClass.Create; ... finally obj.Free end;

придется переделать на правильный код

obj := MyClass.Create; try ... finally CheckedFreeAndNil(obj); end;

← →
Дмитрий СС (2014-02-28 01:56) [387]

> Компромисс1 © (28.02.14 00:02) [386]

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

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

> [387] Дмитрий СС (28.02.14 01:56)
> Плохо что нет никакой директивы, которая бы обнуляла все
> локальные переменные перед вызовом - так было бы вдвое удобнее.

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

> [387] Дмитрий СС (28.02.14 01:56)
> Я первый код иногда использую, обNILивая переменные до try

Где в первом коде обниливание?

> CheckedFreeAndNil (новый метод, который выдает исключение
> при nil параметре

при nil параметре мы и так получим исключение выше, при 1-м обращении к объекту

← →
ухты (2014-02-28 10:17) [391]

даже в FreeAndNil есть полиморфизм, или опять не правильно?

> даже в FreeAndNil есть полиморфизм

он есть и IRL и даже на форумах ДМ

По поводу кода на VBS из [316]:
вполне переписывается на Delphi и без всяких сом (и интерфейсов):
program TestDisp; {$APPTYPE CONSOLE} uses SysUtils; const M_TEST = $0001; type TestClass1 = class public procedure Test(var Message: word); message M_TEST; end; TestClass2 = class public procedure Test(var Message: word); message M_TEST; end; { TestClass1 } procedure TestClass1.Test(var Message: word); begin writeln("TestClass1.Test"); end; { TestClass2 } procedure TestClass2.Test(var Message: word); begin writeln("TestClass2.Test"); end; procedure TestCall(Instance: TObject); var msg: word; begin msg := M_TEST; Instance.Dispatch(msg); end; var c1, c2: TObject; begin c1 := TestClass1.Create(); c2 := TestClass2.Create(); TestCall(c1); TestCall(c2); c1.Free; c2.Free; readln; end.

to Romkin © (28.02.14 13:47) [393]:

> вполне переписывается на Delphi и без всяких сом (и интерфейсов):

Я, собственно, уже писал тут, что обмен сообщениями и их обработка (да хоть в той же винде) тоже является способом реализации полиморфизма. А здесь использована именно что методика обработки сообщений.

Кстати, методы с модификатором message тоже являются подвидом виртуальных. Если быть точнее - динамических. Они живут в отдельной таблице методов, но просто динамическим методам коды в таблице назначает компилятор, а для привязанных к сообщениям - программист.

И да. методы, привязанные к оконным сообщениям появились еще в Borland Pascal. И модификатор тогда записывался в виде virtual MSG_ID Што кагбэ намекает. :)

← →
все она же (2014-02-28 15:26) [395]

Удалено модератором
Примечание: http://delphimaster.ru/forums.shtml#rule Запрещается: п.8

> при nil параметре мы и так получим исключение выше, при
> 1-м обращении к объекту

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

>Компромисс1 © (28.02.14 00:02) [386]
>FreeAndNil прячет ошибки повторного вызова деструктора, Free прячет ошибки обращения к уже удаленному объекта, Destroy не работает при исключении в конструкторе.
-------------------------------------
Не совсем (или даже совсем не) так.
1) при исключении в конструкторе Destroy вызовется сам.

2) Free НЕ прячет ошибки обращения к уже удаленному объекта.
Если объект разрушить (через Destroy или Free), но не обнулиь ссылку, то при ЛЮБОМ обращении получется неопределённое поведение (UB), которое частенько бывает трудно обнаружить. И никакой CheckedFreeAndNil тут не поможет.

3) FreeAndNil гарантирует, что после разрушения объекта ссылка на него чесно будет равна nil, и поэтому при обращении к объекту по этой ссылке вызовет гарантированый Acsess violation.

Естественно всё это работает, только если на объект есть только одна ссылка.

p.s. -В С++ delete нулевого указателя то же не приводит к ошибке.

icWasya © (28.02.14 17:40) [397]

Я именно об этом и писал - после вызова Free не всегда удается обнаружить обращения к уже удаленному обьекту, поэтому нужно обнуление.
Destroy после ошибки в конструкторе вызовется сам, но destroy полей (членов) сам не вызовется, поэтому в деструкторе придется писать myInnerObjectMember.Free или FreeAndNil(myInnerObjectMember).

← →
Дмитрий Белькевич (2014-02-28 23:40) [399]

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

Дело, конечно, каждого, но лично я не считаю multiple free ошибкой (при использовании FreeAndNil, само собой). Проверится, один раз разрушится, больше - нет.

Не вижу минусов в попытке повторного разрушения. Если кому-то такой подход кажется не достаточно чистым - в [386] хорошее решение, как говорится - и нашим и вашим :)

В CheckedFreeAndNil можно поднять исключение о multiple free. Кстати говоря - от multiple free использование free тоже не спасает. То есть free - наихудшее решение, не позволяющее обнаружить ни multiple free ни доступ к уже разрушенным объектам. Мне решение в 386 очень нравится, однако использовать не буду, пока устраивает freeandnil. И так знаю, что у меня в некоторых местах есть multiple free by desing.

Я Написал Книжку по Делфи, хотел бы узнать Ваше мнение и отзывы Найти похожие ветки