From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-03-14 07:52:38
>I've looked at it. What's wrong with it? I'm calling a "const" member
>function of a temporary object; isn't that OK? I've seen it in some C++
>books, and I use it in crc_fast's constructor. (I have no choice there
>unless I stop using an initializer list.)
All I know is that gcc chokes over it, sorry :-(
I also found it hard to figure out what was going on at first glance - I
prefer to break things up more but that may be personal preference.
>I'll probably turn that to a test in "crc_test.cpp".
Good idea, BTW I think that the way to fix this for VC6, is to use a
function object rather than a free function, but that probably relegates
reflect to an implementation detail.
>You're missing a parenthesis here; there's supposed to be one after
I spotted that afterwards, the problem seems to be that shifting by more
than (or equal to) the number of bits in the value is undefined behaviour -
and this is what messes up Borland C++.
>I don't think there are "standard" CRC parameters. I picked the ones
>as examples because those were the examples used in the Internet papers I
>read. If I use other types, I would have to compute the "123456789"
>reference CRC result by hand as a check; which isn't easy. (I took about
>half-hour doing the 1-bit example that is in the test.)
That isn't the impression that I got - chosing the wrong parameters can
lead to something that's not as strong as it should be - but maybe some
else can jump in here.
>The unsigned-char version should cover the others by implicit conversion.
>For a name, maybe "process"?
Maybe, it's hard to think of a really good one I admit.
>I hope you haven't reported that last bug. If so, take it back. It is
>a bug, because "<:" is a perfectly legitimate digraph! It represents the
>opening square bracket ("[").
Well well, you learn something new every day - just shows how few compilers
support digraphs that only gcc (as far as I know) chokes over this.
- John Maddock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk