Эх, глюки

← →
AlexanderMS © (2006-05-11 19:26) [0]

Вы, наверное, замечали, что Delphi - далеко не совершенная и не лишённая глюков среда разработки. Но самое интересное то, что компилятор способен создавать разный код при каждой компиляции. У меня было такое: я долго не мог понять, почему при одной компиляции у меня всё работало, а при другой моя программа глючила. (Если кто помнит, я просил найти ошибку в коде, а в последующих сообщениях я то писал, что всё нормально, то удивлялся, что пограмма глючит). Как так? Во всём был виноват метод FindText объекта класса TRichEdit. После пошаговой трассировки я обнаружил, что при первой компиляции эта функция находила текст, а при второй возвращала -1 (текст не найден).
Пришлось писать свою аналогичную функцию. Я сделал вывод, что компилятор может создавать разный код при новой компиляции. У Вас было такое и правда ли это?

← →
Джо © (2006-05-11 19:28) [1]

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

← →
AlexanderMS © (2006-05-11 19:33) [2]

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

Это - новый закон Глюка в программировании на Delphi.

← →
Eraser © (2006-05-11 19:35) [3]

> AlexanderMS © (11.05.06 19:26)

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

Это не так. Телепатор говорит, что проблема скорее всего в обнулении переменных, вернее в их необнулении :)

← →
Димитрий © (2006-05-11 19:40) [4]

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

← →
AlexanderMS © (2006-05-11 19:42) [5]

> Это не так. Телепатор говорит, что проблема скорее всего
> в обнулении переменных, вернее в их необнулении :)

То есть? И кто такой телепатор?

← →
Чапаев © (2006-05-11 19:44) [6]

> Это не так. Телепатор говорит, что проблема скорее всего
> в обнулении переменных, вернее в их необнулении :)

Телепатор-Про говорит, что виновато свойство RichEdit.SelStart

← →
AlexanderMS © (2006-05-11 19:46) [7]

> Телепатор-Про говорит, что виновато свойство RichEdit.SelStart

Странно, но моя функция работала нормально.

← →
Чапаев © (2006-05-11 19:48) [8]

> AlexanderMS © (11.05.06 19:46) [7]

Это исключительно твои личные проблемы.

← →
AlexanderMS © (2006-05-11 19:49) [9]

Кстати, мне очень не нравиться, что в Memo, RichEdit и Edit при перемещении фокуса на другую форму скрывается выделение (синий маркер). Как-нибудь можно избавиться от этого?

← →
KilkennyCat © (2006-05-11 19:52) [10]

> [9] AlexanderMS © (11.05.06 19:49)

можно.
Можно написать свой компонент.

← →
AlexanderMS © (2006-05-11 19:54) [11]

> Это исключительно твои личные проблемы.

"Нет, эта проблема общественная! Delphi своими глюками значительно снижает наши показатели. Поэтому нужно исправить все глючные процедуры и функции до конца квартала..."

P. S. Что-то знакомое...

← →
AlexanderMS © (2006-05-11 19:57) [12]

> Можно написать свой компонент.

А можно ли это исправить в коде TCustomEdit? Если да, то где именно?

← →
Eraser © (2006-05-11 19:58) [13]

> AlexanderMS © (11.05.06 19:49) [9]

> Как-нибудь можно избавиться от этого?

HideSelection := false; ?

← →
AlexanderMS © (2006-05-11 19:59) [14]

> Eraser © (11.05.06 19:58) [13]
> HideSelection := false;

Огромное спасибо, а я хотел куда-то копать...

← →
Юрий Зотов © (2006-05-11 20:37) [15]

> AlexanderMS © (11.05.06 19:59) [14]

Но виноваты все равно глюки Delphi, правда? :о)

Кстати, если бы такой "глюк" даже и существовал, то виновата и в этом случае была бы все равно не Delphi. Поскольку перечисленные Вами классы VCL являются всего лишь ООП-оберткой вокруг стандартных оконных классов Win32.

← →
Gero © (2006-05-12 01:42) [16]

Читать [1] до полного просветления, ибо это Истина. И эта ветка — еще одно тому подтверждение.

← →
Marser © (2006-05-12 02:06) [17]

"Так значить в Delphi нельзя добавить lookup поле у dataset в runtime?! Это еще раз доказывает что, delphi гиморой."
(С) Орешник раритетное издание (сейчас там этого нет)

