По каким моментам кода вы понимаете

← →
Johnmen © (2004-12-21 12:10) [40]

>Fay © (21.12.04 12:02) [35]

А в чем фишка ? В чем глубина/хорошесть/etc ?

← →
Fay © (2004-12-21 12:12) [41]

2 Johnmen © (21.12.04 12:10) [40]
Я знал, что Вы откликнитесь 8). Мы уже обсуждали это, хватит.

← →
Sandman25 © (2004-12-21 12:12) [42]

[40] Johnmen © (21.12.04 12:10)

Ускорение, и неслабое. Особенно если в НД 1000 записей из 1000 полей.

← →
y-soft © (2004-12-21 12:12) [43]

Ну, млинн, пошло обсуждение по наезженной дорожке :)

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

← →
WondeRu © (2004-12-21 12:13) [44]

Sandman25 © (21.12.04 12:07) [38]
не все так просто в кородевстве датском:

case TMenuItem(Sender).Tag of HWT_OOO: AIValue := XXXX.000_List.Add; HWT_UUU: AIValue := XXXX.UUU_List.Add; .....
XXXX - COM-объект, притом не мой!

← →
Sandman25 © (2004-12-21 12:13) [45]

[43] y-soft © (21.12.04 12:12)

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

← →
Суслик © (2004-12-21 12:14) [46]

> [43] y-soft © (21.12.04 12:12)

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

золотые слова, чессо слово.

← →
Суслик © (2004-12-21 12:16) [47]

Экая панацея эти шаблоны проектирования :)))
Ринулся народ их использовать и к месту и нет :))

← →
Игорь Шевченко © (2004-12-21 12:16) [48]

msguns © (21.12.04 12:03) [36]

Да и вообще винды кривые, раз в них такие функции используются :)

С уважением,

← →
Val © (2004-12-21 12:16) [49]

>Fay&Sandman25
Коллеги, скорость и память частенько в разных углах, согласитесь - экономя на одном, теряеем в другом :)
Ну описали вы одно поле, а десяток?

← →
КаПиБаРа © (2004-12-21 12:17) [50]

y-soft © (21.12.04 12:12) [43]
Точно. Как дети ей богу :)

← →
Fay © (2004-12-21 12:17) [51]

2 Johnmen © (21.12.04 12:01) [31]
>> + если порядок полей изменился в силу каких-то причин, то переделка кода...
Вы это серьёзно? В открытом датасете?! "Порядок"?!!

← →
Johnmen © (2004-12-21 12:17) [52]

>Fay © (21.12.04 12:12) [41]
>Я знал, что Вы откликнитесь 8). Мы уже обсуждали это, хватит.

Ну, как хочешь...

>Sandman25 © (21.12.04 12:12) [42]
>Ускорение, и неслабое. Особенно если в НД 1000 записей из 1000 полей.

Давай будем реалистами и не будем говорить про 1000 полей.
А про 1000 записей интересны твои оценки неслабости :)

← →
y-soft © (2004-12-21 12:17) [53]

>Sandman25 © (21.12.04 12:13) [45]

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

← →
PVOzerski © (2004-12-21 12:18) [54]

Сомнения насчет опытности/профессионализма возникают, когда я вижу:
1) if something=true then;
2) практически повторяющиеся куски (которые так и просятся быть оформленными в процедуру) в разных местах;
3) обращения к конкретному экземпляру класса из метода этого класса (в общем случае).

← →
Val © (2004-12-21 12:19) [55]

>[42] Sandman25 © (21.12.04 12:12)
Это уже конкретика, в зависимости от нее выбирается метод решения. Fay писал о презрении, ничего не конкретизируя - пустословие.

← →
Sandman25 © (2004-12-21 12:22) [56]

[44] WondeRu © (21.12.04 12:13)

Я бы сделал функцию (не метод, если не хочется делать объектную оболочку вокруг XXXX) GetInterfaceById(const Id: Integer): OleVariant;
и использовал AIValue := GetInterfaceById(TComponent(Sender).Tag).Add;
тогда в функции удаления не будем дублировать case, а напишем
GetInterfaceById(TComponent(Sender).Tag).Del;

и в любом случае лучше писать TComponent(Sender).Tag, чтобы не пришлось менять код при замене TMenuItem на TButton, TBitBtn или TSpeedButton

← →
Суслик © (2004-12-21 12:23) [57]

> Сомнения насчет опытности/профессионализма возникают, когда
> я вижу:
> 1) if something=true then;

Наблюдал ошибку компилятора, связанную с тем, что variant, содержищий, bool неверно приводился и код
if v then
работал как бы в v находится false. Находился true.
Поэтому, если работаю с variant, то часто пишу либо
if v=true then
либо
if boolean(v) then
В этом случае ошибок компиляции не наблюдал.

Так что - все зависит от контекста.

← →
Sandman25 © (2004-12-21 12:27) [58]

[52] Johnmen © (21.12.04 12:17)

В DataSet 20 полей, FieldByName вызывается 1 раз вместо 1000.
Происходит в среднем 10.000 лишних сравнений имен полей. Я это считаю недостатком, а автора кода - неопытным программистом (или опытным в запарке из-за deadline :-))

← →
y-soft © (2004-12-21 12:28) [59]

>PVOzerski © (21.12.04 12:18) [54]

Я бы добавил еще грамотное использование try..except и try..finally и предпроверку условий - "неопытные" обычно этим пренебрегают...

← →
PVOzerski © (2004-12-21 12:28) [60]

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

← →
Sandman25 © (2004-12-21 12:30) [61]

[59] y-soft © (21.12.04 12:28)

Точно.
"Скажи мне, используешь ли ты Assert и я скажу, кто ты" :)

← →
PVOzerski © (2004-12-21 12:33) [62]

Вот еще вопрос: оптимизируется ли такое на этапе компиляции?
for i:=1 to length(MyDynArray)do
MyDynArray[i-1]:=100;
Во всяком случае, я такого избегаю. А в чужом коде видывал.

← →
Суслик © (2004-12-21 12:34) [63]

> [60] PVOzerski © (21.12.04 12:28)

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

В том случае судя по cpu был именно глюк.

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

← →
07BB:080Dh (2004-12-21 12:36) [64]

Sandman25 © (21.12.04 12:07) [38]

то есть у меня обработчик

procedure TForm1.OnClick(Sender: TObject);
begin
{-------------------------------
обработка всего меню
--------------------------------}
end;

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

← →
PVOzerski © (2004-12-21 12:37) [65]

>Я бы добавил еще грамотное использование try..except и try.. finally
Тут еще и наличие большого опыта программирования в TurboPascal сказаться может :^)

← →
Sandman25 © (2004-12-21 12:42) [66]

[64] 07BB:080Dh (21.12.04 12:36)

Я уже писал. Используйте ApplicationEvents.OnMessage.

← →
Johnmen © (2004-12-21 12:45) [67]

>Sandman25 © (21.12.04 12:27) [58]
>Происходит в среднем 10.000 лишних сравнений имен полей.

И на что это влияет так, что "абсолютно недопустимо" ?

>Я это считаю недостатком, ...

Недостатком чего ?

← →
Sandman25 © (2004-12-21 12:48) [68]

[49] Val © (21.12.04 12:16)

Мне приходилось копировать поля из одного датасета в другой по имени. Использовался FindField, потому что полей могло и не быть, и динамический массив of TField, потому что число полей было неизвестно - 2 параметра TDataSet и все :)

И на что это влияет так, что "абсолютно недопустимо" ?
Это не моя цитата.

Недостатком чего ?
Решения поставленной задачи.

Суслик © (21.12.04 12:23) [57]
И возможно поимеешь две ошибки

if v=true then

True это константа и единственным определенным значение, а bool это множество значений, при том что поимеешь даже не предположение а истина, многие споткнулись на этом.

if boolean(v) then
В этом случае ошибок компиляции не наблюдал.

Да ошибок компиляции не будет, зато будут ошибки исполнения, поскольку обращаешься только к младщему байту.

А как вы относитесь к пунктуации и комментариям ?
Когда нет отступов либо они накиданы квадратно-гнездовым ? Так, что фиг поймещь, где начало блока, а где конец ? Или полное отсутствие комментариев ? Или, что еще хуже, такие комментарии:
TTable.Open; // Открытие таблицы

Или профи не юзают комменты, как крутые пачаны - презервативы ?

>msguns © (21.12.04 12:57) [72]

Или профи не юзают комменты, как крутые пачаны - презервативы ?

Юзают-юзают, только иногда странные и в неожиданных местах :)

Пойдет, но можно проверку на false
if v<>false
или {long}bool(v)<>false
или Ord(V) = 0

А том виде как предложено это является грубой ошибкой.

>[68] Sandman25 © (21.12.04 12:48)
Наверняка это было хорошим решением..но что это опровергает/доказывает? Врядли вам удалось использовать меньше памяти и при этом выиграть в скорости, не так ли? :)
Поймите, я не говорю что ваш метод плох, я говорю, что высказывание о методе, который я сейчас защищаю, было слишком радикальным, на мой взгляд.

Когда никуда не спешу и хочется написать максимально понятный код, пишу так:
if BoolVar then begin SomeCode1; for i := 0 to X do begin SomeCode2; SomeCode3; end; { for } end { if } else SomeCode4;

>Sandman25 © (21.12.04 12:50) [69]
>>И на что это влияет так, что "абсолютно недопустимо" ?
>Это не моя цитата.

Потому и в кавычках.
Хорошо, ставим вопрос по-другому. Что это даст ? Принципиального.

>>Недостатком чего ?
>Решения поставленной задачи.

Так в чем же всё-таки недостаток ?

Давай разбираться дальше. Я вот поднял сейчас help D6. Булевский тип, как явствует из него, в варианте должен содержаться как wordbool. Понятно, что если младший байт рассматривать как независимый boolean, он может оказаться и нулем при ненулевом старшем байте (откуда проследует ошибка). А вот что будет при попытке сравнить с, если в варианте вообще не булевское значение, а, например, NULL или 0? Вот такой пример выдал мне "+" (D6):

v:=null;
if v=false then
ShowMessage("-")
else
ShowMessage("+");

По каким моментам кода вы понимаете - профи или так... ? Найти похожие ветки