Re: [boost] [bitfield] Initial bitfield proposal available in thevault

From: Andy Little (andy_at_[hidden])
Date: 2006-03-07 22:42:03

"Emile Cormier"  wrote

> Martin is on to something about using pointers. The pointer already
> "knows" how to access char/short/long integers.

Surely any pointer must be capable of being converted to a void* which means
void* has to know about the extra bits? How does that work?
I would have thought it would be possible to reinterpret_cast (or somehow
convert) the struct to the inbuilt type in these situations isnt it thus fooling
the compiler into storing that type?
The problem I see is that there seems to be two types of pointers here which
doesnt seem to be standard C++ behaviour?

The disadvantage of
> using pointers is their storage space and the indirection to the actual
> data. For example, a system with 50 8-bit registers would require
> 50*sizeof(char*) bytes to store the pointers.

Whereas you've exceeded your 36 bit word so it would seem better to chop it into
words if necessary in this case?

I wonder if this doesnt all come down to platform-dependent padding or
alignment?

> I'd prefer that the bitfield manipulate the data directly, so that, for
> example:

[...]

I think that is more traditional use
...  especially in case of memory mapped ports etc. I would have thought that
being forced to use a pointer (with all the problems pointers entail) would be
very of-putting.

IIRC Theres some outline information about ports and tentative useage in n1666
"Technical report on C++ Performance" Chapter 8 "Hardware Addressing Interface"
which may also be relevant.

regards
Andy Little