Handling a lot of boolean fields

[Archos]

I've a struct with 15 boolean fields besides of another kind of
fields. Would be better if those boolean fields were managed like

type check uint16

const (
isFoo check = 1 << iota
isBar
...
)

although it it's most verbose during checking:

if check&isFoo != 0 {
...
}

[Michael Jones]

It would be simpler to have a new type, "bit", that packs wonderfully
(8 to a byte ;-)

I know we don't have conversions so there would be no way to have a
bit take true or false, but at least you could assign 1 or 0.

--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1
650-335-5765

[kortschak]

It could conceivably take true or false as a constant (the same way as untyped consts can be assigned to floats or ints) and be convertable from bool (just as rune <-> byte for ASCII values or string<->[]byte) though. Not suggesting that this be done, but there is a way to get the sugar if you wanted it.

[si guy]

const (
FALSE iota
TRUE
)

Something about this makes me laugh

[Ugorji Nwoke]

IMO, If you're concerned about the size of the struct in memory, then having flags and checking bits may have some advantages (since a bool takes up one byte). From a user call site POV, I think having booleans is better. 

(I went through this just recently, having a uint holding flags, and finally changing to have multiple booleans because the API was not easier at the call site).

In my past life, we used BitSet in java where we wanted to keep a lot of bits together in one "object". It basically used a slice of longs to store bits, and had methods for setting and checking if some bits were set. The code is super simple to implement if you need it i.e. []byte, and given an offset, possibly expand []byte and set/check the appropriate bit in that byte.

OR do something super simple and custom like:

  type MyFlags [10]byte //supports up to 80 flags, etc. Change n up or down for more/less flags.

  func (MyFlag) IsSet(index i) //i <= 80

  func (MyFlag) Set(index i) //i <= 80

As with anything, use what best works for your code leveraging what the platform provides.

P.S. I haven't tried this ... but you get the idea.

[Peter S]

You could (mis)use Int from math/bin in a manner similar to BitSet; it has Bit() and SetBit().

http://golang.org/pkg/math/big/#Int.Bit
http://golang.org/pkg/math/big/#Int.SetBit

Peter

[Michael Jones]

If we had 'bit' then we would implicitly have arrays:

var flag [32]bit

would start with flag[0] .. flag[31] set to zero.

They would naturally pack into four bytes.

[Peter S]

That would indeed be very neat... The problem would be whether to allow bit-slices as well. Not allowing them would break the existing symmetry between arrays and slices, and allowing them would make the language more complex (probably unnecessarily, unless someone has good use cases for them which are not covered by Int in math/big).

[Michael Jones]

I know of no bit addressable computers, ever, other than the Intel
8051 which allows 16 bytes of bit addressable memory, and allows bit
access in registers, but that is a rare and slight exception to a
universal truth. Bytes are as good as it gets

Slices are easy once you deal with the real "problem" of bits and bit
arrays -- you cannot take the address of a bit using the same
monolithic pointer used elsewhere. Instead, such a sub minimum
addressable unit has a two component address, one of:

address of start byte : bit number (S:B) :
bit is ((*(S + B>>3)) >> (B & 0x7)) & 1

address of containing byte : bit number (S:B):
bit is (*(S) >> B) & 1

In full generality this is the size of a pointer plus 3 bits. (or more
bits if bigger chunks are used than bytes. You could allocate bit
objects in lower space (easily with 64 bits) and use the three
high-bits for bit-in-byte but that's starting to get complicated.

Once you decide on this, the slices work naturally.

[minux]

On Sun, Apr 22, 2012 at 9:26 AM, Michael Jones <m...@google.com> wrote:

I know of no bit addressable computers, ever, other than the Intel
8051 which allows 16 bytes of bit addressable memory, and allows bit
access in registers, but that is a rare and slight exception to a
universal truth. Bytes are as good as it gets

In embedded computing, bit addressable register is pretty common.

In fact, ARM Cortex-M series even introduce a bit-band mapping for peripheral memory

space and internal ram space[1].

(each bit is mapped to a word in the corresponding bit-band region, so that bit flags are

easier to use without special compiler support)

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html

[Thomas Bushnell, BSG]

I would express it as clearly as possible...I.e., use booleans. Let the compiler pack it if it wishes; nothing prevents it.

Except in extremely rare cases, especially on modern computers, I would advise always erring on the side of clarity.

Thomas

[Michael Jones]

Agree -- though like tail call optimization, having a contract with
the compiler would make all the difference to the developer.

--

[Jan Mercl]

On Sunday, April 22, 2012 7:58:32 AM UTC+2, Thomas Bushnell, BSG wrote:

I would express it as clearly as possible...I.e., use booleans. Let the compiler pack it if it wishes; nothing prevents it.

I would have thought that's not possible because of http://golang.org/ref/spec#Size_and_alignment_guarantees which are all >= 1. To my surprise, bool is not listed there (actually only numeric types are), so as long as the address is not taken, it seems bools can be in packed freely.

[Graham Anderson]

On Saturday 21 Apr 2012 22:58:32 Thomas Bushnell, BSG wrote:
> I would
> advise always erring on the side of clarity.

+1

Go spec + readable code is a very compelling reason to use this language in
the first place.

[Jason Couture]

Why not just make a bit field type?

type BitField struct {
       data uint16
}

func (b *BitField) Get(bitnum uint) bool {
       return ((b.data & uint16(1<<bitnum)) != 0)
}

//This is not how this function should be written, I just don't feel
much like thinking today.
func (b *BitField) Set(bitnum uint, value bool) {
       if value {
               b.data = b.data | uint16(1<<bitnum)
       } else {
               if b.Get(bitnum) {
                       b.data = b.data ^ uint16(1<<bitnum)

[Hotei]

If you're interested in a package that allows more than one words worth of bits you can check out my package at github:

https://github.com/hotei/bits

I originally designed it for a "dirty buffer tracker" where I use it to track anywhere from hundreds to hundreds of thousands of dirty buffers that occasionally need "refreshing".  It looked useful so I extracted it to a package.  It has a test section and a benchmark section for those interested in same.

[robin...@gmail.com]

I know I am making a late entry to this discussion, but I dont see the problem with creating generic functions for the bitwise operations if you think they decrease readability. 

An example: http://play.golang.org/p/pbZybh920X

It works perfectly, is readable, and has good performance and memory footprint. The con is that it's not extendable to more than 64 flags per field, but it covers the most common use cases.