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

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

2Суслик © (21.12.04 17:52) [157]:
из Help к D6:
>A Boolean variable occupies one byte of memory
Sizeof(boolean) также возвращает 1. Таким образом, с точки зрения использования памяти/регистров для хранения boolean ничем не отличается от byte, разница только при компиляции операций с переменной (в т.ч. сравнения, and, or, pred, succ и т.п.). Что же тогда такое "преобразование идет иначе - сразу к boolean"?

← →
Sha © (2004-12-21 18:03) [161]

> Суслик ©

Идеологически :) правильнее сравнивать что-либо не с истиной, а с ложью.

Успехов.

← →
Суслик © (2004-12-21 18:06) [162]

> [159] Игорь Шевченко © (21.12.04 17:59)

> фетиша из Фаулера

Огромным усилием я заставил себя этого не делать:))).
А опастность была - увлекательно он пишет.
Про овощ согласен. Потому я и не фан такого подхода.

> [160] PVOzerski © (21.12.04 18:01)

Поизучай cpu. В частности VariantManager.
Поясняю:
1. Случай когда variant (256) -> byte -> boolean.
дельфи такую фишку проглатывает. Просто забивает на конструкцию byte в выразении byte(v). Почему? Не знаю. Но важно, что получается word, равный $100. Т.е. младший байт равен 0 => boolean($100) = boolean($00) = false.
2. Случай когда variant(256) -> boolean.
В этом случае значение 256 не проходит через руки целочисленного типа - сразу в манагере вариантов преобразуется к boolean.

См. cpu...

← →
Суслик © (2004-12-21 18:08) [163]

> [161] Sha © (21.12.04 18:03)

> Идеологически :) правильнее сравнивать что-либо не с истиной,
> а с ложью.

Ох уж это слово - идеологически :)))
С этим я давно уже не спорю. Более того посмотрев в себя не нашел = true, только <> false.

Вопрос теперь в другом. АП сказал, что boolean(v), где v variant есть грубая ошибка. Если можно, то хотелось бы узнать почему. Я пока от него не услышал ничего. Может ты знаешь?

← →
DiamondShark © (2004-12-21 18:13) [164]

> Суслик © (21.12.04 17:44) [150]
>
> > [147] DiamondShark © (21.12.04 17:39)
>
> Я так полагаю мы обсуждаем тему приемущественного использования
> методов вместо локальных переменных? ТАк?

Не-а, ни разу не так. Мы обсуждаем тезис:
"пользоваться локальными переменными грешно - функции лучше."
со ссылкой на Фаулера.

> Если да, то я тебе сказал, где читать до полного просветления...

Дело в том, что я Фаулера читал. Ничего подобного у него нет.

> Думаешь есть резон их вспоминать. Я же не на экзамене -
> могу и забыть чего.

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

← →
Sha © (2004-12-21 18:17) [165]

> Суслик © (21.12.04 18:08) [163]

Сначала ты попробуй объяснить мне, что есть boolean(Null) :)

← →
DiamondShark © (2004-12-21 18:23) [166]

> что есть boolean(Null)

EVariantError

← →
msguns © (2004-12-21 18:25) [167]

>Суслик ©

не надоело отмахиваться ?

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

>В этом случае значение 256 не проходит через руки целочисленного
типа - сразу в манагере вариантов преобразуется к boolean.

Вот это-то самое интересное :^). При том, что поддержкой паскалевского типа boolean (1-байтовый, true=1) занимаются исключительно компилятор и RTL.

← →
Anatoly Podgoretsky © (2004-12-21 18:38) [169]

Sha © (21.12.04 18:17) [165]
Вот именно, про это сказано выше, про vartype

PVOzerski © (21.12.04 17:37) [146]
отсюда следует, что boolean(wb) это не приведение типа, а функция, а boolean(byte) приведение.

