Не понравилось то, что в одной строке и условие и действие. Читать - не наглядно, править неудобно (например при правке условия съедет форматирование), а отлаживать - совсем никак (ни printf не вставить, ни точку останова не поставить).


Сходство в том, что навалено в одну строку много несвязанных действий.
Так наглядней видно насколько НЕпрозрачным при этом становится код.

С этим можно согласится и я очень часто выношу тело условия в отдельный блок со скобками, но когда есть нечто схожее в ветвях условий (например присвоение одной и той же переменной (crc в данном случае) значения и после if, и после else) и само тело мизерно, то я всегда предпочитаю не раздувать строки. Этот случай типичный, т.к. мизерное тело условия и отлаживать и править не надо. Всё дело вкуса и привычки. А аргументацию всегда найти несложно.

По крайней мере можно так:


printf все еще поставить нельзя, но все остальное мной перечисленное - убирается. в т.ч. не придется изначально вручную с помощью пробелов форматировать строку с else.

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

О CRC
Считая CRC верным можно пытаться восстановить данные, по простой сумме это делать бессмысленно. Далее можно смотреть кодирование/декодирование.
IMHO, CRC это кодирование, но редко делается декодирование с исправлением ошибок.

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

Кодирование и декодирование с исправлением ошибок делается довольно часто - например, все CD-ROM работают только благодаря
этому. Редко можно найти CD-диск, у которого нет хотя бы десятка исправленных C1 ошибок при чтении.
Обычно же их на диск несколько десятков тысяч.

Вы что смеётесь? Вероятность пропуска ошибки CRC16 1 к 2^16, CRC32 1 к 2^32, а для простой суммы на ПОРЯДКИ больше!!!
Вы что ещё до сих пор верите в благотворительность? То что просто заXORить массив намного менее затратно чем посчитать CRC я не спорю, но что-то мне подсказывает, что и вероятность пропуска ошибки примерно (прюс-минус трамвайная остановка, конечно) во столько же раз больше.
За всё надо платить - закон сохранения энергии, однако!


Не, не моё это:-) Я либо в строку форматирую, либо уж по полной программе со скобочками.
К полумерам не привык! Два по сто в одной посуде!:)

Вы полагаете, это аргумент - все так делают, поэтому так делать - правильно?

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

Вероятность пропуска ошибки CRC16 1 к 2^16, CRC32 1 к 2^32 - знаете, как считается?
Всего разных значений у 16 битного числа 2^16, если ошибка равновероятно порождает одно из значений, то вероятность, что она
породит нужное, равна 1 к 2^16.
Это справедливо для многобитной ошибки ( например, от мощной импульсной помехи ), но справедливо как для CRC, так и для прямой суммы.

Исторически CRC появилась по простой причине - в механических телетайпах основной ошибкой были сбои в одном из реле, что порождало
многократные ошибки в одном из разрядов. СRC тут намного лучше прямой суммы.
Но времена те ушли, а CRC осталось...

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

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

Вы хотели сказать, при размерах поражения порядка длины контрольного слова?
То есть когда поражено несколько бит?

Повторюсь - CRC лучше для двойных регулярных ошибок ( когда они в одном разряде ).
В остальных случаях - надо специально разбираться.

Интуитивно понятно, и - спору нет.
При длине блока даже в 256 байт простая сумма будет менее 2^16. Даже при бОльшей длине блока не будет выполняться равновероятность пораждения одного из значений CRC (ситуацию нЕсколько спасёт циклическая сумма). Для суммы: только при очень большой длине блока (строго говоря - бесконечной) это условие выполнится.

При длине блока в 4 байта простая сумма может быть больше, чем 2^16.
Или Вы хотите суммировать байты для получения 16 разрядной контрольной суммы?
Какой смысл - складывать в старший байт переносы?
Вроде при этом надо суммировать 16 разрядные слова.

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

Извините, но Вы так и делаете: получаете сумму значений 76 байт, а не 38 слов (см. функцию void SumCRCNew(unsigned int len) ).

P.S.Поправка: делает это athlon64, но Вы его решения защищаете

С чего Вы взяли, что я настаиваю именно на таком вычислении контрольной суммы?
Я просто спросил - почему CRC лучше прямой суммы.
Вы согласны, что посчитать 16 битную сумму столь же просто, как и 8 битную?
И намного проще и быстрее, чем правильное 16 битное CRC?

Так что скажите для случая 16 битной суммы?

Конечно - проще!


Потому, что при случайных с равномерным распределением данных (общий случай) распределение значений простой суммы далека от равномерного (P.S. при длине блока данных больше 6 можно считать, что имеем близкий к нормальному закон распределения), особенно при "малых" значениях длины блока данных. В CRC с распределением значений - тоже не всё гладко, но гораздо лучше, чем у суммы.