From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-02-08 17:02:19
Daryle Walker wrote:
> I'm trying to make a CRC class library, and I can't get my latest version to
> link because I'm screwing up defining, not declaring, class-static data
> members of a class template. I put what I have so far (version 0) in file
I've had a look. Here are a few general comments as well:
The CRC interface should be iterator-based, and not "data, length"-based.
I don't like the "::std" stuff, i.e. the explicit "::" prefix. Nobody
will define a "std" namespace within the boost namespace, and it looks
Explicit instantiation of std::max is not necessary in your context
if you use "0u" instead of "0" (for values of type size_t).
bit_count = ::std::max< ::std::size_t >( bit_count, 0 );
is superfluous, because bit_count has type size_t which is unsigned
and thus cannot be < 0.
I understand that CRC is often time-critical and 32bit, so the provided
crc_fast fulfills a real need. However, can we make crc_slow
completely non-dependent on template parameters and have everything,
including the bit size, configured at run-time? This would also allow
for CRC values larger than the largest built-in integral type, if
being properly implemented. For this interface, performance doesn't
matter anyway. All uses of CRC I know (modem, Ethernet, etc.) use an
eternally fixed CRC configuration (bit size, polynomial etc.), so
crc_slow is for experimentation and special use anyway.
Compiles fine with Comeau in strict mode except for two warnings.
gcc 2.95.2 seems to have trouble with the >> in e.g.
static value_type const sig_bits_ = (~(value_type()) >> (limits_type::digits - Bits));
Also, gcc doesn't have <ostream>. Since you're already including <iostream>,
you should forget about <ostream> until gcc gets fixed.
When run, has an unlimited recursion in line
crc_ccitt_fast( data, data_len );
because crc_fast::operator(unsigned char) calls
crc_fast::operator(const void*, size_t)
which calls crc_fast::operator(unsigned char) etc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk