Альтернатива GetTickCount

← →
Unknown user © (2012-03-13 20:03) [0]

Подскажите, пожалуйста чем можно заменить такую конструкцию

Start := GetTickCount;
while (FReceivedData = nil) and (GetTickCount - Start < WaitTime) do
Application.ProcessMessages;

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

Оказалось, что GetTickCount возвращает правильные значения только первые 50 дней непрерывной работы системы.

← →
QAZ (2012-03-13 20:16) [1]

идиотская конструкция

← →
Anatoly Podgoretsky © (2012-03-13 20:18) [2]

> Unknown user (13.03.2012 20:03:00) [0]

Не новость.

← →
Sha © (2012-03-13 20:18) [3]

а мне интересно, чему равно WaitTime

← →
Jeer © (2012-03-13 20:19) [4]

И что ?
Таймаут на 50 дней ?

GetTickCount всегда возвращает "правильные" значения по модулю.

← →
Sha © (2012-03-13 20:23) [5]

и еще неправильные - это какие ?
и еще где все эти операторы написаны?

← →
Sha © (2012-03-13 20:26) [6]

и еще часы на стене - они правильные значения показывают?

← →
Jeer © (2012-03-13 20:33) [7]

> Подскажите,

Подсказываю:
GetSystemTimeAsFileTime(..)

этого должно надолго хватить "правильно" показывать время.

← →
sniknik © (2012-03-13 20:37) [8]

> чем можно заменить такую конструкцию
если ждать аж 50 дней то календарем... :)

> GetTickCount возвращает правильные значения только первые 50 дней непрерывной работы системы.
а дальше что неправильные? все возвращается правильно, в соответствии с документацией...
а то, что переменная возвращаемого значения возрастает без учета переполнения (в соответствии с докой), довольно легко учесть в условии.

← →
Sha © (2012-03-13 20:40) [9]

там типа учтено, проблема в другом

← →
Dimka Maslov © (2012-03-13 21:26) [10]

Для начала нужно подумать, а что даёт такая "конструкция"? Она не даёт ничего. Сообщения обрабатываются, форма выглядит и работает нормально. Если нужен таймер - надо пользоваться таймером, там тоже в процессе ожидания события всё работает. На худой конец можно воспользоваться rtdsc. Но у него тоже время ограничено.

← →
sniknik © (2012-03-13 22:24) [11]

> там типа учтено
там типа, без типа, нельзя сказать.
например
var start, finish: Int64; begin start := DWORD(-1) - 10; finish:= 10; ShowMessage(IntToStr(finish - start)); end;
или
var start: DWORD; finish: integer; begin ...

← →
DVM © (2012-03-13 22:54) [12]

> Unknown user © (13.03.12 20:03)
> Подскажите, пожалуйста чем можно заменить такую конструкцию
>
> Start := GetTickCount;
> while (FReceivedData = nil) and (GetTickCount - Start <
> WaitTime) do
> Application.ProcessMessages;

Эта конструкция результат желания одновременно задержать выполнение программы и обрабатывать сообщения Windows. Смысла не имеет никакого.
Данная конструкция заменяется таймером. В таймере проверка какого либо флага. Если нужно запретить в программе выполнять какие либо действия, то опять же проверяем флаг перед их выполнением. И не нужно крутить циклы!!!

А ждать очень большие интервалы времени лучше с помощью WaitableTimer (CreateWaitableTimer, SetWaitableTimer)

← →
Sha © (2012-03-13 23:15) [13]

sniknik © (13.03.12 22:24) [11]

Еще типа byte может быть.
Раз работаем с GetTickCount, то имеет смысл объявить
var Start, WaitTime: dword;
и все учтется автоматом.

Если в главном потоке проверяем FReceivedData,
то, вероятно, в другом ее меняют.
Поэтому имеет смысл оттуда просто послать сообщение,
и тогда вся эта "конструкция" нафиг не нужна.

← →
sniknik © (2012-03-13 23:34) [14]

> и все учтется автоматом.
спасибо кэп!

← →
Sha © (2012-03-13 23:47) [15]

все благодарности - компилятору, это он предупреждения выдает

← →
sniknik © (2012-03-14 00:09) [16]

а ты проверь... вот хотя бы первое приведенное в [11].

← →
antonn © (2012-03-14 00:16) [17]

