Кто-нибудь сможет сходу определить причину ошибки? :)

← →
SergP. (2004-10-05 09:46) [40]

> [37] SergP. (05.10.04 09:35)

Все-таки я ошибся.
Такой код:

ArrayEdit[0] := TEdit.Create(self);
with ArrayEdit[0] do Parent := self;

Работает.
Значит причина ошибки та что была уже неоднократно высказана.

← →
Гаврила © (2004-10-05 10:44) [41]

Забавно
я, честно говоря, думал, что with отметается еще на этапе синтаксического разбора, оказывается нет

← →
DiamondShark © (2004-10-05 11:42) [42]

> Ведь with не что иное как просто упрощения записи, чтобы
> было понятнее.

Ничего подобного.

> P.S. Сейчас мне кто-нибудь точно припомнит IS :)))

Ну, ты в курсе.

← →
Piter(Ne doma) (2004-10-05 12:13) [43]

Корень ошибки - в упорном нежелании обращать внимание на хинты и варнинги компилятора

никаких предупреждение компилятор НЕ ПИШЕТ

← →
GuAV © (2004-10-05 12:30) [44]

> я, честно говоря, думал, что with отметается еще на этапе
> синтаксического разбора, оказывается нет

Иногда отметается иногда нет см. примеры в [0]

Кстати, я обычно стараюсь не писать такое with которое будет отметено. т.е. with ArrayEdit[0] do напишу, а with Edit do заменю на Edit.* ; Edit.* ; ...

> Зы. странно, что борланды вообще такую конструкцию считают
> синтастически допустимой...

О чём это Вы ?

← →
Суслик © (2004-10-05 12:36) [45]

смерть with.
я перестал его использовать еще на досе когда писал - пока не жалею.

← →
1008 © (2004-10-05 12:38) [46]

Суслик © (05.10.04 12:36) [45]

иногда бывает удобно

← →
Суслик © (2004-10-05 12:42) [47]

> иногда бывает удобно

не будем начинать холи вор, поэтому соглашусь:))
но я не пользуюсь.

← →
Sandman25 © (2004-10-05 12:44) [48]

[47] Суслик © (05.10.04 12:42)

Нет, надо было ответить: "Мне всегда неудобно". И никто оспорить не сможет :)

← →
вразлет © (2004-10-05 12:45) [49]

-Скажите, а ваучер это ценная бумага?
-В жизни каждого человека бывает минуты, когда любая бумажка становится очень ценной(с)

← →
DiamondShark © (2004-10-05 13:17) [50]

> Суслик © (05.10.04 12:36) [45]
> смерть with.

Смерть ламерам.

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

И это правильно. Чего не понимаешь -- лучше не использовать.

← →
GuAV © (2004-10-05 13:25) [51]

> Смерть ламерам.

Не скажите. Без with всегда можно обойтись
var A: TMyStrucType; begin with A do begin B; C; end;можно заменить на
begin A.B; A.C;А конструкцию типа
begin with TmyType.Create do begin B; C; end;заменить на
var localvar: TmyType; begin localvar:=TmyType.Create; localvar.B; localvar.C;

Эти замены будут чисто синтаксическими и не влияют на результат компиляции.
Лучше не использовать with чем ошибочно его применять.

← →
Игорь Шевченко © (2004-10-05 13:29) [52]

GuAV © (05.10.04 13:25) [51]

> Без with всегда можно обойтись

Можно. Но не всегда удобно. Пример в студии

var PrefilterExpressionValue: string; .... with FPrefilterClass.Create(AOwner) do try Mr := ShowModal; if Mr = mrOk then PrefilterExpressionValue := PrefilterExpression; finally Free; end;

← →
jack128 © (2004-10-05 13:38) [53]

> Без with всегда можно обойтись
всегда можно обойтись без Exit, Break, параметров по умолчанию, циклов for/repeat, без классов/объектов в конце концов ;-)

> Лучше не использовать with чем ошибочно его применять.
ну так это относиться не только к with ;-)

← →
KSergey © (2004-10-05 13:40) [54]

> [52] Игорь Шевченко © (05.10.04 13:29)

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

with FPrefilterClass.Create(nil) do

Все равно есть явный код уничтожения, так стоит ли лишний раз назначать родителя (которому будет слаться уведомление при создании/разрушении)?

← →
KSergey © (2004-10-05 13:41) [55]

Не родителя - owner"а (владельца), конечно

← →
Игорь Шевченко © (2004-10-05 13:59) [56]

KSergey © (05.10.04 13:40) [54]

> так стоит ли лишний раз назначать владельца

Стоит, как минимум, если в создаваемом классе имеется явное или неявное обращение к свойствам/метолам владельца.

← →
DiamondShark © (2004-10-05 14:12) [57]

> Стоит, как минимум, если в создаваемом классе имеется явное
> или неявное обращение к свойствам/метолам владельца.

Тогда этот класс не должен допускать параметр nil в конструкторе.

← →
Суслик © (2004-10-05 14:12) [58]

> [50] DiamondShark © (05.10.04 13:17)

> Смерть ламерам.

в своем стиле :))) Я тебе лично что-то сказал, или with твой близкий родственник?

Для меня лично with уменьшает наглядность кода. А т.к. у меня его (кода) много (порядка 1млн строк), то этот факт для меня весьма критичен. Есть моменты, когда я могу его использовать. Но они чрезвычайно редки.

← →
Игорь Шевченко © (2004-10-05 14:14) [59]

DiamondShark © (05.10.04 14:12) [57]

> Тогда этот класс не должен допускать параметр nil в конструкторе.

В этом случае может действовать поведение по умолчанию. Все зависит от задачи.

← →
KSergey © (2004-10-05 14:23) [60]

> [56] Игорь Шевченко © (05.10.04 13:59)
> Стоит, как минимум, если в создаваемом классе имеется явное
> или неявное обращение к свойствам/метолам владельца.

Вы меняете условия ;) По сути задаете такие, где это необходимо, что не имеет никакого отношения к эффективности ;)
К стати, о неявном: что-то на ум ничего не приходит...

← →
Игорь Шевченко © (2004-10-05 14:27) [61]

KSergey © (05.10.04 14:23) [60]

> Вы меняете условия ;) По сути задаете такие, где это необходимо,
> что не имеет никакого отношения к эффективности ;)

А о какой эффективности может идти речь в этом случае ? :)

> К стати, о неявном: что-то на ум ничего не приходит...

procedure TWinControl.CreateWnd;
....
if (WndParent = 0) and (Style and WS_CHILD <> 0) then
if (Owner <> nil) and (csReading in Owner.ComponentState) and
(Owner is TWinControl) then
WndParent := TWinControl(Owner).Handle
else
raise EInvalidOperation.CreateFmt(SParentRequired, [Name]);

:))

← →
KSergey © (2004-10-05 14:35) [62]

> [61] Игорь Шевченко © (05.10.04 14:27)

Ну в приведенном коде вполне допустима ситуация, когда nil. Хотя согласен, по сути оно.

> [61] Игорь Шевченко © (05.10.04 14:27)
> А о какой эффективности может идти речь в этом случае ?

constructor TComponent.Create(AOwner: TComponent); begin FComponentStyle := [csInheritable]; if AOwner <> nil then AOwner.InsertComponent(Self); end;

Ну и ответная часть в деструкторах.
В коде

> [52] Игорь Шевченко © (05.10.04 13:29)

я не вижу смысла в Owner как таковом, а потому выполнение выделенного участока кода считаю никчемным кроме случаем, когда это необходимо по каким-либо (признаюсь, редко, на мой взгляд, встречающимся) причинам. Хотя предлагаю не спорить о самих причинах, их частоте возникновения и т.п. - это лишь от ситуации зависит, согласитесь, однако, думаю, вы так же согласитесь, что имеет смысл писать тут nil, когда нет явной необходимости в обратном, при этом nil сэкономит нам несколько машинных тактов ;)

← →
Игорь Шевченко © (2004-10-05 15:11) [63]

KSergey © (05.10.04 14:35) [62]

> В коде
>
> > [52] Игорь Шевченко © (05.10.04 13:29)
>
> я не вижу смысла в Owner как таковом

Потому что ты не видишь код создаваемого класса :)

> > А о какой эффективности может идти речь в этом случае
> ?
>
> constructor TComponent.Create(AOwner: TComponent);
> begin
> FComponentStyle := [csInheritable];
> if AOwner <> nil then AOwner.InsertComponent(Self);
> end;

Все равно, не понимаю, о какой эффективности идет речь.

← →
KSergey © (2004-10-05 15:20) [64]

О повышении быстродействия. Или это не эффективность? Может я термины неудачные применяю?

← →
Anatoly Podgoretsky © (2004-10-05 15:42) [65]

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

← →
Игорь Шевченко © (2004-10-05 15:44) [66]

KSergey © (05.10.04 15:20) [64]

> О повышении быстродействия.

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

← →
Anatoly Podgoretsky © (2004-10-05 15:45) [67]

Игорь Шевченко © (05.10.04 15:44) [66]
А оно вообще не имеет отношения к быстродействию :-)

← →
Игорь Шевченко © (2004-10-05 15:49) [68]

Anatoly Podgoretsky © (05.10.04 15:45) [67]

Насколько я понимаю, предлагается повышение быстродействия за счет исключения вызова метода InsertComponent (и RemoveComponent, соответственно).

[66] Игорь Шевченко © (05.10.04 15:44)

Создается процедура. По умолчанию она без параметров. Если понадобился параметр, он добавляется в определение и вызов. Никто не описывает процедуру с 10 параметрами, которые никогда не понадобятся.

Имеем метод с обязательным параметром, который в конкретном случае не нужен. Зачем передавать что-нибудь кроме nil? Зачем замедлять работу программу добавлением/удалением контрола в/из список?

[67] Anatoly Podgoretsky © (05.10.04 15:45)

Ненужные действия замедляют работу. Особенно если они совершаются в цикле.

> Ненужные действия замедляют работу. Особенно если они совершаются
> в цикле.

:)))
О замедлении можно говорить в одном случае - когда проведен опыт "до" и "после" с замерами и с решением о том важно ли быстродействие в данном конкретном случае или нет.

> [71] Sandman25 © (05.10.04 15:57)

> всегда будет медленнее чем

Медленнее и чудовищно медленнее разные вещи.

"Медленнее" не важно в большинстве случаев.

"Чудовищно медленнее" важно почти всегда.

При каком замедлении ставить эпитет "чудовищно" каждый решает сам (или за него реает начальник). Все зависит от ситуации. Чаще твое личное время важнее и дороже.

Sandman25 © (05.10.04 15:49) [69]

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

А кто сказал, что он не нужен ?

> Ненужные действия замедляют работу. Особенно если они совершаются
> в цикле.

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

[72] Суслик © (05.10.04 16:15)

Я считаю, что для того, чтобы программист сделал неоптимально, всегда должна быть причина. Делать медленнее, чем можешь, только потому, что будет не намного медленнее, могуть только саботажники.

PS. "Я сделал медленнее, потому что привык передавать параметром форму" или "потому что в будущем может понадобиться обратиться к методу владельца" - причины.

PPS. "nil" - короче, чем "MyForm" :)

[73] Игорь Шевченко © (05.10.04 16:18)

Я понимаю, что в данном случае следует указывать конкретный параметр. Меня удивляет Ваше нежелание признать, что очень часто лучше указывать именно nil.

> [74] Sandman25 © (05.10.04 16:22)

А я считаю, что все зависит от условий и целей работы.

Оптимизировать нужно только критичные места. Зачастую наглядность кода важнее оптимальности. Чем важнее? Да все тем же - деньгами: замеление на 23 мс не заметит никто, а ты, возможно допустивный в будущем при модификации ошибку по причине недопонимания заоптимизированного по самы помидоры кода, принесешь конторе определенный убыток. Пусть и не большой, но убыток - лишний потраченный час (блин, что я сейчас делаю :))) есть деньга...

[76] Суслик © (05.10.04 16:26)

Не об оптимизации разговор. Грубо говоря, чтобы написать
A := 1;
B := 2;
A := 2;
нужна причина. Кодер тратит время на написание третьей строки, потом другой кодер полчаса пытается понять, в чем же причина того, что третья строка была написана, потом третий кодер матерится, когда видит количество лишних строк, разбросанных по всему модулю...
Резюме: для ухудшения кода должна быть причина. Под ухудшением понимаем все, что угодно - от ненаглядности до глюкавости.

PS. Что аналогия некорректна, я понимаю.

[78] Суслик © (05.10.04 16:34)

Боюсь, что и Игорь Шевченко тоже не понял, почему я написал свой пост.

1. Передача не nil в конструктор компонента замедляет работу.
2. Исходя из пункта 1, кодер вправе рассчитывать, что есть какая-то причина, почему передается не nil. Особенно, если учесть, что в качестве параметра можно передать все, что угодно, начиная от Application и заканчивая AnotherForm.HiddenButton.

Sandman25 © (05.10.04 16:38) [79]
Если с тобой согласиться, то придется делать двойной комплект методов, с параметром и без. Вот тут тебе прогнозирую резкое замедление производительности, на время написания, на время тестирования и навремя поиска потом ошибок в программе.
Механизм с одним методом гарантирует как единообразие, так и отсутствие возможных ошибок, где передали, где нет, а использовать пытались.
Перенос анализа на НИЛ из метода добавления в другие методы, к тому же вызовет заметное замедление работы других частей иерархии.

Кто-нибудь сможет сходу определить причину ошибки? :) Найти похожие ветки