Но оппонент старательно избегает обсуждения случая для vartype <> varBoolean
Более того приведенный CPU код где проводится сравнение с 1 явно показывает ошибочность такого сравнения, конечно возможно приведен не весь код, скажем где то выше есть преобразование значения bool в единицу/ноль, тогда все в порядке, но так как кода больше не приведено, то и говорить пока не о чем.

← →
Anatoly Podgoretsky © (2004-12-21 18:42) [170]

И главное зачем делать такие рисскованные шаги, которые явно зависят от версии компилятора, а надо, что бы код одинаково надежно работал как на Д2 так и на Д12, а формат bool и boolean хорошо документирован.
Помню несколько месяцев назад было обсуждение, связаное с bool и неверной работой кода, а оно было связано именно с приведением и со сравнение с true, подробности конечно не помню, но это близко к сегодняшнему обсуждению, сегодняшнее усугляется примением variant

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

2Anatoly Podgoretsky © (21.12.04 18:42) [170]:
Присоединяюсь. Тем более, что выбор, что использовать, есть. Я вообще варианты только в случаях OLE/COM использую, потому что там без них просто нельзя.

← →
Sha © (2004-12-21 23:17) [172]

> PVOzerski © (21.12.04 18:45) [171]

Присоединяюсь.
На мой взгляд в данном случае вместо Variant было бы уместнее использовать longbool или integer.

← →
Johnmen © (2004-12-21 23:21) [173]

>Anatoly Podgoretsky © (21.12.04 18:42) [170]
>а надо, что бы код одинаково надежно работал как на Д2 так и на Д12,

Коды столько не живут :)

← →
Юрий Зотов © (2004-12-21 23:36) [174]

> По каким моментам кода вы понимаете - профи или так... ?

Практически все уже сказал y-soft.

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

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

← →
Aldor © (2004-12-22 00:00) [175]

Я недавно занялся составлением своего sample-кода (в приложение к резюме), и главный вопрос оказался такой: какого размера должен быть sample? Слабо представляю себе, что человек, отвечающий за прием кадров будет смотреть 10 листов кода. Однако при этом в коде на страничку мало что можно показать. Конечно, отсюда вывод: искать "середину". И приходим к следующему вопросу: "Что нужно показывать в своем sample-коде?"

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

> Aldor © (22.12.04 00:00) [175]
> "Что нужно показывать в своем sample-коде?"

ИМХО, правду. То есть:

1. Это должен быть действительно собственный код, а не содранный с просторов Интернета.

2. Он должен показывать действительный уровень. Не больше, но не меньше.

3. 10 листов для не этого нужно. Достаточно нескольких процедур, каждая строк на 20, не более. Иначе никто не станет читать.

4. Неплохо привести пару-тройку разных кусков. Скажем, один кусок показывает знание API, другой - знание VCL, третий - умение строить нетривиальные алгоритмы.

5. Еще неплохо, если показанные куски стыкуются со спецификой конкретной конторы, куда пишется резюме.

← →
Anatoly Podgoretsky © (2004-12-22 01:43) [177]

Johnmen © (21.12.04 23:21) [173]
Живут, у меня есть несколько проектов, которые пережили Д2-Д6, хоть это и неправильно технологически.

← →
Alex Konshin © (2004-12-22 01:46) [178]

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

← →
Piter © (2004-12-22 01:53) [179]

Sandman25 © (21.12.04 11:26) [12]
опытного программиста меньше операторов case

а по-моему мнению это как раз новички не используют case, ибо не знают про него, а используют множественный if, Типа:

if Msg.Message = WM_USER then... ; if Msg.Message = WM_PAINT then... ; if Msg.Message = WM_PASTE then ... ;

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

Sandman25 © (21.12.04 11:32) [15]
а вместо одного обработчика нескольких разных кнопок следует использовать несколько разных обработчиков.

Sandman25, имхо, ты не прав :) Да новички вообще не знают, что на разные кнопки можно повесить один обработчик! Ты что... Ведь они задают обработчики исключительно через вкладку Events в инспекторе объектов, а там по двойному клику для каждого события создается свой обработчик, куда и пишется код.

