468,456 Members | 1,719 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 did the C++ standard committee make such restrictions on bit-fields?

On page 163 of the C++ standard document(9.6 Bit-fields), I found 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 make
such restrictions. I'm not able to 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
5 1582
TB
Lighter skrev:
On page 163 of the C++ standard document(9.6 Bit-fields), I found 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:
<snip>

It can sometimes take a few minutes for a post to propagate throughout
the network and become visible, so please wait a while before you
repost everything. No need to post 3 copies within 10 minutes.

--
TB @ SWEDEN
Jul 6 '06 #2
Lighter wrote:
On page 163 of the C++ standard document(9.6 Bit-fields), I found 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 make
such restrictions. I'm not able to 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.
The standard is refereing to a bit field, not a struct containing bit
fields, which is what you have here.

BIT a : 1;

is a bit field.

Also, don't post the same thing three times!

--
Ian Collins.
Jul 6 '06 #3
I'm very very sorry for my ignorance of the repeated posts. I always
removed the original post before I repost, I didn't know the server
would keep the copies.

Thank you all for your timely reply. That's good. I am clear now.

Jul 6 '06 #4
I'm very very sorry for my ignorance of the repeated posts. I always
removed the original post before I repost, I didn't know the server
would keep the copies.

Thank you all for your timely reply. That's good. I am clear now.

Jul 6 '06 #5
Lighter wrote:
I'm very very sorry for my ignorance of the repeated posts. I always
removed the original post before I repost, I didn't know the server
would keep the copies.

Thank you all for your timely reply. That's good. I am clear now.
But you still replied twice...

--
Ian Collins.
Jul 6 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by skoco | last post: by
71 posts views Thread by Christopher Benson-Manica | last post: by
29 posts views Thread by David Eng | last post: by
43 posts views Thread by Steven T. Hatton | last post: by
132 posts views Thread by Frederick Gotham | last post: by
20 posts views Thread by Chor Lit | last post: by
270 posts views Thread by jacob navia | last post: by
32 posts views Thread by Stephen Horne | 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.