Bit fields in protocol buffer

[swapn...@gmail.com]

Hi All,

I have a project in which we are using Protocol buffers (C++ ). The
existing code for uses bit fields.
i would like to know can we use bit fields in .proto file? If yes then
please tell me how to use it?

[Peter K.]

Hi,

I'm not a PB expert, but I don't believe that the basic types support
bitfields.

One way to do it is to just expand each bitfield into a "uint32".

Another way might be to just refer to all the bitfields as "bytes".

We chose the first approach, but YMMV.

Ciao,

Peter K.

[Henner Zeller]

On Fri, May 8, 2009 at 5:50 AM, Peter K. <koot...@gmail.com> wrote:
>
> Hi,
>
> I'm not a PB expert, but I don't believe that the basic types support
> bitfields.
>
> One way to do it is to just expand each bitfield into a "uint32".

fixed32 or fixed64 would be probably better. uint32 is encoded in
variable length which would make bitfields typically larger than
necessary.

[Peter K.]

On May 8, 12:03 pm, Henner Zeller <h.zel...@acm.org> wrote:

> fixed32 or fixed64 would be probably better. uint32 is encoded in
> variable length which would make bitfields typically larger than
> necessary.

Cool! Thanks for the feedback.

Ciao,

Peter K.

[Kenton Varda]

On Fri, May 8, 2009 at 9:03 AM, Henner Zeller <h.ze...@acm.org> wrote:

fixed32 or fixed64 would be probably better. uint32 is encoded in

variable length which would make bitfields typically larger than
necessary.

Depends.  If you are only using the first few (low-order) bits, then uint32 is probably better since it will use fewer bytes.  But, yes, if you use all 32 bits then fixed32 is better.

[Henner Zeller]

On Fri, May 8, 2009 at 2:06 PM, Kenton Varda <ken...@google.com> wrote:
>
>
> On Fri, May 8, 2009 at 9:03 AM, Henner Zeller <h.ze...@acm.org> wrote:
>>
>> fixed32 or fixed64 would be probably better. uint32 is encoded in
>> variable length which would make bitfields typically larger than
>> necessary.
>
> Depends.  If you are only using the first few (low-order) bits, then uint32
> is probably better since it will use fewer bytes.  But, yes, if you use all
> 32 bits then fixed32 is better.

this is why I said 'typically' :) bitfields typically have a random
distribution of bits.

[Kenton Varda]

On Fri, May 8, 2009 at 2:27 PM, Henner Zeller <h.ze...@acm.org> wrote:

On Fri, May 8, 2009 at 2:06 PM, Kenton Varda <ken...@google.com> wrote:
>
>
> On Fri, May 8, 2009 at 9:03 AM, Henner Zeller <h.ze...@acm.org> wrote:
>>
>> fixed32 or fixed64 would be probably better. uint32 is encoded in
>> variable length which would make bitfields typically larger than
>> necessary.
>
> Depends.  If you are only using the first few (low-order) bits, then uint32
> is probably better since it will use fewer bytes.  But, yes, if you use all
> 32 bits then fixed32 is better.

this is why I said 'typically' :) bitfields typically have a random
distribution of bits.

I think we're imagining different things.  I'm imagining something like:

  enum Flags {

    FLAG1 = 1;

    FLAG2 = 2;

    FLAG3 = 4;

    FLAG4 = 8;

  }

  optional int32 flags = 1;  // bitwise OR of Flags

In this case, since only the low-order 4 bytes are used, an int32 is the best choice.  The only time a fixed32 would be more efficient than an int32 is if you used the highest-order four bits.

For arbitrary-size bitfields you'd want to use repeated fixed32 [packed = true], repeated fixed64 [packed = true], or probably just bytes, yes.