> DVM © (13.03.12 22:54) [12]
>
>
> > Unknown user © (13.03.12 20:03)
> > Подскажите, пожалуйста чем можно заменить такую конструкцию
> >
> > Start := GetTickCount;
> > while (FReceivedData = nil) and (GetTickCount - Start
> <
> > WaitTime) do
> > Application.ProcessMessages;
>
> Эта конструкция результат желания одновременно задержать
> выполнение программы и обрабатывать сообщения Windows. Смысла
> не имеет никакого.

у меня вместо "Application.ProcessMessages" вызывается обработчик, и в зависимости от класса это может быть и таймер, в отдельном потоке и не завязаный на оконные сообщения. Задавался тем же вопросом что и автор: что делать после 49 дней. Но мне проще, я могу сервер ребутнуть ради своей службы, потому не стал особо мучаться.

← →
antonn © (2012-03-14 00:18) [18]

вот, кстати http://forum.sources.ru/index.php?showtopic=334024

← →
Anatoly Podgoretsky © (2012-03-14 00:25) [19]

> antonn (14.03.2012 00:16:17) [17]

Умножить на количество кругов

← →
DVM © (2012-03-14 00:27) [20]

> в отдельном потоке и не завязаный на оконные сообщения

там WaitableTimer + WaitForXXXObjects самое оно.

← →
Sha © (2012-03-14 00:43) [21]

> а ты проверь... вот хотя бы первое приведенное в [11].

Зачем? Я арифметику знаю.
Нормальный программист если в коде ниже машинально напишет первое объявление,
прочитав предупреждение, тут же исправит на второй вариант.
Профнепригодный на int64. Вот и весь сказ.

procedure TForm1.Timer1Timer(Sender: TObject); var Start, WaitTime: integer; //warning Start, WaitTime: dword; //OK FReceivedData: pointer; begin FReceivedData:=nil; WaitTime:=1000; Start := GetTickCount; while (FReceivedData = nil) and (GetTickCount - Start < WaitTime) do Application.ProcessMessages; end;

← →
Sha © (2012-03-14 00:49) [22]

> antonn © (14.03.12 00:18) [18]

повеселили ребята

← →
Unknown user © (2012-03-14 17:19) [23]

Тут целые баталии развернулись по поводу GetTickCount :)

Это был мой недосмотр...Конец рабочего дня, сказывается усталость :)

Ошибку нашел почти сразу, после создания этого поста. Забыл отписать. Start у меня была объявлена как Integer.

Start := GetTickCount; while (FReceivedData = nil) and (GetTickCount - Start < WaitTime) do Application.ProcessMessages;

Здесь нет другого потока. FReceivedData создается также в первичном потоке, при обработке сообщений из очереди. WaitTime = 5000.

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

Никто из вас не использует такой подход?

← →
QAZ (2012-03-14 17:23) [24]

> Start у меня была объявлена как Integer.

а какого фака не кардинал?
и где связь между 5 секунд и 50 суток?

← →
sniknik © (2012-03-14 17:24) [25]

> Никто из вас не использует такой подход?
нет конечно.

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

← →
Unknown user © (2012-03-14 17:28) [26]

>а какого фака не кардинал?

ну я же говорю, пьян был

>и где связь между 5 секунд и 50 суток?

ну тут все просто, сервак уже отработал больше 25 суток без перезагрузки. Поэтому Start переполнялся и оказывался < 0. GetTickCount же возвращала значение больше 2^31 и цикл сразу завершался.

← →
QAZ (2012-03-14 17:35) [27]

> Поэтому Start переполнялся и оказывался < 0

я и говорю какого фака интежер?

← →
Jeer © (2012-03-14 17:35) [28]

> сказывается усталость :)

> ну я же говорю, пьян был

О как! В данную эпоху понимается: "пьян был" == "устал" :)

Не дай хрен такого работника никому.

← →
Jeer © (2012-03-14 17:42) [29]

> я и говорю какого фака интежер?

Да им все равно: интежер, ворд, байт, бит..

Напомню реальную историю, случившуюся чуть ранее вхождения Фобоса в грунт.

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

← →
QAZ (2012-03-14 17:47) [30]

дык еще и книжки пишут по принципу "типов integer и real вам будет достаточно для большинства задач" :)

← →
Unknown user © (2012-03-14 17:50) [31]

>Не дай хрен такого работника никому.

Ну не знаю, почему-то ценят.

Не верю, что вы пишите программы без багов и никогда не "тупите". С каждым бывает...

Как насчет моего вопроса?

