[jcxz 220]

А чем ваша операция лучше? CRC все равно нужно хранить. Так почему бы не хранить ее такой, что при проверке структуры вместе с CRC получится 0? Небось, на ноль проверять приятнее.

Может и приятнее, но тратить кучу своего времени на поиски методов вычисления ради такой ерунды как экономия пары байт на сравнении с 0 я бы не стал.

Ну только если уж совсем заняться нечем :biggrin:

[ViKo 1]

Может и приятнее, но тратить кучу своего времени на поиски методов вычисления ради такой ерунды как экономия пары байт на сравнении с 0 я бы не стал.

Ну только если уж совсем заняться нечем :biggrin:

Учили в школе, что данные, дополненные их же CRC, в результате дают 0. Автоматом. Тут не нужно тратить никакую кучу. Но эти манипуляции с перестановкой и инверсией битов потребовали день экспериментов. Все, вопрос решен окончательно. :rolleyes:

[toweroff 1]

А поподробней можно?

Что именно?

[k155la3 26]

Ничего не понял.... Почему не . . .

При приеме "битового" потока (фрейм из канала связи или например с дискового накопителя), параллельно с заполнением буфера идет подсчет в сдвиговом регистре CRC. Для контроля целостности пакета достаточно после прихода фрейма проверить содержимое рег.CRC на 0x0000. (тк фрейм "закрывается" байтами-битами CRC).

Соотв-но нет никаких доп. операций копирования, сравнения итп. (проверка на 0 выполняется в любом случае быстрее).

ps - Это имеет смысл только для скоростной аппаратной реализации.

[dii# 0]

Да и в программной меньше букв писать.

 

Только если выходная добавленная к сообщению CRC инвертируется, в результате получается не ноль, а CRC(0xffffffff). Которая, впрочем, тоже константа, ничем не хуже 0 )