Walter Bright wrote:
Nick Sabalausky wrote:
Provided that they aren't as crappy as the ones in C, bitfields can be
immensely useful for anything really low-level, like embedded systems,
drivers, firmware, or packed data formats for network or file I/O (ie,
"systems programming" stuff). Anything higher-level then that, though,
and their usefulness certainly does seem to diminish.
I've written a lot of bit twiddling code. Bitfields are not immensely
useful. They're at best a trivial convenience, and often result in poor
code generation as compared with using bit masking operations.
Bit fields are much less useful than they once were...because there's
less need to pack storage tightly. The times I've really wanted to use
named bit fields was when I was packing numbers into a word for export
(usually to disk), or reading conversely. They were, indeed, only a
convenience...but they were a significant convenience. I suppose that
such occasions still arise when one is interacting with foreign code.
But I don't like the syntax that D choose for this feature. (See my
suggestions earlier in this thread as to what I would consider an
improvement.)
I'm much more interested in the general comments about what constitutes
good syntax than in the specific commentary around bitfields.
Perhaps there just *ISN'T* a good way to do templates & mixins. The
syntaxes that I have encountered previously, including D's, have caused
me to avoid all but the simplest cases of using them. I admit that they
appear quite powerful (not really using them I can't say more than
that), but they're UGLY. Well, habituation can change ones aesthetic
sense, so that's not really objective. They look ugly to me at the
present time, as they have for the past year.
An additional problem is that generics are crippled when one of the
basic types is desired as a parameter. Say you want a tree with keys
sorted by uint. It should be possible to just write a generic sorted
tree and specify the key. But Objects and ints have incompatible
comparison mechanisms. The obvious fix to this would be to have the
basic types all respond to, e.g., opCmp. Apparently, however, this
would have significant costs. But the lack of this kind of mechanism
renders templates significantly less useful to me than they would
otherwise be.
As always, these are relatively trivial problems. The major problem is
the lack of libraries, and there doesn't seem to be any way around that
except time. But the division between tango and phobos isn't making
solving that any easier. (I'm afraid that I can't bring myself to trust
tangobos. It always seems to be mentioned with a "you can use this
until you really convert to tango" kind of comment.)