← →
Mystic © (2012-03-14 17:58) [32]

Идем в MSDN, смотрим функцию GetTickCount
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx

И там же читаем
The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days. To avoid this problem, use the GetTickCount64 function. Otherwise, check for an overflow condition when comparing times.

Неужели это какой-то бином Ньютона? Не говоря о том, что по идее, в автодополнении GetTickCount64 должна быть.

← →
CRLF (2012-03-14 18:02) [33]

> Jeer © (14.03.12 17:35) [28]
Чего придираешься... Бухать устал.

← →
Jeer © (2012-03-14 18:13) [34]

> Бухать устал.

Да.. не дошло до меня :)

← →
pasha_golub © (2012-03-14 18:24) [35]

function GetTickCount: LongWord; {$IFDEF DELPHI_12}inline;{$ENDIF} begin {$IFDEF MACOS} Result := AbsoluteToNanoseconds(UpTime) div 1000000; {$ENDIF} {$IFDEF MSWINDOWS} Result := Windows.GetTickCount; {$ENDIF} end; function GetTickDiff(const AOldTickCount, ANewTickCount: LongWord): LongWord; {$IFDEF DELPHI_12}inline;{$ENDIF} begin {This is just in case the TickCount rolled back to zero} if ANewTickCount >= AOldTickCount then begin Result := ANewTickCount - AOldTickCount; end else begin Result := High(LongWord) - AOldTickCount + ANewTickCount; end; end;
Привет Землянам!

← →
pasha_golub © (2012-03-14 18:26) [36]

DELPHI_12 - это Д2009, он же Tiburon, если че

← →
Sha © (2012-03-14 19:13) [37]

> Unknown user © (14.03.12 17:19) [23]

Ты задачу озвучь полностью, чего добиться хочешь?
А то, просто не верится, что такое бывает в реале.

> pasha_golub © (14.03.12 18:24) [35]

Привет братьям по разуму!
Веселье продолжается. Пил то же бухло?

← →
antonn © (2012-03-14 22:32) [38]

> DVM © (14.03.12 00:27) [20]
>
>
> > в отдельном потоке и не завязаный на оконные сообщения
>
> там WaitableTimer + WaitForXXXObjects самое оно.

для чего? сабж возвращает время прошедшее со старта системы, а предложенное?

> Sha © (14.03.12 00:49) [22]
>
> > antonn © (14.03.12 00:18) [18]
>
> повеселили ребята
>

всегда рады

← →
antonn © (2012-03-14 22:37) [39]

> Mystic © (14.03.12 17:58) [32]
>
> Идем в MSDN, смотрим функцию GetTickCount
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.
> 85).aspx

Requirements
Minimum supported client: Windows Vista
Minimum supported server: Windows Server 2008

← →
DVM © (2012-03-14 23:03) [40]

> antonn © (14.03.12 22:32) [38]

> для чего? сабж возвращает время прошедшее со старта системы,
> а предложенное?

сабж может и возвращает, но сабж применяется для организации ожидания в паре с циклом и просыпаниями через определенные интервалы времени.

WaitableTimer позволяет выставить таймер с любым интервалом, хоть 100 лет. WaitForXXX позволяют ждать срабатывания таймера хоть вечно + параллельно ждать сколько угодно событий таких как завершение потока и т.д. Крутить циклы со всякими GetTickCount, Sleep и т.д. расточительно и не правильно.

← →
antonn © (2012-03-14 23:24) [41]

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

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

← →
Sha © (2012-03-14 23:35) [42]

> antonn © (14.03.12 23:24) [41]

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

← →
antonn © (2012-03-15 00:19) [43]

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

там и так все переменные втянутые в работу с сабжем в dword, мест много, после 49 дней разность будет немного не такая как ожидалось. Плюс используется результат GetTickCount, а не его разность (используется аналогично времени в unixtime). Вот потому и задавался вопросом как бы "перегрузить" GetTickCount чтобы возвращал в int64 (например) результат.

← →
Sha © (2012-03-15 00:23) [44]

ничего не понимаю

← →
antonn © (2012-03-15 00:27) [45]

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

← →
Sha © (2012-03-15 00:29) [46]

И зачем нужно помнить старую метку 49-дневной тухлости?

← →
antonn © (2012-03-15 00:32) [47]

> И зачем нужно помнить старую метку 49-дневной тухлости?

переформулируй
один раз вызвали GetTickCount на 49-й день, второй раз на 50-й, какая будет разница м/у метками времени?

← →
Sha © (2012-03-15 00:35) [48]

1 день, разумеется
Какая разница, что хранится в метках, если разница правильная.

Пример - вокзальные часы.
Они "переполняются", но время перекура позволяют измерить.

← →
antonn © (2012-03-15 00:45) [49]

> Они "переполняются", но время перекура позволяют измерить.

до тех пор пока разница не вычисляется путем отнимания значения первой метки от второй?

← →
Sha © (2012-03-15 00:49) [50]

В нашем измерении разница всегда вычисляется путем вычитания старого замера из нового.

← →
antonn © (2012-03-15 00:52) [51]

понятно.
жаль что я всегда натыкаюсь не на "ваше", и приходится наблюдать вычитание нового из старого: 25032704-4233600000 (50 дней минус 49 дней)

← →
antonn © (2012-03-15 00:53) [52]

тьфу ты, из нового старое =)
пример с цифрами тот же

← →
Германн © (2012-03-15 00:55) [53]

> до тех пор пока разница не вычисляется путем отнимания значения
> первой метки от второй?

До тех пор, пока вычитание выполняется бездумно. Если разница считается по крайней мере один раз каждые 49.7 суток никаких проблем быть не может.

← →
antonn © (2012-03-15 00:59) [54]

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

это очень важный и информативный ответ.

← →
Sha © (2012-03-15 01:03) [55]

Во ты заморочил сам себе голову.
Старый замер - тот что был сделан до нового, их значения могут быть любыми.

procedure TForm1.Button1Click(Sender: TObject); var dw1, dw2, dw: dword; begin dw1:=25032704; Memo1.Lines.Add(IntToStr(dw1)); dw2:=4233600000; Memo1.Lines.Add(IntToStr(dw2)); dw:=dw1-dw2; Memo1.Lines.Add(IntToStr(dw)); end;

Результат

25032704 4233600000 86400000

А в вашем измерении иначе?

← →
antonn © (2012-03-15 01:07) [56]

у меня типы разные, с бОльшей "разрешающей способностью", пока до разницы дойдет

← →
Sha © (2012-03-15 01:07) [57]

> antonn

В моем примере несколько неудачно выбраны имена переменных.
Ты конечно, понял, что замер dw1 сделан после замера dw2.

← →
Sha © (2012-03-15 01:08) [58]

> у меня типы разные, с бОльшей "разрешающей способностью", пока до разницы дойдет

НАФИГА????

← →
antonn © (2012-03-15 01:09) [59]

что "нафига"?

← →
Германн © (2012-03-15 01:10) [60]

> antonn © (15.03.12 00:59) [54]
>
>
> > До тех пор, пока вычитание выполняется бездумно.
>
> это очень важный и информативный ответ.
>

Дык ведь уже дали туеву хучу примеров правильного вычитания! Последний пример в pasha_golub © (14.03.12 18:24) [35]. Дополнительная информация о частоте вычислений этой разности в моём ответе.

Какая ещё информативность тебе требуется?

← →
Sha © (2012-03-15 01:10) [61]

НАФИГА ЭТО

типы разные, с бОльшей "разрешающей способностью"

← →
antonn © (2012-03-15 01:11) [62]

> Какая ещё информативность тебе требуется?

Лично мне не нужны ответы в стиле "код должен быть продуман". Это и так все знают.
Ну может кому нибудь такие ответы нужны, потому не буду говорить тебе "не пиши их" :)

> Sha © (15.03.12 01:10) [61]
>
> НАФИГА ЭТО

sql

← →
Германн © (2012-03-15 01:14) [63]

> antonn © (15.03.12 01:11) [62]
>
>
> > Какая ещё информативность тебе требуется?
>
> Лично мне не нужны ответы в стиле "код должен быть продуман".
> Это и так все знают.

Типичный ответ троешника.
Ты автор вопроса?

← →
Sha © (2012-03-15 01:17) [64]

> Германн © (15.03.12 01:10) [60]
> Дык ведь уже дали туеву хучу примеров правильного вычитания! Последний пример в pasha_golub © (14.03.12 18:24) [35].

Это как раз пример неправильного вычитания по двум причинам:
1. сильно смахивает на всеми любимый IncDay.
2. при переходе через 0 он ошибается на 1ms.

Правильное вычитание только одно: C=A-B, и нефиг городить огород.

← →
antonn © (2012-03-15 01:18) [65]

> Sha ©

изначально я искал возможность в готовом проекте "подменить" GetTickCount который бы выдавал int64. В пхп можно было перегрузить, и в своей функции сделать костыляку наподобии [35] (собственно там она и есть).
Т.к. временнЫе метки использовались в вычислениях "много-где" (именно по этому не подходил вариант с переделкой "таймеров", подгонов типов), тип для хранения метки везде int64, и только сам источник такой метки отдает dword.

← →
Sha © (2012-03-15 01:19) [66]

> antonn © (15.03.12 01:11) [62]
> sql

не вижу связи одного с другим

← →
Sha © (2012-03-15 01:20) [67]

> GetTickCount который бы выдавал int64

ну никак не пойму зачем

← →
Германн © (2012-03-15 01:22) [68]

> Это как раз пример неправильного вычитания по двум причинам:
>
> 1. сильно смахивает на всеми любимый IncDay.
> 2. при переходе через 0 он ошибается на 1ms.

Это просто самый "ближний" пример, который я нашёл колесом мышки.
И что значит, что он "ошибается на 1ms"? С учётом того, что в топике проверка "прошли ли те 5 секунд, которые я задал".

← →
Sha © (2012-03-15 01:24) [69]

> Германн © (15.03.12 01:22) [68]

Да пойми ты, это бред, ярко демонстрирующий,
что автор не в ладах с целочисленной арифметикой.

← →
antonn © (2012-03-15 01:29) [70]

> ну никак не пойму зачем

если у меня будет завтра желание, если за сегодня никто не поймет и не попробует объяснить, и если ветку не закроют - завтра попытаюсь объяснить (хотя если из [65] не ясно - то даже не знаю есть ли смысл объяснять). А сейчас - спокойной ночи :)

← →
Германн © (2012-03-15 01:29) [71]

> Sha © (15.03.12 01:24) [69]
>
> > Германн © (15.03.12 01:22) [68]
>
> Да пойми ты, это бред, ярко демонстрирующий,
> что автор не в ладах с целочисленной арифметикой.

Какого автора ты имеешь в виду? Если Пашу Голубева, то объясни чем автор не в ладах с целочисленной арифметикой?

← →
Германн © (2012-03-15 01:33) [72]

Паша, извини. Похоже я переврал твою фамилию. :(

← →
Sha © (2012-03-15 01:40) [73]

> Германн © (15.03.12 01:29) [71]

Ну вот тебе более понятный пример.
Есть A и B.
Интегер.
Надо получить их разность.
Причем заранее известно, что она всегда точно равна A-B.
Ты бы стал писать для этого функцию?
Ты бы стал внутри нее проверять знаки переменных?
Ты бы заложил в нее ошибку, чтобы результат иногда отличался от правильного на 1?
Или просто написал бы C=A-B ?
В сабже все то же самое.

← →
Германн © (2012-03-15 02:00) [74]

> Sha © (15.03.12 01:40) [73]
>
> > Германн © (15.03.12 01:29) [71]
>
> Ну вот тебе более понятный пример.
> Есть A и B.
> Интегер.
> Надо получить их разность.
> Причем заранее известно, что она всегда точно равна A-B.
>
> Ты бы стал писать для этого функцию?

Если переменные типа Integer - не стал бы. Но GetTickCount возвращает DWORD.
Теперь понял, что ты имел в виду.
Но результат вычитания GetTickCount - Start возвращает Integer не глядя на то, что "GetTickCount возвращает DWORD"!

← →
Sha © (2012-03-15 02:07) [75]

На интегер свет клином сошелся!
Религия запрещает выбирать другие типы!
Даешь программирование без чтения букваря!
Ворнинги не для писателей!

← →
Германн © (2012-03-15 02:25) [76]

> Sha © (15.03.12 02:07) [75]
>
> На интегер свет клином сошелся!
> Религия запрещает выбирать другие типы!

Ты об чём вообще?
Спать!
Рекомендую спать всем, кто не может согласиться с тем, что ему лучше пойти спать, чтобы завтра со свежей головой участвовать на форумах. :)

← →
Sha © (2012-03-15 02:30) [77]

Эх, жаль Юрий Зотов забросил свой культпросвет.
Арифметика была бы актуальной темой.

← →
Германн © (2012-03-15 02:44) [78]

