"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