y-soft © (21.12.04 12:28) [59]
Я бы добавил еще грамотное использование try..except и try..finally и предпроверку условий - "неопытные" обычно этим пренебрегают...

это 100%

Если профи открывает ссылку:

Handle := OpenXXX

то он ее и закрывает:

Handle := OpenXXX... ; try ... finally CloseXXX(Handle); end;

PVOzerski © (21.12.04 12:18) [54]
3) обращения к конкретному экземпляру класса из метода этого класса (в общем случае).

при этом признаком хорошего тона, вероятно, стоит признать явное употребление Self.

PVOzerski © (21.12.04 12:33) [62]
Вот еще вопрос: оптимизируется ли такое на этапе компиляции?
for i:=1 to length(MyDynArray)do
MyDynArray[i-1]:=100;

а чему тут оптимизироваться?
Кстати, имхо так правильнее:

for i:=0 to High(MyDynArray)do MyDynArray[i]:=100;

PVOzerski © (21.12.04 13:18) [83]
на предмет того, сколько раз будет вычитаться единица в процессе выполнения кода

ты про это... А ты посмотри как организованы циклы. При определенных обстоятельствах for i:=x to y do выполняется наоборот, то есть счетчик цикла крутится от высшего значения до нуля

← →
Sandman25 © (2004-12-22 09:07) [180]

[134] Fay © (21.12.04 17:09)

Проблема с бедламом элементарно решается.

Допустим, GetInternetConnection().Connected().GetServer().GetServerFrame().GetParam() возвращает объект типа TMyObject, тогда описываем

procedure DoMyObjectOperations(const MyObject: TMyObject);
begin
MyObject.Set(1);
....
end;

и вызываем
DoMyObject(GetInternetConnection().Connected().GetServer().GetServerFrame().GetParam());

Так что подход Фаулера в принципе правильный :)

← →
Sandman25 © (2004-12-22 09:17) [181]

[179] Piter © (22.12.04 01:53)
Да новички вообще не знают, что на разные кнопки можно повесить один обработчик!

Когда новички начинают повышать свой уровень, они добираются до момента, когда всюду стремятся использовать Tag в качестве выбора, из-за этого им кажется, что они круто программируют. Затем они доходят до сравнений указателей, происходит небольшой рефакторинг и в результате получаем if Sender = Button1.

← →
Igorek © (2004-12-22 10:55) [182]

Кудесник © (21.12.04 10:30)
По каким моментам кода вы понимаете - профи или так... ?
{*******************************************************} { } { Borland Delphi Runtime Library } { System Utilities Unit } { } { Copyright (C) 1995,99 InpriseCorporation } { } {*******************************************************}
$-)

---
А если серьезно, то должно быть "коротко и ясно".

← →
Gero © (2004-12-22 10:58) [183]

> $-)

Это за директива компилятору?

← →
Gero © (2004-12-22 10:58) [184]

> Это за

Это что за

← →
Igorek © (2004-12-22 11:01) [185]

Gero © (22.12.04 10:58) [183]
Ну высокооплачиваемый профи писал.

← →
Суслик © (2004-12-22 11:05) [186]

> [164] DiamondShark © (21.12.04 18:13)
> Не-а, ни разу не так. Мы обсуждаем тезис:
> "пользоваться локальными переменными грешно - функции лучше."
> со ссылкой на Фаулера.

Блин. Флудер. Без обид.

> > Если да, то я тебе сказал, где читать до полного просветления...
> Дело в том, что я Фаулера читал. Ничего подобного у него
> нет.

Гонишь. Если бы читал, то знал бы о чем речь. Без обид.

← →
Суслик © (2004-12-22 11:17) [187]

> [165] Sha © (21.12.04 18:17)
> > Суслик © (21.12.04 18:08) [163]
>
> Сначала ты попробуй объяснить мне, что есть boolean(Null)
> :)

Александр.
Попытаюсь тебе объяснить тему разговора.

Факт 1. Я наблюдал неустойчивое поведение компилятора в следующем случае

v: variant; ... v := true; // false - для примера не важно if v then // условие срабатывает неверно

Примеров приводить не буду, т.к. к сути обсуждаемого вопроса это отношения не имеет. Скажу только, что наблюдал я это в дельфи5. Судя по cpu клинило именно компилятор - он приводил не к тому целевому типу - в данном случае boolean. Если не ошибаюсь значение всегда была false.

Факт 2. С целью избежать неверного поведения в тех случаях, когда variant заведомо содержит boolean, я стал писать boolean(v).

v: variant; ... v := true; if boolean(v) then

Как сказал АП - это есть грубая ошибка, т.к. анализируется только 1 байт, а не 2, которые отводятся на хранение wordbool (именно в этом типе в variant хранится булевы значения).

Меня данный факт, сообщенный безусловно уважаемым человеком, очень заинтересовал. И понятно почему - потому, что я использую такую конструкцию. Исследования cpu показали, что АП не прав - при переведении variant -> boolean анализируются 2 байта, а не 1. К тому же boolean(v) (повторю v содержит значение заведомо совместимое с boolean) нисколько не противоречит семантике явного приведения типов.

На какой вопрос бы я хотел получить ответ:
1) почему boolean(v) является грубой ошибкой в случае если v содержит значение совместимое с boolean?
2) Или АП не прав, т.к. не до конца разобрался в обсуждаемом предмете?

Меня этот вопрос (первый:) действительно волнует т.к. я не могу найти объяснения. А верить уважаемым людям воспитание приучило.

Буду безмерно благодарен если кто-то поможет... :)

С уважением, Тимохов Д.

← →
Суслик © (2004-12-22 11:22) [188]

> [168] PVOzerski © (21.12.04 18:31)
> Вот это-то самое интересное :^). При том, что поддержкой
> паскалевского типа boolean (1-байтовый, true=1) занимаются
> исключительно компилятор и RTL.

А что здесь интересного? Есть variant manager, который компилятор явно подключает при компиляции - своего рода compiler magic. В приведенном тобой примере с byte() компилятор кладет на твое желание привесит к byte, а приводит к word.

> [171] PVOzerski © (21.12.04 18:45)
> Присоединяюсь. Тем более, что выбор, что использовать, есть.
> Я вообще варианты только в случаях OLE/COM использую, потому
> что там без них просто нельзя.
>
> [172] Sha © (21.12.04 23:17)
> Присоединяюсь.
> На мой взгляд в данном случае вместо Variant было бы уместнее
> использовать longbool или integer.

Господа - значение совместимое с boolean приходит из БД в виде variant.
Выбора у меня нет :)

> Суслик © (22.12.04 11:22) [188]
> Господа - значение совместимое с boolean приходит из БД в виде variant.
> Выбора у меня нет :)

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

> [189] Sha © (22.12.04 11:48)

Александр.
Спасибо за ответ.

Но поинмаешь дело то не в этом. Это понятно, что нужно защищаться и все такое.

Но посмотри мой пост тебе с объяснением вопроса.

Утверждением мастера было: нельзя приводить, т.к. при этом анализируется только младший байт. Но это же не так. Вот. Или так?

И вообще - не люблю делать грубых ошибок.

ЗЫ
Говорили мне учи асемблер :)

АП был прав, я и другие привели доводы, да и ты опять довод привел, на который я тоже указывал, это разные версии компилятора.
Хочешь работь с варианты безопасно, так предварительно проверяй VarType
А явное приведение (преобразование) в данном случае грубая ошибка, ну не получил сейчас по ушам, так есть надежда получить в будущем. Поскольку это ВАРИАНТ, а у тебя явное приведение.
Про различные безопасные пути тебе рассказали, выбор есть.

Любишь ты поспорить :-)