← →
Чапаев © (2006-05-12 10:40) [18]

Вы меня со свету сживёте этими шутками про датасет (см. http://delphimaster.net/view/5-1147246180/)... Хотя перечисленные проблемы я почти все порешал... :-)

← →
Игорь Шевченко © (2006-05-12 10:43) [19]

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

Неверный вывод

← →
Чапаев © (2006-05-12 10:48) [20]

> > Я сделал вывод, что компилятор может создавать разный
> код
> > при новой компиляции
> Неверный вывод

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

← →
Плохиш © (2006-05-12 11:39) [21]

> AlexanderMS © (11.05.06 19:33) [2]
>
> > количество глюков, находимых
> > в средстве разработки обратно пропорционально опыту и
> знаниям
> > программиста.
>
> Это - новый закон Глюка в программировании на Delphi.

Нет, это аксиома в не зависимости от языка программирования.

← →
REA (2006-05-12 12:06) [22]

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

← →
data © (2006-05-12 12:19) [23]

в дельфи встречалась с глюком, когда переставало работать окно code explorer.. задалбывало, тк глючило часто. Значительно реже, но тоже глючил подвал для сообщений компилятора - выдавалось AV при добавлении туда сообщений)). Оба этих глюка приходилось устранять только перезапуском дельфи.
А недавно в билдере нашли баг: при сборке дебаговой версии все Ок, а при сборке релиза почему-то некорректно работает блок try-finally, если в finally есть оператор return))). Покопались в инете - оказывается это известный баг, надо было знать)))

← →
homm © (2006-05-12 13:00) [24]

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

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

← →
Desdechado © (2006-05-12 13:06) [25]

REA (12.05.06 12:06) [22]
это если пользоваться недокументированными (а значит - негарантированными, т.е. случайными фичами)

← →
Inco (2006-05-12 13:06) [26]

На всякий случай вот вам правильный паттерн для создания безглючного кода:

"Семь раз проверь один раз верни"

if (flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true) then
Result := true
else
Result := false

← →
antonn © (2006-05-12 13:32) [27]

Explorer в Deplhi5 меня задалбывал, в 7ой такого нет. Зато есть глюк с перепрыгиванием а списке Code Insight (через стройку, через две, через три..). Чем больше работаешь, тем больше строк перепрыгивает. Однажды рекорд поставил, к концу дня с 1 на 16 перепрыгивал:))

← →
КиТаЯц © (2006-05-12 14:02) [28]

> AlexanderMS © (11.05.06 19:26)
>
> Вы, наверное, замечали, что Delphi - далеко не совершенная
> и не лишённая глюков среда разработки. Но самое интересное
> то, что компилятор способен создавать разный код при каждой
> компиляции. У меня было такое: я долго не мог понять, почему

Да! И у меня было!
Потом прошло... давно уже... куда делось? Сам не пойму... :-/ не помню наверное...

← →
Думкин © (2006-05-12 14:08) [29]

> Inco (12.05.06 13:06) [26]

Тут тогда надо управлять проверками, ибо 7 раз не всегда выйдет.

← →
AlexanderMS © (2006-05-12 14:12) [30]

> > > Я сделал вывод, что компилятор может создавать разный
>
> > код
> > > при новой компиляции
> > Неверный вывод
>
> Почему ж... Автор ведь не уточнил, вносил ли он изменения
> в исходный код перед "каждой компиляцией"...

Я уточняю, что изменения в исходный код я не вносил, а то зачем бы я говорил о глюках? Один раз нажму F9 - всё ОК, другой раз, не закрывая Delphi, - глючит...

> Зато есть глюк с перепрыгиванием а списке Code Insight (через
> стройку, через две, через три..).

И у меня было. Приходилось мышкой выбирать.

> if (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) then
> Result := true
> else
> Result := false

Это уже супер-проверка: каждый раз дважды проверяется равенство flag"a true. :)

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

У меня тоже очень умный оптимизатор. В начале цикла проверяется некая переменная типа boolean, в конце - меняется в зависимости от результата. И здесь вдруг выясняется, что value assigned to x never used, хотя это значение проверятся в начале цикла. Таким образом, оптимизатор перестарался...

← →
Eraser © (2006-05-12 14:23) [31]

> AlexanderMS © (12.05.06 14:12) [30]

