Потестите модуль для расчета CRC8/16/32/64

← →
DVM © (2008-01-06 20:52) [0]

На написание сего подвинула ветка:
http://delphimaster.net/view/2-1199304844/

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

Поэтому данный модуль - попытка упорядочить некоторые из вариантов вычисления CRC на основании достоверной информации, которую удалось выудить из Интернет. Существует значительно больше видов CRC, но доскональное описание мне удалось найти только на некоторые. И то XMODEM CRC пока под вопросом.

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

Пример использования - функция SelfTestModule в конце модуля.

http://dvmuratov.narod.ru/crc.pas

← →
homm © (2008-01-06 21:03) [1]

Зачем в примере вызываются GenerateCRC8TableSMBUS; и подобные? Они не могут сами вызваться в функции расчета?

CRC8Table и подобные — не лучше ли держать указатели на них, а генерить отдельно перед каждой функцией. При входе в функцию расчетп проверяем соответствующий CRC8Table на nil, если пусто, вызываем соответствующий GenerateCRC8Table. Иначе такой бред получается, нужно следить какая до того инициализировалась функция, или все равно каждый раз вызывать (как у тебя). А finalization освобождаем память.

← →
DVM © (2008-01-06 21:13) [2]

> homm © (06.01.08 21:03) [1]

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

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

← →
homm © (2008-01-06 21:16) [3]

> [2] DVM © (06.01.08 21:13)
> Я думал на этим. Дело в том, что создание таблицы занимает
> приличное время и создавать таблицу внутри функции кодирования
> накладно при многократных вызовах функции кодирования.

Прочти еще раз.
При входе в функцию расчета проверяем соответствующий CRC8Table на nil, если пусто, вызываем соответствующий GenerateCRC8Table.

← →
homm © (2008-01-06 21:18) [4]

> [2] DVM © (06.01.08 21:13)
> А в initialization модуля все таблицы помещать неразумно
> ибо тогда бы пришлось для каждого метода делать свою таблицу,
> что при большом числе методов будет расходовать память
> понапрасну.

В initialization помещать не нужно, нужно иництализировать при первом обращении к функции. А своя таблица для каждого метода нужна. Далеко не все они будут инициализированны в реальном приложении, чаще только одна.

← →
DVM © (2008-01-06 21:21) [5]

> Прочти еще раз.
> При входе в функцию расчета проверяем соответствующий CRC8Table
> на nil, если пусто, вызываем соответствующий GenerateCRC8Table.
>

А если он не nil, но таблица сгенерирована другим методом?

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

Я вот сомневаюсь пока.

← →
homm © (2008-01-06 21:23) [6]

> [5] DVM © (06.01.08 21:21)
> А если он не nil, но таблица сгенерирована другим методом?

У каждого метода свой указатель на свою таблицу.

Не сомневайся :)

← →
DVM © (2008-01-06 21:28) [7]

> У каждого метода свой указатель на свою таблицу.

Да, наверное все же так лучше будет.

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

← →
homm © (2008-01-06 21:31) [8]

С CryptoLIB я полагаю, ты уже знаком?

← →
DVM © (2008-01-06 21:39) [9]

> homm © (06.01.08 21:31) [8]

Нет не знаком.
Есть несколько продуктов с таким названием. Какой имеется в виду?

← →
homm © (2008-01-06 21:41) [10]

Оказывается они DCPcrypt называются.

http://www.cityinthesky.co.uk/cryptography.html

← →
DVM © (2008-01-06 21:46) [11]

> Оказывается они DCPcrypt называются.

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

← →
homm © (2008-01-06 21:51) [12]

> [11] DVM © (06.01.08 21:46)

А под «другими методами кодирования» понимались другие разновидности CRC? Тогда я не в тему спросил :)

> под «другими методами кодирования» понимались другие разновидности
> CRC?

Да, именно, CRC. Я неточно выразился. Собственно сами методы и даже их полиномы известны, на той же http://en.wikipedia.org/wiki/Cyclic_redundancy_check полно их.
Но для написания функции данной информации недостаточно.

красоту навожу...
array[0..255] почему не array[byte]

и много лишнего в interface опубликовано... зачем?
я приверженец "дескрипторного" подхода:
type TCRCDescriptor=record Init:TCRCInitProc; Init:TCRCInitProc; end; function CRCInitialize(const CRCType:TCRCType):PCRCDescriptor; procedure CRCProcessData(var Buffer;const Size:integer;var CRCDescriptor:PCRCDescriptor); function CRCGetValue(var CRCDescriptor:PCRCDescriptor;var Buffer;const Size:integer):integer; procedure CRCFinalize(var CRCDescriptor:PCRCDescriptor);

Slym © (09.01.08 7:36) [15]
type PCRCDescriptor=^TCRCDescriptor; TCRCDescriptor=record Init:TCRCInitProc; Data:TCRCDataProc; Value:TCRCValueProc; Fin:TCRCFinProc; CRCSize:byte; CRC:array[0..0] of byte; end; const TCRCType=(crc8,crc16,...);

> array[0..255] почему не array[byte]

я уже это поменял.

> Slym © (09.01.08 07:36) [15]

Мне в принципе тоже нравится.

> я приверженец "дескрипторного" подхода:

Можно вообще классами оформить, только вот надо ли? Да код становится нагляднее и универсальнее, но потом его на мой взгляд в конечной программе использовать менее удобно. Много телодвижений совершать придется для простой операции.

DVM © (09.01.08 10:48) [17]
Да код становится нагляднее и универсальнее
удобнее для вырезки/кражи и кастрации :)
еще и при компиляции лишнее выкинет...

но новичку эта туева хуча методов и процедур как горем импотенту...

Потестите модуль для расчета CRC8/16/32/64 Найти похожие ветки