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