Re: Help with static data members of class templates

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
>> <http://groups.yahoo.com/group/boost/files/crc.zip>.
> 
> 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
> ugly.

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
moot?)

> 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
me.)

> 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