Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Paul Long (plong_at_[hidden])
Date: 2013-07-01 15:46:03

On Mon, 1 Jul 2013 15:24:16 -0400, Daryle Walker wrote:
>> 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"

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