Re: [boost] [integer] Promotion of endian library code from vault

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-28 18:25:51

Neil Mayhew wrote:
> On 24/05/08 05:45 AM Beman Dawes wrote:
>> Neil Mayhew wrote:
>>> The areas that I am interested in seeing more work done on are (1)
>>> making constructors "conditional" and (2) adding a bit-range access 
>>> method.
>>>
>> * Should there be a way (#ifdef? separate class?) to provide an
>> interoperable version that meets C++03 POD requirements, so endian
>> objects can be put in unions? Is that what you mean by (1)?
> 
> Yes, this is what I meant. I was thinking that the most elegant solution 
> would be to have a base class that contains everything except the 
> constructors, and a derived class that adds the constructors (I think 
> this was in a post in 2006).

There are some issues with the base class approach. For it to be a POD, 
it can't have constructors, base classes, or private members. No base 
classes means no arithmetic operations unless they are 100% supplied by 
the class itself. No private members means the non-POD version would 
have to use private inheritance and then forward all operations to the 
private operations.

Messy, but I can't think of any other approach. It might be better to 
just have two separate types, endian and old_endian. (old_endian isn't 
very clear as a name, but calling it pod_endian becomes invalid the 
moment C++0x ships.)

 > The typedefs to big32_t etc. would then be
> #if'd to correspond to the POD or non-POD classes as desired. I think 
> this is better than putting the #if's around the constructors themselves.

Hummm... Seems too obscure. Better to have two sets of typedefs, with 
the C++03 set prefixed by old_ (or whatever better name anyone can come 
up with.)

> 
>> Do you have a proposed design for bit-range access?
> 
> I was thinking of adding methods to read and write the given bits within 
> the value:
> 
> value_type endian::bits(std::size_t offset, std::size_t length) const;
> value_type endian::bits(std::size_t offset, std::size_t length, 
> value_type value);
> 
> Making these template methods with offset and length being template 
> arguments might allow for more compile-time unrolling, but since these 
> methods just do shifting and masking, the compiler will probably do all 
> the needed optimization anyway.
> 
> A better design might be to specialize Bitfield to accept endians, 
> although I haven't studied Bitfield enough yet to see how well this 
> would work.
> 
>> What is the use case or motivation for bit-range access?
> 
> A packed binary structure like the following. The numbers are lengths in 
> bits, and the total length is 24 bits (ie 3 bytes):
> 
> +------------+-----------+------------+
> |  field_a:6 | field_b:4 | field_c:14 |
> +------------+-----------+------------+
> 
> This may look contrived, but I have seen plenty of things similar to 
> this in protocols and data files.
> 
> As part of a bigger struct, this would be implemented using endian::bits 
> as follows:
> 
> struct packet
> {
>     ubig24_t abc;
> 
>     uint_least32_t field_a() const
>     {
>        return abc.bits(0, 6);
>     }
>     uint_least32_t field_b() const
>     {
>        return abc.bits(6, 4);
>     }
>     uint_least32_t field_b() const
>     {
>        return abc.bits(10, 14);
>     }
>     uint_least32_t field_a(uint_least32_t v)
>     {
>        return abc.bits(0, 6, v);
>     }
>     uint_least32_t field_b(uint_least32_t v)
>     {
>        return abc.bits(6, 4, v);
>     }
>     uint_least32_t field_b(uint_least32_t v)
>     {
>        return abc.bits(10, 14, v);
>     }
> };
> 
> If the design used Bitfield instead, there would be one access method 
> for both read and write, which would return by value a Bitfield on abc. 
> However, the method would need to have both const and non-const 
> versions, returning a const and non-const Bitfield respectively. 
> Unfortunately, the Bitfield can't be made a part of the struct because 
> it would take up space, breaking the mapping of the memory. So there 
> would be an inconsistency with the syntax for accessing other (non-bit) 
> fields within the structure, ie with and without parens, but I can live 
> with that.

Interesting. I need to think about that some more.

Thanks,

--Beman