On Mon, 1 Jul 2013 15:24:16 -0400, Daryle Walker wrote:
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"
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.
Hmm... What is best? Overloads for unsigned char *, signed char *, and char *, plus their const versions? IOW, must I provide overloads for all six variations?
(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).
I understood. That's why I said, "FWIW."
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.
Okay, great. Paul