Add gem about bit manipulations

[wilzbach]

Also based on #224 (will be rebased) - fixes #130.

[JackStouffer]

I think the gems section needs a navigation redesign. I agree that it's a cool idea to present these ideas in the tour format. But if you're going to have lots of gems as your PRs imply, they shouldn't be accessed from a dropdown. Preferably, the nav would link to a page with the gems grouped into beginner and advanced techniques.

[wilzbach]

I think the gems section needs a navigation redesign. I agree that it's a cool idea to present these ideas in the tour format. But if you're going to have lots of gems as your PRs imply, they shouldn't be accessed from a dropdown. Preferably, the nav would link to a page with the gems grouped into beginner and advanced techniques.

I fully agree - see #269 (restructure chapters) and #52 (vertical left menu).

[wilzbach]

Ready for destruction ;-)

Out of interest does anyone know whether the fact that bitfields are no lvalues is a feature or bug?

vec.x = 2; // OK
vec.x += 2; // ERROR: vec.x is no lvalue

[stonemaster]

@wilzbach I would consider this "as designed". Bitfields need to do bit fiddling internally and if lvalue ought to be supported an opaque type would have to be returned that writes changes back. At first this sounds doable but increased the complexity and maybe hurts performance a little..

[stonemaster]

operators

[wilzbach]

@wilzbach I would consider this "as designed". Bitfields need to do bit fiddling internally and if lvalue ought to be supported an opaque type would have to be returned that writes changes back. At first this sounds doable but increased the complexity and maybe hurts performance a little..

After that I asked on IRC and I was told that there no apparent reason and it's just a missing feature. Hence I opened a feature request:

https://issues.dlang.org/show_bug.cgi?id=16187

(I don't feel strongly about this, so if either the performance or complexity increase turns out to be true, I will weep a bit, but survive).

[PetarKirov]

No, @stonemaster is right - you can't do this without returning a proxy, which would be pessimization for the general case. The only that could help is something like opDispatchOpOpAssign(string member, string op), but for better or worse it doesn't exist.

[PetarKirov]

BTW there several other interesting applications of bit manipulation that I didn't see mentioned:

• using built-in integers for generating all possible subsets of a random access range of fixed size (e.g. 32 or 64)
• using http://dlang.org/phobos/std_bitmanip#.BitArray to store a general set (of any size)
• using http://dlang.org/phobos/std_bitmanip#.bitsSet to get a range of the indexes of the bits that were set, which useful when these indexes are used to index another array and you need to find the first element in it that passes a certain condition: allowed.bitsSet.countUntil!(idx => arr[idx].isOK)
• using std.bitmanip : peak, read to parse any binary format (e.g. network packets, image formats, etc), especially useful when you have described the format with structs (i.e. your not reading it an int at a time).

In my experience bitFields is a more rarely used, but it's still a nice showcase of D's CT power.

[stonemaster]

. Missing at EOL

[stonemaster]

: instead of ;