Billy Donahue (4) [Avatar] Offline
#1
In Sec 5.1.1 (draft v4), "Objects and memory locations":

"Note how the zero-length bit field bf3 separates bf4 into its own memory location."

The C++ standard [class.bit]/p2 only grants this property to unnamed bit fields, so a bitfield named bf3 wouldn't do this.

"As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary."

The 'bf3' field should be unnamed to accomplish the alignment. Maybe comment out the name?

You also show bf3 taking up a memory location, which doesn't seem right to me. I think 0-length bf's are meant as just an enforced boundary, but without their own storage.
anthony.williams (199) [Avatar] Offline
#2
Billy Donahue wrote:In Sec 5.1.1 (draft v4), "Objects and memory locations":

"Note how the zero-length bit field bf3 separates bf4 into its own memory location."

The C++ standard [class.bit]/p2 only grants this property to unnamed bit fields, so a bitfield named bf3 wouldn't do this.


[intro.memory]p3:

"A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having
nonzero width."

Thus, a zero-width bit-field splits memory locations.

Billy Donahue wrote:
"As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary."

The 'bf3' field should be unnamed to accomplish the alignment. Maybe comment out the name?

You also show bf3 taking up a memory location, which doesn't seem right to me. I think 0-length bf's are meant as just an enforced boundary, but without their own storage.


The unnamed bit-field alignment is a separate effect. Yes, you are right, bf3 isn't a memory location, as it's zero width.
Billy Donahue (4) [Avatar] Offline
#3
anthony.williams wrote:
Billy Donahue wrote:In Sec 5.1.1 (draft v4), "Objects and memory locations":

"Note how the zero-length bit field bf3 separates bf4 into its own memory location."

The C++ standard [class.bit]/p2 only grants this property to unnamed bit fields, so a bitfield named bf3 wouldn't do this.


[intro.memory]p3:

"A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having
nonzero width."

Thus, a zero-width bit-field splits memory locations.

Billy Donahue wrote:
"As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary."

The 'bf3' field should be unnamed to accomplish the alignment. Maybe comment out the name?

You also show bf3 taking up a memory location, which doesn't seem right to me. I think 0-length bf's are meant as just an enforced boundary, but without their own storage.


The unnamed bit-field alignment is a separate effect. Yes, you are right, bf3 isn't a memory location, as it's zero width.



Thanks for the very enlightening discussion! I should have pulled a longer quote from the C++ spec!

from [class.bit]/p2:
"As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary. Only when declaring an unnamed bit-field may the value of the constant-expression be equal to zero."


So, it looks like you're correct that "a zero-width bit-field splits memory locations". But this final sentence states that such memory-location-splitting zero-length bitfields must be unnamed.
anthony.williams (199) [Avatar] Offline
#4
Billy Donahue wrote:
from [class.bit]/p2:
"As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary. Only when declaring an unnamed bit-field may the value of the constant-expression be equal to zero."


So, it looks like you're correct that "a zero-width bit-field splits memory locations". But this final sentence states that such memory-location-splitting zero-length bitfields must be unnamed.


Well spotted. And just in time to fix it before the 2nd edition goes to press too.

Thanks.