мда. оптимизитары хреновы. я помню, долго веселился, когда обнаружил, что от перестановки местами полей разных типов в записи, меняется размер записи. понятно там, packed record'ы есть, в семёрке вообще выравнивание по границе можно руками выставлять, но всё равно: нафига, спрашивается? а недавно наткнулся на статью, где какой-то мудрый чувак советует за счёт таких перестановок "минимизировать размер приложения". у него в примере размер класса в памяти уменьшился на 8 байт. дескать, если у вас экземпляров класса ТЫЩИ, то по 8 байт на ТЫЩУ, это ж целых 8 КИЛОБАЙТОФФ!!! да хоть мегов восемь, для прикладного программирования, особенно в корпоративных разработках, читабельность кода намного дороже размера экзешника.

а другой фрукт как-то с пеной у рта мне доказывал, что Fields [0] работает быстрее, чем FieldByName. в принципе - да. быстрее. на доли миллисекунды. но доказывать ему, что по сравнению со скоростью доступа к базе это просто [censored34! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], и ничего он на такой "оптимизации" не выйграет, а вот в коде может напороть как с добрым утром, - бесполезно.

и куда этот мир катиться?

З.Ы.
    Vit, сорри за оффтоп.

Цитата(p0s0l @ 30.9.2003, 22:14)

Тут такой вопрос появился: Т.к. Low(i) = -2147483648 (это выяснилось с помощью writeln(n1)), по смыслу эти два цикла д.б. одинаковыми: for i := -2147483648 to 2147483647 do; // [Error] Overflow in conversion or arithmetic operation for i := Low(i) to 2147483647 do; // OK ?

Gute frage...

А вот еще просто замечательный вопрос:

Код

for i := High(i) downto Low(i) do; // FOR or WHILE loop executes zero times - deleted  for i := Low(i) downto High(i) do; // Ok !!!!

И просто шикарно выглядит генерируемый код для "OK !!!!":

Код

mov     eax, 0FFFFFFFEh @@1:                inc     eax                jnz     @@1

No comments...

Cashey может претендовать на звание багооткрывателя Если только это не задокументировано уже...

Цитата

а другой фрукт как-то с пеной у рта мне доказывал, что Fields [0] работает быстрее, чем FieldByName. в принципе - да. быстрее. на доли миллисекунды. но доказывать ему, что по сравнению со скоростью доступа к базе это просто [censored34! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], и ничего он на такой "оптимизации" не выйграет, а вот в коде может напороть как с добрым утром, - бесполезно. и куда этот мир катиться?

Ну знаешь, ситуации бывают разные. У меня была такая: одна редиска вскрыла прогу разрабатываемую фирмой, где я работаю, и было принято решение срочно заменить кодировку (прога бухгалтерская, поэтому обновляется много раз в течении года). и вот мне - автору журнала учета- было приказано перерегистрить наших официальных пользователей автоматически, сам кодировщик зделали программеры создавшие прогу, поэтому он был на FOXPRO в DLL и работал в моем журнале (Delphi 5) через OLE Server. Так вот пришлось писать цикл, вытаскивать из базы Paradox (через драйвер BDE) все записи (> 50.000) прогонять их через OLE и загонять обратно. У меня тогда еще старый комп стоял (C266, 64Mb). Вот и думай кокого было, а я все делал с помощью fielbyname и здесь замена на field[0] было оправдано (даже очень)

Цитата

Cashey может претендовать на звание багооткрывателя  Если только это не задокументировано уже...

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

Согласен с Cashey. У меня тоже бывало такое, что нужна была скорость в БД - фильтрация таблицы из 20000 записей должна была делаться вручную, т.е. каждая запись проверялась моей процедуркой - я для каждого поля создавал отдельный компонент, скорость получилась приличная. Кстати, так читать даже легче прогу:
Table1.FieldByName('Street').AsString := ...
и
tb1Street.Value := ...

А.... ээээээ.... причем здесь оптимизация? Есть явный прокол в генерации кода, а если бы генератор не был оптимизирующим, то он бы нам НЕ сообщимл "FOR or WHILE loop executes zero times - deleted" и ....... (дальше каждого должен быть свой набор матюгов ).

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