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

[David Malcolm <dmalcolm redhat com>]

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.