468,456 Members | 1,563 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,456 developers. It's quick & easy.

Why shall a non-const reference not be bound to a bit-field?

On page 163 of In the C++ standard document(9.6 Bit-fields), I find
three rules on bit-fields:

Rule 1, "A bit-field shall not be a static member."

Rule 2, "A non-const reference shall not be bount to a bit-field"

Rule 3, "Note: if the initializer for a reference of type const T& is
an lvalue that refers to a bit-field, the reference is bound to a
temporary initialized to hold the value of the bit-field; the reference
is not bound to the bit-field directly."

Visual Studio 2005, however, can correctly compile and run the
following code fragment:

typedef int BIT;

struct BITSET
{
BIT a : 1;
BIT b : 1;
BIT c : 1;
BIT d : 5;
};

class Test
{
public:
static BITSET m; // Violation of the Rule 1
};

BITSET Test::m = {0};

int main()
{
BITSET a = {1, 0, 1};
BITSET& b = a; // Violation of the Rule 2
const BITSET& c = a;
a.a = 0; // After this statement, c.a is also set to 0. Violation of
the rule 3
}

Maybe someone will say: "They are just that Microsoft doesn't abide by
the C++ standard", but what I want know is why the C++ standard
committee made such restrictions. I cannot find enough motivation for
the C++ standard committee to do like this. I think VS 2005 did right
to break these rules.

If you know the whys, please tell me. Thanks in advance.

Jul 6 '06 #1
1 1882
* Lighter:
On page 163 of In the C++ standard document(9.6 Bit-fields), I find
three rules on bit-fields:

Rule 1, "A bit-field shall not be a static member."

Rule 2, "A non-const reference shall not be bount to a bit-field"

Rule 3, "Note: if the initializer for a reference of type const T& is
an lvalue that refers to a bit-field, the reference is bound to a
temporary initialized to hold the value of the bit-field; the reference
is not bound to the bit-field directly."

Visual Studio 2005, however, can correctly compile and run the
following code fragment:

typedef int BIT;

struct BITSET
{
BIT a : 1;
BIT b : 1;
BIT c : 1;
BIT d : 5;
};

class Test
{
public:
static BITSET m; // Violation of the Rule 1
};

BITSET Test::m = {0};

int main()
{
BITSET a = {1, 0, 1};
BITSET& b = a; // Violation of the Rule 2
const BITSET& c = a;
a.a = 0; // After this statement, c.a is also set to 0. Violation of
the rule 3
}

Maybe someone will say: "They are just that Microsoft doesn't abide by
the C++ standard", but what I want know is why the C++ standard
committee made such restrictions. I cannot find enough motivation for
the C++ standard committee to do like this. I think VS 2005 did right
to break these rules.
The above code does not demonstrate any rule breaking.

A static bit-field would be like

struct Foo { static int a : 1; };

And so on -- please post your validation results with the code changed
to use actual bitfields, not structs.

If you know the whys, please tell me. Thanks in advance.
For the why's of the standard, please ask in [comp.std.c++].

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 6 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by David Powell | last post: by
10 posts views Thread by vwd2005eeb | last post: by
22 posts views Thread by Howard Kaikow | last post: by
24 posts views Thread by Dan Jacobson | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.