Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk