Re: [boost] Re: Comments on crc9

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-03-27 12:45:17

Daryle Walker wrote:
> Is it OK to define template specializations without declaring them,
> especially if you only have a forward declaration for the general version?

I think so.  A definition of a specialization is also a declaration.

> I'm wondering if these could become part of <boost/integer.hpp>?

First things first.

[CRC - code or check]
> I don't think there's any authority on this.  I think I had it as "check,"
> but changed it because my main reference material used "code."

Ok, then stay with "code", but please add a sentence to the documentation
for confused people like me :-)

>  The diagram
> thought unadorned "std" items belonged in a "boost::std" namespace.  I know
> we don't (currently?) use Doxygen, but I wanted to pre-empt any problems
> with future diagrams.  I don't know if its worth it.

So Doxygen's parser has a serious problem with namespace name lookup.
Fix doxygen, or avoid it.

> > - The "const" members in a crc_basic<> mean that the compiler cannot
> > generate a default assignment operator.  Is there any reason why
> > a crc_basic<> object cannot behave like a value (i.e. Copyable and
> > Assignable)?
> 
> No major reason.  I just wanted to protect myself from accidentally changing
> a parameter value.

This, accidentally, means that crc_basic<> is no longer Assignable, so
for example, I can't put it in standard containers :-(

> [SNIP comments about reflection coding]
> I think I changed it because I heard that compilers inline function objects
> better than functions.

This sounds like a very platform-dependent claim which is hopefully
backed by lots of benchmarks on different platforms?  In other words:
This is most certainly not correct in general.

> > - crc_optimal<>::process_byte calls ...::process_bytes which in turn
> > calls ...::process_block.  And sizeof(unsigned char) is guaranteed
> > to be 1, btw.  Wouldn't it be better to call process_block directly?
> 
> I guess.  I've heard that pointer arithmetic is proper only if the original
> pointer and the pointer value after adding are both part of the same array
> (or to one unit past the array).  Is this true?  If so, how should I handle
> single bytes, copy it into an one-element array?

char c = my_single_byte;
process_block(c, c+1);

I think there's a C++ defect report issue about that.

[crc_tabulator]
>   Wouldn't the class-static member be contradictory to the simple
> function idea?  The table cannot be a class-static member of crc_optimal,
> since several versions of crc_optimal will share a table.  (The optimal CRC
> computer has six template parameters, the tabulator only uses three of
> them.)

I've sent you a suggestion in private e-mail.

> > - Reflected input: "etc" is in italics for no apparent reason.
> 
> I thought that these Latin(?)-derived words get italicized.  Does anyone
> have a style manual on this issue?

Uhm, I'm not a native speaker, but it's actually about the first
time I see this.  Any English people out there?

> > - In crc_basic, you're using a bitset<> to store the interim remainders,
> > but the value type is limited to an integral type.  This seems inflexible
> > at least.

> What do you mean by this?

If I've got a 100 bit polynomial for crc_basic, I cannot get the
100 bit remainder back if I don't have a 100 bit "int" type on my
machine.  Or am I overlooking something?  I thought crc_basic<>
wanted to be the general, but slow solution for all your CRC needs?

Jens Maurer