Anyhow, the point is, limitations of the underlying system aren't excuses for why this syntax isn't implemented. If I can write bitmasks, then so can a compiler, right?
Anyhow, the point is, limitations of the underlying system aren't excuses for why this syntax isn't implemented. If I can write bitmasks, then so can a compiler, right?
If the question is "why isn't bit indexing supported" then "because processors didn't (and don't) support it" is the historically correct answer, whether you like it or not.
Yes some languages actually support this:
http://www.erlang.org/documentation/doc-5.6/doc/programming_...
http://hackage.haskell.org/packages/archive/binary-strict/0.... (I have no idea why this isn't a Functor nor an Applicative Functor, so this is a bad example. and I know 'language features' in pure functional programming is cheating, butm eh)
http://en.wikipedia.org/wiki/Bit_field -- BE WARNED. C bitfields might give you access to bits, but they're still aligned to the boundary of your system (DWORD boundary on x86 for example)
e.g.:
struct a {
unsigned a: 13;
unsigned b: 12;
};
sizeof(struct a) => 4;
in gcc they've got a flag to force structs to their actual bit size: struct a {
...
}__attribute__((packed));Now while this may not be as "convenient" as array-style indexing, it definitely is orders of magnitude better than using bit masks and what not. You could also argue forcing to name each clump of bits (as a bit field struct forces you to) is a good thing, because most of the time the use case calls for something like this, and simply numerically indexing into bits might not be the most readable approach.