Re: [boost] Any interest in bitstream class?

Date: Mon, 1 Jul 2013 12:47:36 -0500 From: plong@packetizer.com

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