> У меня тоже очень умный оптимизатор. В начале цикла проверяется
> некая переменная типа boolean, в конце - меняется в зависимости
> от результата. И здесь вдруг выясняется, что value assigned
> to x never used, хотя это значение проверятся в начале цикла.
> Таким образом, оптимизатор перестарался...

показывай код.

← →
Игорь Шевченко © (2006-05-12 14:32) [32]

> У меня тоже очень умный оптимизатор. В начале цикла проверяется
> некая переменная типа boolean, в конце - меняется в зависимости
> от результата. И здесь вдруг выясняется, что value assigned
> to x never used, хотя это значение проверятся в начале цикла.
> Таким образом, оптимизатор перестарался...

Never attribute to malice which can be adequately explained by stupidity.

← →
Джо © (2006-05-12 14:54) [33]

> [32] Игорь Шевченко © (12.05.06 14:32)
> Never attribute to malice which can be adequately explained
> by stupidity.

Моя любимая цитата, вот уж совпадение :)

← →
AlexanderMS © (2006-05-12 17:19) [34]

> Never attribute to malice which can be adequately explained
> by stupidity.

Приму на вооружение :)

> показывай код.

Исправил код от начала и до конца. Теперь сделал по-другому.

← →
Gero © (2006-05-12 17:25) [35]

> AlexanderMS © (12.05.06 17:19)

То есть с [1] ты уже согласился?

← →
AlexanderMS © (2006-05-13 19:01) [36]

> То есть с [1] ты уже согласился?

Нет! [34] - к [30].

FindText действительно подводит, программа то работает, то нет после очередной компиляции, хотя код не я не менял. Ну ладно, я уже свою функцию написал.

← →
Джо © (2006-05-13 20:44) [37]

> FindText действительно подводит, программа то работает,
> то нет после очередной компиляции

Значит, это была неправильная программа :)

> Never attribute to malice which can be adequately explained by stupidity.
+

Бритва Хеллона:
Не усматривайте злого умысла в том, что вполне объяснимо глупостью.

Закон Ханта:
У любой великой идеи есть недостаток, равный или превышающий величие этой идеи.

Закон Хлейда:
Решение сложной задачи поручайте ленивому сотруднику - он найдет более легкий путь.

Закон Мейера:
Усложнять - просто, упрощать - сложно.

> Never attribute to malice which can be adequately explained by stupidity.
+

Бритва Хеллона:
Не усматривайте злого умысла в том, что вполне объяснимо глупостью.

Почему "+", если это просто перевод? :-)

> [39] Lamer@fools.ua © (14.05.06 00:09)
> > Never attribute to malice which can be adequately explained
> by stupidity.
> +
>
> Бритва Хеллона:
> Не усматривайте злого умысла в том, что вполне объяснимо
> глупостью.
>
> Почему "+", если это просто перевод? :-)

Тоже хотел спросить :-)

> if (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) and
> (flag == true) then
> Result := true
> else
> Result := false

руки просто чешутся...

Result := (flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true) and
(flag == true);

Лично у меня руки чешутся двойной символ "=" на одиночный заменить.

← →
Gero_ (2006-05-14 23:55) [43]

> AlexanderMS © (13.05.06 19:01)

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

← →
Imbac (2006-05-15 00:26) [44]

1:
if a=b then
begin
if b=a then
begin
if a<>b then
begin
if a<=b then
begin
if b>=a then
begin
end
else
begin
goto 1;//Вдруг компилятор ошибся
end;
end;
end;
end;
end;

← →
Imbac (2006-05-15 00:27) [45]

:DDD

> goto 1

Это вам не Бейсик, батенька! ;)

Дадад, label должон соответствовать правилам составления имён идентификаторов...

Оптимизируем дальше:

Result := flag and flag and flag and flag and flag and flag and flag;

> [48] KilkennyCat © (15.05.06 02:46)
> Оптимизируем дальше:
>
> Result := flag and flag and flag and flag and flag and flag
> and flag;

Небезопасно. Эх, учи вас :)

try Result := flag and flag and flag and flag and flag and flag finally // может, в этот раз повезёт? Result := flag and flag and flag and flag and flag and flag end;

> [50] Германн © (15.05.06 03:06)
> 2 Джо © (15.05.06 02:48) [49]
> except забыл вставить, имхо. :-)

Это можно. Даже двойной блок. На всякий пожарный :-)

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

но глюк это дельфей или виндов не знаю

Мне так думается, что в 99% случаев это глюк разработчика, написавшего компонент.

Эх, глюки Найти похожие ветки