>> So generate them mechanically; I have a program "renumber" that's
>> specifically designed for [this among other related things]
> That doesn't help much -- just add more custom tools and junk.

It helps to the extent that the hand-generated nature of them is a
problem, which from your specifically mentioning it in your message
seemed to be a significant aspect of it to you.

It certainly helps *me*.

>>> I'm beginning to find that one-bit bit-fields are much more elegant
>>> and make my code very easy to understand.
>> And they have plenty of problems of their own, most notably that
>> they make it impossible to manipulate more than one bit (or field,
>> if you use multi-bit fields) at a time.
> That's not quite true -- unions to the rescue!

Okay, merely difficult and awkward, and even more difficult and awkward
if you want to make it nontrivially portable:

union {
	unsigned int as_word;
	struct {
		unsigned int bit_one : 1;
		unsigned int bit_two : 1;
	} s;
} u;

Okay now, I want to set both s.bit_one and s.bit_two at the same time.
What do I do to as_word?

This also comes across to me rather like saying that it's fine to post
to the list in Esperanto, because if you want anyone to understand you,
you can always post a translation.

> In any case it's rare, at least in my experience, to want to
> manipulate multiple bits in APIs like this, and indeed if you do so
> it's much much much better to be 100% clear about what you're doing
> and let the compiler worry about optimisation.

In your opinion.  I for one would really appreciate it if you didn't
state opinions as facts like this (referring to the part after the
"like this"; the part before that is not really subject to debate).
That's opinion on two counts: one is that you have given no metric for
"better", so all we have to go on is opinions; the other is that
somehow bitfields are "100% clear" while masks-and-ints aren't, a point
on which I for one disagree with you.

And given the relative prevalence of the two techniques, it seems I'm
far from alone in that last opinion.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B