When is a good time to use bitwise operations, if ever, while

>>58765232
>When is a good time to use bitwise operations, if ever, while programming?
Setting specific bits in a register or a bitfield or passing multiple flags in one int variable.

>>58765249
but why would I ever need to do that.

>>58765232
Bitwise operators are useful for low-resource programming.

>>58765324
To do those things I just said.

>>58765324
So you do not have to use 64 booleans

>>58765249
if you need to use flags on something, like a material. You can use one int, or 32 bools for them.

>>58765232
When you need to do any of the following...

- Packing smaller values into larger words (like flags, small numbers, etc)
- Performing modulus without a division operator
- Performing multiplication without a multiplication instruction
- Performing n-bit addition without an add instruction
- Checking if a number is odd or even
- Printing binary numbers

Most of the time I just use them for flags and basic pow2 multiplication/division.

>>58765232
Every time I write something for a microcontroller. To set registers and pack/unpack values and stuff.

For non-embeded things mostly just boolean flags.

You could have also asked Google.
http://graphics.stanford.edu/~seander/bithacks.html

>>58765232
When you write 4-bit graphics
like for TempleOS

>>58765232
I've used bit shifting to properly align an integer received in bytes over the network. Can't think of a better way to do it, other than maybe using bit wise and.

>>58765232
It's very common when programming microcontrollers and may very well be required when you're working at the wire level of some protocol (network or otherwise).

>>58765232
Mostly for performance optimizations and low-level hardware interaction.

You can do some neat stuff like the following though.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

static uint64_t pack(uint8_t x,
          uint8_t y,
          uint8_t z,
          uint8_t w,
          uint8_t u,
          uint8_t v,
          uint8_t j,
          uint8_t k);

static void unpack(uint64_t x, uint8_t *xs);

static inline uint64_t mask(uint64_t x)
{
    return x & ~(UINT64_C(1) << 7U |
           UINT64_C(1) << 15U |
           UINT64_C(1) << 23U |
           UINT64_C(1) << 31U |
           UINT64_C(1) << 39U |
           UINT64_C(1) << 47U |
           UINT64_C(1) << 55U);
}

static inline uint64_t high_bits(uint64_t x)
{
    return x & (UINT64_C(1) << 7U |
           UINT64_C(1) << 15U |
           UINT64_C(1) << 23U |
           UINT64_C(1) << 31U |
           UINT64_C(1) << 39U |
           UINT64_C(1) << 47U |
           UINT64_C(1) << 55U);
}

static __attribute__((noinline))  __attribute__((noclone)) uint64_t add(uint64_t x, uint64_t y)
{
    return (mask(x) + mask(y)) | (high_bits(x) ^ high_bits(y));
}

int main(void)
{
    uint64_t x = pack(3, 42, 1, 23, 32, 34, 8, 120);
    uint64_t y = pack(59, 4, 23, 92, 87, 12, 11, 140);

    uint8_t xs[8U];
    unpack(add(x,y), xs);
    for (size_t ii = 0U; ii < 8U; ++ii) {
        fprintf(stderr, "%u\n", xs[ii]);
    }
    return 0;
}

static uint64_t pack(uint8_t x,
          uint8_t y,
          uint8_t z,
          uint8_t w,
          uint8_t u,
          uint8_t v,
          uint8_t j,
          uint8_t k)
{
    return ((uint64_t) x) |
        ((uint64_t) y) << 8U |
        ((uint64_t) z) << 16U |
        ((uint64_t) w) << 24U |
        ((uint64_t) u) << 32U |
        ((uint64_t) v) << 40U |
        ((uint64_t) j) << 48U |
        ((uint64_t) k) << 56U;
}

static void unpack(uint64_t x, uint8_t *xs)
{
    xs[0U] = x;
    xs[1U] = x >> 8U;
    xs[2U] = x >> 16U;
    xs[3U] = x >> 24U;
    xs[4U] = x >> 32U;
    xs[5U] = x >> 40U;
    xs[6U] = x >> 48U;
    xs[7U] = x >> 56U;
}

When dealing with hardware, also bit fields.

>>58765324
You've never seen something like this?

fstream f(fname, fstream::in | fstream::binary);

>>58765232
Embedded C. And when you want to stop being a fag and leaking / wasting memory everywhere.

I have an ancient relay controller board that talks RS-232 and expects bit fields

>>58765572
Why do you unsign your integers randomly

>>58765874
Probably a habit. There's no difference between signed and unsigned left-shift, but with right shift there is a difference; signed right-shift is arithmetic (carries sign bit) while unsigned right-shift is logical.

>>58765232
>When is a good time to use bitwise operations, if ever, while programming?
When encoding or decoding binary file formats and protocols. Try writing a gzip function without them, for example.