On Tue, Nov 18, 2008 at 1:26 PM, Benjamin Kirk <[EMAIL PROTECTED]> wrote:
> So I dusted off an old C book and found bit fields, which seem perfect...
>
> Something like
>
> struct PackedState
> {
> bool is_shared:1;
> bool is_remote:1;
>
> unsigned char h_flag:3;
> unsigned char p_flag:3;
> };
> On my machine produces
>
> sizeof(PackedState)=1
>
> Gotta admit, this is the first I've encountered these...
First I'd heard of them as well. From what I'm reading, there is a
lot about bitfields which can be implementation-defined, for example
if you would try to do something like this:
struct T1
{
char m_a : 5;
char m_b : 6;
char m_c : 5;
};
for an implementation using 8-bit chars you may find that
sizeof(T1)==3, instead of 2. Although you have used a total of only
16 bits, m_b goes over the char boundary and so the struct can't be
squeezed into 2 bytes. Granted, this is a contrived example which is
easily fixed by using a short or an int as the underlying data type,
but it's something to keep in mind anyway...we should probably test
out whatever we do on multiple compilers as well as 32 vs 64-bit
architectures just to be sure everything's happy.
As far as I know, the only thing guaranteed by the standard is that
sizeof(char)==1, everything else is implementation-defined but is
usually the same for everybody. For example, I don't think you will
find an implementation which has bytes that aren't 8 bits but
technically it is possible... :)
I've also read anecdotal evidence that the machine code which is
generated to access bitfields can potentially be slower than something
using normal variables. I can't really comment on this, but it seems
plausible, essentially you are gaining storage efficiency at the
expense of slightly increased access times..
--
John
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
