Despite the documentation in the library reference manual, a nameless field cannot be set as the "last" entry in a list of bit fields: This code: ========== module scratch; import std.bitmanip; version(unittest) { void main() { } } struct S { mixin(bitfields!( uint, "some", 4, uint, "", 4 )); } ========== Produces this error: ========== $ dmd -unittest -run bronze/util/scratch.d bronze\util\scratch.d(14): Error: variable scratch.S.some conflicts with function scratch.S.some at bronze\util\scratch.d(12) ========== Strangely, leading nameless fields are okay. This code compiles fine: ========== struct S { mixin(bitfields!( uint, "", 1, uint, "", 1, uint, "some", 4, uint, "last", 2 )); } ==========
Ahh, I hit this myself a few days ago. My fields are now named "ignore1", "ignroe2", etc. I thought it was maybe my mistake because I was trying to do something like... struct Instruction{ union{ mixin(bitfields!( ubyte, "imm", 4, ubyte, "rot", 4, ubyte, "", 4, ubyte, "opcode", 4)); // Read the bottom 8 bits as a longer immediate mixin(bitfields!( ubyte, "imm8", 8, ubyte, "", 8)); } } And was unsure about bitfields support within union type structures.
Entertainingly, this is the "real" code I was trying to work on: union Instruction { ushort raw; // Basic opcode + data mixin(bitfields!( Opcode, "opcode", 7, uint, "rest", 9)); Is it only people working with opcodes that want to use bitfields? :) Also, I think I'm going to request that repeated bitfield definitions be allowed if they are identical - I'd like to redeclare "opcode" rather than "".
I was unable to duplicate this problem, so either DMD already fixed some bug, or my patches already fixed it. > And was unsure about bitfields support within union type structures. Inside a union it should be fine, as only one variable is made that's accessible (although enums are present). If those give you trouble, you can use bitfieldsOn (in my branch) to specify a specific variable elsewhere that you want to use for your source. Once the pull is accepted I'm changing this status to resolved.
@Era: what pull are you referring to?
(In reply to comment #4) > @Era: what pull are you referring to? He seems to have been referring to pull requests: 1045, 719, 734 and 740 (all closed unmerged.) This seems to have been fixed prior to 2.060, I'll end up writing a unittest to make sure it stays that way.