Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Daryle Walker (darylew_at_[hidden])
Date: 2013-07-01 15:24:16

> Date: Mon, 1 Jul 2013 12:47:36 -0500
> From: plong_at_[hidden]
> 
> On Mon, 1 Jul 2013 08:45:26 -0400, Daryle Walker wrote:
> > Looking at the header file "bstream.h"
> >
> > 1. Can't "uintmax_t" be used for "bitfield"?
> 
> It certainly could be. IIRC, I chose the current definition 
> arbitrarily.
> 
> > 2. Why doesn't "bitbuf" have constructors that take "char *"?
> 
> It... does. Are you asking why bitbuf constructors have char * 
> modifiers, i.e., signed and unsigned? Since the signedness of char sans 
> modifier is implementation dependent, I thought I'd be explicit. Is that 
> a problem? Is it unnecessary?

I mean "char," not "unsigned char" or "signed char."  The "char" type is a strong-typedef for either "unsigned char" or "signed char," which one is implementation-defined.  But since it's a strong-typedef (which only exists for some built-in integer types), you have to give it a separate overload, "char*" is NOT covered by what you currently have.
 
> 
> > 3. The names used for the methods of the Standard text stream family
> > of classes are horrid.
> 
> heh heh heh
> 
> > Since you're not inheriting from the old
> > classes, can you improve the names?
> 
> Sure. However, I thought mimicking stringstream made the classes more 
> familiar and therefore was more beneficial than using my own, possibly 
> more intuitive and consistent names. I'm certainly open to new names, 
> but I'd like to hear what others think. Familiar or intuitive?
> 
> > Importantly, the legacy names
> > used "ImportantName" for the protected implementation functions,
> > forcing the use of "pubImportantName" for the user-facing interface.
> > You should reverse them to protected "do_action" and public "action."
> > (The standard locale facets did this fix.)
> 
> FWIW, as currently planned, locale does not apply to the proposed 
> bitstream library.

That's just an example; I wasn't saying to include a std::locale analogue (somehow).
 
> 
> > 4. The "ibitstream" class has an "operator !" without a Boolean
> > conversion operator?  There's no way to use a stream in a test.  You
> > should create an (explicit) "bool" conversion operator.  Then you can
> > use a stream in built-in Boolean tests (including "operator!"!).
> 
> Okay, thanks! Will do.
> 
> Interesting... VS2012 never overloads operator bool. Instead it 
> provides this functionality via a void * overload in xiobase:
> 
> 	__CLR_OR_THIS_CALL operator void *() const
> 		{	// test if any stream operation has failed
> 		return (fail() ? 0 : (void *)this);
> 		}
> 
> gcc 4.7.3 does the same thing in basic_ios.h for class basic_ios:
> 
>        operator void*() const
>        { return this->fail() ? 0 : const_cast<basic_ios*>(this); }
> 
> but provides an operator bool overload "downstream" in istream/ostream 
> for basic_istream/basic_ostream:
> 
>        operator bool() const
>        { return _M_ok; }
>      };
> 
> VS2012 never provides an overload for operator bool. The proposed 
> bitstream library has neither, though, so I definitely need to fix this.

Before C++11, we had to use the "Safe-bool" implementation, using a pointer (or, better, pointer-to-member) type since it can't sliently be used for regular numeric operations (unlike "bool").
 
> 
> 
> > Also, this operator should be moved to the ios_base/basic_ios class
> > when you create it.  (Make sure to "using" it in the istream, 
> > ostream,
> > and iostream classes.)
> 
> Yeah, I had been thinking about mimicking the stringstream class 
> hierarchy more closely, all the way up to ios_base. Not sure why, 
> offhand, but it must have been done that way for a reason.

You don't need both "ios_base" and "basic_ios," since there's no character and/or traits templating; use a single class as an analogue for both.  This class is meant to hold data that's common to both input and output (and dual) streams.
 
Daryle W.