Subject: Re: [boost] Any interest in bitstream class?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-06-29 11:12:42
On Jun 28, 2013, at 7:18 PM, Paul Long <plong_at_[hidden]> wrote:
> On 6/28/2013 3:32 PM, Mathias Gaunard wrote:
>> - how do you overload operator>> or operator<< for your stream?
> I'm not sure what you mean by "how." To date, I have only implemented the input side and so haven't overloaded operator<<. For operator>>, I have overloaded it for various right-hand parameters, including integrals and a few stream manipulators, such as aligng(). The left hand is always an ibitstream reference (which will be extended to bitstream and obitstream references once I support output streams).
I suspect that Mathias is assuming ibitstream derives from istream, so there would be issues selecting the right extraction overload for a UDT.
>> How do you avoid conflicts with text-based overloads?
> Maybe I misunderstand your question, but I'm not even aware of how there can be a conflict. Since these operators are overloaded with left hand of bitstream, ibitstream, or obitstream, they cannot be applied to the std::iostream derivatives. Is that what you mean?
If you derive from the standard library types, then the text based operators can also apply. In that case, any bitstream overload not provided for a UDT will imply use of the text based operator instead. That would mean silently getting text based encoding.
>> - what does writing an int to a stream actually do? Is it the same behaviour as write(&i, sizeof(int)), or does it translate the int to big-endian first?
> Effectively the latter. It does not assume any particular endianness of the platform (for example, it does not blindly copy platform memory to the bit stream) and therefore does not actually "translate" between endians.
Surely you're doing host to network swaps. That means you assume input and output in host order, and transmission in network order. That fits "translation" well enough I think.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk