Seebs 47dcb5b4a7 Abstract away access to container slices ... On a 64-bit machine, the slices in a Container consume 72 bytes, and the Container itself is 80. But we only use one slice at a time! This patch shifts us to keeping a single slice in the Container, and converting provided slices to and from that type when we want to update it. (It is not safe to access the slice through the wrong type.) We also add some new tests, conditional on a build tag called `roaringparanoia`. These tests will be optimized away entirely by the compiler when the tag isn't present, because the conditionals use a const. These catch possible errors like trying to access the bitmap slice of a non-bitmap container. We also eliminate all direct creation of Container literals, so we can mess with the internals more. (On reflection and study, we decided not to go to the fancier design where references to .n and .typ were also converted to function calls, which would have allowed packing those attributes more tightly, because it was a lot more overhead and a lot of work to keep track of.) There's some circumstances where we appear to have been relying on incorrect guesses about the nature of containers. For instance, in xorBitmapRun, there's logic that makes sense only if the output's a run container, but it's not, it's a bitmap container. This creates strange behavior sometimes, though. Several of these are corrected now.		2019-03-22 16:31:29 -05:00
..
b	Abstract away access to container slices	2019-03-22 16:31:29 -05:00
COPYING	Add enterprise license	2018-05-15 12:20:45 -05:00
enterprise.go	update licensing and NOTICE to reflect btree being moved to roaring	2019-03-05 15:52:32 -06:00