Boost logo

Boost :

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-06-04 08:28:37


Robert Stewart wrote:
> Terry Golubiewski wrote:
>>
>> It's easy for me to suggest that someone else should change.
>> But what would such a change look like.
>> How about this... (I've ignored alignment)
>>
>> namespace boost { namespace interface {
>
> boost::interface strikes me as a meaningless namespace.

I see several classes as having to do with message passing and communication
interfaces. endian, packed_int, bitfield, dispatcher, etc.
Perhaps just "comm" would be better?

>
>> template<size_t Bits, endian_t Endian=native>
>> class PackedInteger {
>> public:
>> typedef typename boost::int_t<Bits>::least value_type;
>> static const endian_t endianness = Endian;
> [snip]
>> PackedInteger(): { m_storage.fill('\0'); }
>> explicit PackedInteger(value_type x) { store(x); }
>
> Why explicit?

Without the explicit, operations on PackedInteger, such as comparison, will
have ambiguity.

>
>> operator value_type() const { return retrieve(); }
>> PackedInteger& operator=(value_type x) { store(x); }
>> // All the usual integer operations go here.
>> }; // PackedInteger
>>
>> } } // boost::interface

The point of PackedInteger is to provide 3-, 5-, 6-, 7-byte integers. It
really doesn't have anything to do with endianess in intention. However,
when storing the values into memory, you have to decided which endian to
use, of course. I hastily picked the "PackedInteger" name because I believe
it will be used by users that want the smallest integer that will meet their
needs because they are space constrained, such as in messages.

>
> I don't understand the point of "packed" in the name. I'd have expected
> boost::endian to be what Beman has now minus arithmetic operators and then
> boost::endian_integer to be derived from boost::endian with the arithmetic
> operators. That seems simple and obvious. Have I missed something?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk