Subj : Re: bit field bug? To : borland.public.cpp.borlandcpp From : Andrue Cope Date : Tue Nov 18 2003 09:48 am Thomas Maeder [TeamB], > > Bitfields should be avoided as if they were the spawn of the Devil > > ]:-) > > I think that you are overstating your point. > It comes from experience, but it was a humorous jibe. > As with any C or C++ feature, one should take care not to assume guarantees > that don't exist. But within these guarantees, I don't see why bitfields > shouldn't be used. > From the standard: "Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. ]" and "It is implementation-defined whether a plain (neither explicitly signed nor unsigned) char, short, int or long bit-field is signed or unsigned." Exactly /what/ guarantees do you think there are? The only guarantee that I can see is that you will end up with a structure that has data members. > I have yet to see a non-trivial project that does not, to some extent, depend > on implementation specific features. Do you see a fundamental difference > between bitfields? > Yes. Bitfields offer no guarantees about anything and yet they /sound/ like they have a use. If you are just using them to pack data then they will probably save a small amount of storage. If you are using them to communicate with hardware or represent encoded data they are next to useless. ISTM that these days the only reason to use a bitfield is to represent encoded data or hardware flag register usage. > If I understand the OP correctly, the program to be ported did not contain > the scaffolding; some talking might be in order. > Well I'll note that I missed a smiley of that comment :) The only "scaffolding" I can think of is to have multiple declarations of the same bitfield - one for each compiler. And for a lot of compilers you might have to use a different structure altogether. We used to use them and we suffered the consequences of the change in Borland compilers. IIRC the change occured between BC5 and Builder. In both cases it was 32-bit code - we just wanted to move the project across to a more modern version of the compiler. We ended up writing a class to encapsulate the functionality as there was no practical way that we could determine to correct the structure or to avoid the maintennance perils of duplicated structure declarations. So maybe I'm bitter and twisted when it comes to bitfields but I stand by my assertion that they should be avoided. Thankfully we have a class that encapsulates the functionality now. -- Andrue Cope [Bicester, UK] .