> Sha © (15.03.12 02:30) [77]
>
> Эх, жаль Юрий Зотов забросил свой культпросвет.
> Арифметика была бы актуальной темой.
>

Не ЮЗ забросил. И арифметика тут не не при чём.

> Ты об чём вообще?
> Спать!
> Рекомендую спать всем, кто не может согласиться с тем, что
> ему лучше пойти спать, чтобы завтра со свежей головой участвовать
> на форумах. :)

procedure TForm17.Button1Click(Sender: TObject); var dw1, dw2: DWORD; begin dw1 := $FFFFFFFF; dw2 := $00000001; Label1.Caption := IntToStr(Cardinal(dw2-dw1)); end;

dw1 - твой GetTickCount перед аптаймом.
dw2 - через 2 миллисекунды (как нетрудно догадаться).
Результат - то, что Sha уже чёрти-сколько постов пытается донести.

> то, что Sha уже чёрти-сколько постов пытается донести.
он странно "доносит". я вон пытался сказать что тип важен, надо это учитывать, привел примеры, и на это - "нормальный программист ... " т.д. вместо того чтобы прямо написать. т.к. по факту 98% не понимают представления чисел в компе что такое переполнение, и как делается вычитание (когда то нас учили, это было через сложение... может сейчас уже не так).

> Германн (15.03.2012 02:44:18) [78]

Но она стала бы популярна

> dw1 - твой GetTickCount перед аптаймом.
> dw2 - через 2 миллисекунды (как нетрудно догадаться).
> Результат - то, что Sha уже чёрти-сколько постов пытается
> донести.

а с ним спорят, что ничего не получится при одних dword"ах? вроде бы все согласны

> sniknik © (15.03.12 08:18) [80]
> он странно "доносит".

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

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

← →
han_malign (2012-03-15 09:25) [84]

> я вон пытался сказать что тип важен

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

З.Ы. Кстати - с модулем 256 - насколько помню, засада еще круче - разница двух byte - нихрена не byte(в выражении), т.к всегда сначала к integer приводится.

Так что лучше - от греха - еще и явно приведение типа в выражении делать...

> sniknik © (15.03.12 08:18) [80]

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

> Куда катится мир.

Он уже там.

> han_malign (15.03.12 09:25) [84]

Все немного не так.
Для работы с целочисленными типами длиной меньше или точно 32 бит
32-битный компилятор использует 32-битную арифметику.
Она едина для всех знаковых и беззнаковых типов.
Знаковость числа или результата используется только в 3 случаях
1 при необходимости его расширения до большей длины
2 в операциях сравнения
3 при выводе функциями типа IntToStr

← →
han_malign (2012-03-15 09:40) [88]

> antonn ©

- если нужен абсолютный штамп времени - то нужно использовать соответствующие функции, например GetSystemTimeAsFileTime - возвращает то самое 64-битное целое число(с разрешением 100нс)...

А использование относительных локальных меток в глобальном ресурсе("sql"(с)...) - чревато независимо от разрядности.
Например GetTickCount(64 в том числе) - меняется от машины к машине и сбрасывается после перезагрузки...

← →
han_malign (2012-03-15 09:50) [89]

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

- если бы я на эти грабли лично не напоролся, то не утверждал бы - в BDS - выражение (u32 <{+-} i32) - расширяется(молча) до 64-бит... С 32-битными одного типа(знаковости) - слава богам - все путем осталось...

> han_malign (15.03.12 09:50) [89]

Здесь работает правило 1:
1 при необходимости его расширения до большей длины

> Я предполагал, что у автора топика тип всех переменных dword и проблема в другом.
а я всегда предполагаю, что раз не показано, значит не знает про важность этой части (если она реально важна), и это значит там худшее из возможного.
т.е. не умение выделить из кода значимые части для показа = их не знание, а вовсе не "само собой разумеющееся, поэтому лишнее, ошибки там не возможны".

> han_malign (15.03.2012 09:50:29) [89]

Причем тут SQL, там другие правила и не имеют отношения к Дельфи

> Anatoly Podgoretsky (15.03.2012 10:02:32) [92]

Там ближе к Бейсику, с его "вариантами"

← →
Андреевич (2012-03-15 10:20) [94]

> han_malign (15.03.12 09:40) [88]
>
> > antonn ©
>
> - если нужен абсолютный штамп времени - то нужно использовать
> соответствующие функции

зачем мне говорить что нужно? у меня есть то что есть.

