Re: [boost] Re: Help with static data members of class templates

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-02-11 15:02:35

Daryle Walker wrote:
> 
> on 2/8/01 11:02 PM, Jens Maurer at Jens.Maurer_at_[hidden] wrote:
> > 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? 

It's consistent with the general style of the STL.  Assume a
std::vector<unsigned char> (e.g. a network packet) you want to have a
CRC of.  In the style of the STL, it seems most fashionable to say
crc(v.begin(), v.end()).
 
> Since the CRC is applied to a sequence of bits, it won't have a general
> iterator interface. 

Ok.

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

memcpy() also gets a "const void*", so this seems ok.  And I believe we can
cast all pointer types to "const void*".  Do cast to "unsigned char *" in
your code, because the C++ standard has special provisions for aliasing
handling in this case (only).

I have to think about the iterator stuff a little more, but I still believe
it's reasonable to have a 

  template<class Iterator>
  crc::add(Iterator first, Iterator last)

and saying that first and last must be iterators with value_type == char,
signed char, or unsigned char.  (Allow other integral types as well, if you
can handle it.)  "const void*" in addition to that is fine as well, I guess.
Thinking more about crc'ing PODs, you'd certainly want to say
  crc::add(&my_data, sizeof(my_data))
so strike the "not data,length" part of my sentence quoted above.

[std::max] 
> Fixed.  (Did you notice that the fixing the latter item makes the former
> moot?)

Hey, good :-)

> If I make the bit size a run-time parameter, what type is the interim CRC
> supposed to be?

std::bitset   ?

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

gcc simply chokes on the ">>".  "<<" in the other line is ok, curiously
enough.  I'll try with the current CVS version of gcc.

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

Into "ostream.h".   Don't ask, grab STLport 4.0 :-)

>   Or
> stuff like "endl"?  Is there a guarantee that <ostream>, for proper
> compilers, is always #included in <iostream>? 

I've never seen a program fail that includes <iostream> and uses
std::cout for output afterwards.  And it's in all books I know.

Jens Maurer