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