On Tue, 2019-05-21 at 19:14 +0000, Era Scarecrow via Digitalmars-d-learn wrote: > […] > I worked on/with bitfields in the past, the limit sizes is more > or less for natural int types that D supports.
Rust bitfield crate and it's macros are the same, the underlying type for a bitfield must be a primitive integer type. Fortunately, Rust has i128 and u128 which is enough for my 112 bit EIT header. Boris Barboris suggested using BitArray and I willinvestigate but the size_t/byte problem would need to go away. > However this limitation is kinda arbitrary, as for simplicity it > relies on shifting bits, going larger or any byte size is > possible depending on what needs to be stored, but ti's the speed > that really takes a penalty when you aren't using native types or > you have to do a lot of shifting to get the job done. > > What's the layout of what you need? I'll see if i can't make > something that would work for you. > > Would be better if you can use a object that breaks the parts > down and you can actually fully access those parts, then just > re-store it into the limited space you want for storage, which > then would be faster than bitfields (although not by much) I found an interesting way forward in the source code of dvbsnoop. It basically uses the byte sequence as a backing store and then has a function to do the necessary accesses to treat it as a bit array. If D's Bit Array can work with bytes instead of size_t then it is exactly what dvbsnoop does (in C) but adds writing as well as reading. The Rust solution using bitfield with a u128 backing it seems to work, but it is all very clumsy even if it is efficacious. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
