Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?

[Jules Colding <colding omesc com>]

On Fri, 2006-12-01 at 10:18 -0500, David Malcolm wrote:
> On Fri, 2006-12-01 at 11:39 +0100, Jules Colding wrote:
> > On Thu, 2006-11-30 at 12:08 -0500, Matthew Barnes wrote:
> > > On Thu, 2006-11-30 at 11:51 -0500, Jeffrey Stedfast wrote:
> > > > wow, that came out totally wrong...
> > > > 
> > > > using a single bit allows us to extend the structure with more bitfields
> > > > w/o breaking ABI if we find we need to.
> > > > 
> > > > it's akin to having:
> > > > 
> > > > unsigned int sync_offline:1;
> > > > unsigned int unused:31;
> > > 
> > > I'm just curious, but what's the advantage of bitfields over just having
> > > an integer field called "flags" and defining the individual flags as
> > > enum values?  The latter approach has all the advantages that Jeff
> > > enumerated, but it also allows you to work with groups of flags at once
> > > (e.g. masking, copying, etc.).  Perhaps that's not relevant for this
> > > particular case?
> > 
> > As far as I see it there is no difference/advantage at all. It is just a
> > matter of personal coding style if you prefer to handle bit fields
> > instead of bit flags.
> > 
> > I would have preferred a bit flags, but who am I to criticize the style
> > of another coder if there is no factual advantage of choosing one style
> > over the other?
> > 
> A debugger has a chance of deciphering single-bit fields, whereas if you
> do it with #defined masks on a plain uint32, it (probably) can't.


Hmm... good point. At least it seems easier to read while debugging when
you are presented with a name instead of just a plain uint that you must
decipher in your head. So the difference points down to a matter of what
is easier to read when things go south. 

Thanks,
  jules