//Суслик
А зачем булеан использовать. Касти это дело к целочисленному значению: 0 - false, не 0 - true.

> [191] Anatoly Podgoretsky © (22.12.04 11:53)

> Любишь ты поспорить :-)

Ты не любишь :)))
Да и повод есть.

--------------
По делу.
Гарантия есть, что там varBoolean. Давай даже так. Допустим я даже это проверил.

Т.е. исходная позиция: vartype(v) = varboolean!

(на самом деле у меня обычно именно так)

Ты же вроде говорил, что boolean(v) будет работать некорректно не потому, что я не проверил boolean, а потому, что будет сравнение только младшего байта, а т.к. varBoolean представляется WordBool (т.е. 2 байта), то я совершаю грубую ошибку.

Я же спорил по этому, а не потому, что я не понимаю, что я опасно привожу.

Т.е. вопрос: в приведенном примере (где v имеет тип varBoolean) приведение boolean(v) есть грубая ошибка?

ЗЫ. Ответь и разойдемся по другим топикам :)))))))

> И вообще - не люблю делать грубых ошибок.

Ути-пути...

Ну про байты и CPU код мы говорили, если это все и нет выше приведения wordbool к boolean то код в CPU ошибочный, поскольку идет сравнение с 1, было бы с 0 то все бы было в порядке. Именно эта ошибка часто и фигурирует в вопросах про проверку bool
Я и другие несколько раз подчеркнули этот факт, что true для bool это не 1

AlexG © (22.12.04 12:02) [192]
А как насчет vartype <> varBoolean это же нормальная ситуация для варианта, за что вообще считать varnull поскольку это по сути неопределенное значение, ни true ни false, а другие типы для варианта. Я сам в начале пути сталкивался с этим, пришлось вводить проверку на vartype, хорошо хоть при присваивании происходило исключение, долго причину искать не пришлось.

2 Anatoly Podgoretsky © (22.12.04 11:53) [191]
Тоесть, вы хотите сказать, что не во всех компиляторах работа с Variant в случаях, когда её значение использовалось как boolean/LongBool, использовало Call @VarToBool?

> [195] Anatoly Podgoretsky © (22.12.04 12:37)

Код на дельфи

var v: variant; begin // Присвоение делаю таким образом, чтобы заведомо в младшем // байте был 0 и общее значение wordbool было отлично от 1, -1 и пр. tvardata(v).vtype := varBoolean; pword(@tvardata(v).vboolean)^ := $f00; // b станер равно true, при любом значении v.vboolean, отличном от нуля. b := boolean(v); <<< end;

Теперь рассмотрим код cpu из variants - фукцния _VarToBool для типа varBoolean:

mov eax,[ebp-$04] cmp word ptr [eax+$08],$01 << это слово равное v.vboolean. Если > 0 sbb eax,eax inc eax mov [ebp-$05],al jmp +$00000268

Моих скудных знаний асм хватило на то, чтобы опнять, что все дело в флажке CF, который принимает значение на строчке << и используется фукнцией sbb.

Т.е. любое значение v.vboolean отличное от нуля переводится в true.

Т.о. любое значение wordbool отличное от нуля переводится в true.

В чем же грубость ошибки?

//Anatoly Podgoretsky ©
Честно говоря, я не совсем понял, что ты сказал вот здесь:
за что вообще считать varnull поскольку это по сути неопределенное значение, ни true ни false, а другие типы для варианта.
Т.е. ты имеешь ввиду случай когда приходящее значение не является булевым? Если так, то лучше сразу определить для себя, что от туда должно приходить и поставить проверку, а так же, на всякий случай try ... except ...

А ты рассмотри случай когда получишь из функции не varBoolean, как ты сказал она у тебя внешняя, а ты явно говоришь, а мне плевать какой тип, считай что varBoolean

И получишь разные результаты на разных версиях Дельфи, в Ж6 очень сильно изменили работу с вариантами, отчасти из постоянных ошибок при работе с ними.

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

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

break :)

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