Re: Enum bitfield (Visual Studio Bug or not?)
#include <iostream>
union U {
int Word;
struct {
int bit : 1;
Warning: It is implementation-defined if this is a signed or unsigned
bit-field. (see 9.6/3)
Warning: allocation of the bit-field is implementation-defined (see
9.6/1)
};
};
int main () {
U x;
x.Word = 1;
std::cout << x.bit; // prints -1
x.bit = 1; // not even a warning from GCC
std::cout << x.bit; // prints -1
}
Prints -1-1 with gcc (and hopefully all compilers) because the
bitfield has meaning inherited from C that "bit" has type int yet is
truncated to 1 bit storage. This is what bitfields mean historically.
Then you have a very inaccurate view of all the variation that is
permitted within bit-fields.
Your example can just as well print 01 and the compiler would still be
fully conforming.
Yes I'll just give you that but I don't know of a platform off the top of my
head where it doesn't fill bitfields from the lsb as a frequent purpose of
bitfields is to map over hardware. I have never worked on a platform where
int is unsigned regardless of width (might exist somewhere, people?)
union U {
signed int Word;
struct {
signed int bit : 1;
};
};
int main () {
U x;
x.bit = 1;
std::cout << x.bit;
}
I'd love an example of a platform + compiler where this doesn't print -1
Let's turn the question around: I have an embedded device with a keypad.
The keypad driver sends messages that are encoded as
enum e_key { /* several key ID's ,*/ e_key_last };
struct payload {
bool press : 1;
bool long_press: 1;
e_key key : 6;
};
Is this structure definition sufficient to report presses/releases of
all the 60 different keys on the keypad?
Do you do embedded work or use bitfields in anger? I can only assume that
you think your example packs into a byte. With GCC(3.4.4) on a 32bit Intel
machine sizeof(payload) is 4. You've packed 8 bits into 32. Tidy. You don't
even give the poor embedded compiler the help of placing the e_key at the
start of the bitfield to eliminate extraneous shifts (if the chip is
powerful enough to do the shifts you should have specified a cheaper chip).
Looks like you've been had over by 9.6/1
The compiler in question claims C++03 conformance and does _not_ support
the extension of specifying a base type for enumerations.
The compiler in question is VC9. Microsoft claims VC9 to be standards
compliant? Not in the VC doumentation it doesn't. I quote...
"This reference explains the C++ programming language as implemented in
Microsoft Visual C++. The organization is based on The Annotated C++
Reference Manual by Margaret Ellis and Bjarne Stroustrup and on the ANSI/ISO
C++ International Standard (ISO/IEC FDIS 14882). Microsoft-specific
implementations of C++ language features are included."
And yes VC9 _does_ support the extension for specifying base types. The bool
example in the standard works if you specify unsigned with that compiler
using the extension which you say is not supported... it is even documented.
See
http://msdn.microsoft.com/en-us/library/2dzy4k6e.aspx
Just try..
#include <iostream>
enum e_key { /* several key ID's ,*/ e_key_last };
struct payload {
bool press : 1;
bool long_press: 1;
e_key key : 6;
};
typedef unsigned char u8;
struct payload2 {
u8 key : 6; // enum extends the bitfield to 32 bits on a 32 bit machine
with GCC. Don't use it
u8 press : 1; // don't use bool because you will get bitten by a compiler
at some point despite what the standard says
u8 long_press : 1;
};
int main ()
{
std::cout << sizeof(e_key) << std::endl;
std::cout << sizeof(bool) << std::endl;
std::cout << sizeof(payload) << std::endl;
std::cout << sizeof(payload2) << std::endl;
}
Outputs (on 32 bit Intel machines):
4141 : GCC
4181 : VC6 (oh dear... 8 bytes now and yes lots of people do use it still) &
VC9
4181 : Intel 4.5
This _underlines_ my point that you need to be explicit with bitfields and
ambiguity and "helpful stuff" from the standard is anything but so. If you
don't program C and don't do embedded work then I don't believe you are
qualified to state an opinion on how they do or ought to work. Low level
code is about being explicit - simply minutes of fun can be had with
Motorola processors and Intel CAN chips. Don't water down that explicit
control over bitfields.
I was explicit about signs and type & I got the intended result. I repeat
again that enum should respect this and the sooner the [:type] extension
becomes part of the language proper the better, then it might be usable but
ONLY IF it fully respects the type and not the values.
payload2 is probably what you intended but isn't what you wrote. If you
expect the standard to fix it then you have written completely unportable
code to the vast majority of compilers out there now.
On the other hand, the programmer does not know if the compiler will use
a signed or unsigned underlying type for the enumerations, so there has
The only kind of contract that can decide this between a programmer and
a host of compilers is an international standard.
All the more reason for it to be explicit.
There is no need to guess at all for the compilers.
The type is explicit (foo), but the internal representation of the type
*is not*. You should not rely too much on the information that your
current compiler prefers to use a signed underlying type for
enumerations. The next compiler might prefer unsigned.
I don't guess, I am explicit. I just want the compiler to respect that
without me jumping through hoops. Coercing types is tedious & know your
compiler - remember the compiler is your friend ;)
Consistency is good, but not surprising your users is also good.
I find it surprising that I need an extra bit for my 'unsigned'
enumerations, due to some implementation detail that I don't want to be
bothered with.
Specify them as unsigned then but don't break my code because your laziness
has magical signedness for enums.
Don't hold your breath waiting for that to happen.
The committee has already once affirmed that the behaviour in the
example is defined and as required.
I won't. As it is now, enums are hopeless for bitfields. Microsoft VC9 works
however & I applaud their implementation.
Chris
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]