> Например GetTickCount(64 в том числе) - меняется от машины
> к машине и сбрасывается после перезагрузки...

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

← →
han_malign (2012-03-15 10:54) [95]

> Там ближе к Бейсику, с его "вариантами"

- модульную арифметику там никто не отменял ((4294967296 + fresh - ancient) % 4294967296)...

> Здесь работает правило 1:

- гоню я короче, родной раздражающий "W1024 Combining signed and unsigned types - widened both operands" - там никуда не делся(проверил только что). У меня в граблях таки int64 затесался... (старею, маразм крепчает)

А вот с byte таки засада:
if( byte(byte(s[i]) - byte("0")) > 9 )then exit;

Я как чувствовал, что топик нужно помещать в раздел прочее :)

Увлеклись вы ребята вычитанием на квантовом уровне. Еще немного и про искривление времени речь зайдет. Вы же наверняка знаете, что время вблизи массивных объектов течет медленнее? :)

Но ответа на мой второй вопрос так никто и не дал. Ну почти не дали...

Start := GetTickCount; while (FReceivedData = nil) and (GetTickCount - Start < WaitTime) do Application.ProcessMessages;

Что плохого в этом коде? Приложение однопоточное. WaitTime - 5 секунд. Да, лишняя загрузка процессора. Но это всего на 5 сек.

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

> Unknown user (15.03.2012 11:09:36) [96]

Чего плохого? Ну например использование процессора вместо радиатора

> han_malign (15.03.12 10:54) [95]

Как вариант
if dword(s[1])-dword("0")>9 then exit;

> Unknown user © (15.03.12 11:09) [96]

Ужас

>Чего плохого? Ну например использование процессора вместо радиатора

Надо понимать больше недостатков нет?

>Все приложения кушать хотят.

Это забота ОС. Мое приложение не выполняется с realtime приоритетом и давно уже используется вытесняющая многозадачность.

> [100] Unknown user © (15.03.12 11:44)
> Это забота ОС.

Вот будет твоё приложение жрать 100% времени, а тут ещё одному понадобится для расчёта, а не для просто так, но твоё 50% заберёт. Какое из них пользователь отправит в корзину?

> Unknown user © (15.03.12 11:44) [100]
> Надо понимать больше недостатков нет?

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

Например, есть ли недостатки в операторе C:=A-B?
Тебе их все назвать?

А как насчет такого кода? Все так же или что-то поменялось?
while not Application.Terminated do Application.HandleMessage;

Я тут тоже кое-что пишу

i:=-1;

Это правильно?

В последнем посте я спрашивал насчет лишней загрузки процессора. Что поменялось.

1. Ты спрашиваешь до или после того, как посмотрел закладку процессов в диспетчере задач?

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

>1. Ты спрашиваешь до или после того, как посмотрел закладку процессов в диспетчере задач?

Я посмотрел на реализацию Application.HandleMessage, там используется функция WaitMessage. Поэтому такой код

Start := GetTickCount; while (FReceivedData = nil) and (GetTickCount - Start < WaitTime) do Application.HandleMessage;

не должен вызывать лишней загрузки процессора. Значит в таком виде его можно применять? (сообщения в очередь приходят регулярно)

to Sha

Насчет неполного фрагмента кода. Остальная часть не суть важно. Там всего лишь обработка сообщения PIPE message и создание объекта FReceivedData. Все в первичном потоке.

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

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

Жду критики профессионалов.

> [107] Unknown user © (15.03.12 15:48)

Потому что непонятно, что ты делаешь в непоказанном коде и потому, что есть объекты снхронизации, как раз чтобы с ними "забота ОС" была.

Ну и что должны делать объекты синхронизации в однопоточном приложении?

> Почему такой код считается неграмотным?
это попытка сохранить стиль линейного программирования в событийно ориентированной среде...

ну типа, по аналогии, сохранение "стиля бейсика" с нумерацией строк/goto в при написании программ в дельфи. ну вот что плохого? если работает... но на работу не возьмут, если такой код, весь пронизанный goto, на собеседовании покажешь.

> Sha © (14.03.12 19:13) [37]
> Привет братьям по разуму!
> Веселье продолжается. Пил то же бухло?

Разработчики Indy пили, да. А я решил не мучаться и поверил. :)

Чем для меня примечательна данная ветка, что впервые увидел "воинствующих мастеров"! Новая веха, однозначно! :)

Альтернатива GetTickCount Найти похожие ветки