From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-10 13:46:43
on 2/8/01 11:02 PM, Jens Maurer at Jens.Maurer_at_[hidden] wrote:
> 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 did change the interface (to two constant-void pointers), but why? What
does an iterator-based interface gain us? I guess that it could help if the
length is larger than the maximum std::size_t value. (But isn't std::size_t
defined not to do that for a particular architecture?)
Since the CRC is applied to a sequence of bits, it won't have a general
iterator interface. I considered an interface (a member function template)
taking two T* objects, but the const-void* indicates better that it should
get a low-level bit-bucket and non-expert users shouldn't be tempted to put
non-POD items in there.
> 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
I started the "::" stuff before the "std" from seeing a sample Doxygen
output of some Boost files. The documenting program mistakenly saw some
instances of un-"::"'d qualifications of "std" as being of the nonexistent
"boost::std" namespace. (The mistake is only in Doxygen's analyzer; the
compiler got the namespace stuff right.)
> 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.
Fixed. (Did you notice that the fixing the latter item makes the former
> 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.
If I make the bit size a run-time parameter, what type is the interim CRC
supposed to be? I would have to use an arbitrary-precision arithmetic type,
which I haven't finished yet.
> Coding issues:
> 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));
What's the problem? Is there a fix/workaround? The constant is supposed to
be the lower-"Bits" bits set.
> Also, gcc doesn't have <ostream>. Since you're already including <iostream>,
> you should forget about <ostream> until gcc gets fixed.
GCC doesn't have <ostream>?! Where does it put its stream definitions? Or
stuff like "endl"? Is there a guarantee that <ostream>, for proper
compilers, is always #included in <iostream>? I know that <iostream>
contains external declarations of the basic stream objects; does it need
the full definitions for those classes (I know you don't for pointer
objects), which are in <ostream> and <istream>? (If the answer is no, then
<iostream> could just #include <iosfwd> instead, which wouldn't work for
> 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.
Fixed that right before seeing this message.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk