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?