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.