4 ms·

Or that simply has never had reason to use them so didn’t think to look for them.

PaulHoule 5y ago
I never found C style operators for bit twiddling to be intuitive (compared to assembly) even if you use the left angle brace to shift left.
- the_only_law 5y ago
  While this example is a pretty simple and I agree that a bit shift is a fine solution, I’ve recently been doing work on some bit-oriented HDLC-like protocols I’m convinced Erlang is the only language that can manipulate binary data very well at the bit level.
  - codesections 5y ago
    Out of curiosity, what makes the Erlang syntax so good?
    - the_only_law 5y ago
      It's super easy to construct binaries and bitstrings even when you need to work with award sizes or set bits at weird positions and IMO looks a lot cleaner than a lot of shifting and boolean operators. For example constructing a 8-bit LAPB Information transfer control field might look like: build_info_control(SendSeq, RecvSeq, Poll) -> <<0:1, SendSeq/bitstring, Poll/bitstring, RecvSeq/bitstring>>. Where the `SendSeq` and `RecvSeq` are 3-bit sequence numbers... say one of them is `<<2:3>>` (0b010) and Poll is a single bit (you can see the format here: https://imgur.com/a/9bVBM0W https://imgur.com/a/9bVBM0W). This field would then be stuck into a binary representing the entire frame. This could probably be made a littler simpler, though, as I'm still rather new to Erlang. Note you also do get bit shift operators for cases when they’re an appropriate solution (`bsl` and `bsr`)
      - voidnullnil 5y ago
        (As someone strongly against adding new features to languages,) I've never understood where there would be any need for anything more complicated than list concatenation when assembling bits. In some language with list notation, (++ being concatenation of two lists) you could do something like this: [0] ++ sendSeq ++ recvSeq ++ [poll] say sendSeq was one bit but we still wanted it to take 3 bits: [0] ++ pad 3 sendSeq ++ poll ++ recvSeq given some "pad" function defined in a library The only reason it's "hard" in C is because the operations are induced from what the machine can do efficiently and without "a sufficiently smart compiler".
        macintux 5y ago
        The bit syntax in Erlang is for deconstruction and assignment (pattern matching), not just assembling. The entire language is built around pattern matching to the point where it simply wouldn't exist otherwise, and I assume binary protocol handling was a core requirement when the language was designed since it was created for telecom switches.
        Jtsummers 5y ago
        https://erlang.org/doc/programming_examples/bit_syntax.html https://erlang.org/doc/programming_examples/bit_syntax.html > say sendSeq was one bit but we still wanted it to take 3 bits: > [0] ++ pad 3 sendSeq ++ poll ++ recvSeq In Erlang you could do this to get something padded (or truncated) to the correct size: << 2:3 >> ;; corresponds to the 3 bits <<010>> So you can do something like this to ensure the precise bit size of each field: << 0:1, SendSeq:3, Poll:3, RecvSeq:3>>
        voidnullnil 5y ago
        Yaeh, my point was that it is trivial to define a pad function and call it instead of needing some syntax like Erlang. But now I see there is deconstruction too, which is more arguably useful to take the time to add syntax for.
        spc476 5y ago
        C has the concept of bit fields, and this could be specified as: struct build_info_control { unsigned char : 1; unsigned char SendSeq : 3; unsigned char Poll : 1; unsigned char RecvSeq : 3; }; struct build_info_control control; control.SendSeq = sendSeq; control.Poll = true; control.RecvSeq = recvSeq; The downside of bit fields is that they are implementation specific---you'll have to check the compiler documentation to see if the bits are specified "most significant bit to least significant bit" or "least significant bit to most significant bit" (if that is indeed, important to the problem).
  - dnautics 5y ago
    elixir too, since the underlying technology is the same (arguably it's even easier to read in elixir than erlang). This was super helpful when I was writing a dhcp server.
  - kiadimoondi 5y ago
    Agreed. I was writing a port of the redis protocol to erlang for a personal project that's a server using said protocol as an interface for distributed MPSC "locking", and it was incredibly simple to implement because of erlang's binary strings and pattern matching. Same with base64/hex/etc. manipulations of strings into binary data. I've read a fair bit about how erlang is great for protocols, but hadn't experienced it myself (professionally or personally) until I decided to implement this project.
- mdip 5y ago
  I learned these operators in a college course I took while in High School[0]. I remember I had to make flash cards with examples and memorize throughout the semester. I kept mixing up & and | in comparison/setting. It's still rare that I use anything outside of those two operators in work code, and when I do it tends to get commented as a premature optimization during code reviews. [0] That's not a humble-brag, context provided b/c it's a time, due to 7 hours a day spent taking tests/memorizing and spent also learning algebra through calculus, I was at my absolute peek for learning this sort of thing.
- marcosdumay 5y ago
  The existence of a single pair of operators, instead of one for signed and another for unsigned shifts (with good names) make the operators impossible to remember to me. Ok, the article just made me remember they are not signed. But it's certain that the next time I need them, I won't remember it again.
- CRConrad 5y ago
  > I never found C style operators for bit twiddling to be intuitive (compared to assembly) even if you use the left angle brace to shift left. What I don't get: Are those operators present in C++ too -- wouldn't they clash with the "streaming" thingamajigs, isn't that what "<<" means nowadays?
cm2187 5y ago
Or perhaps for a rarely called function, and which was quicker to write via an inefficient but familiar method rather than spend any time figuring out how to do it in an optimal and correct way.

I never found C style operators for bit twiddling to be intuitive (compared to assembly) even if you use the left angle brace to shift left.

the_only_law 5y ago
While this example is a pretty simple and I agree that a bit shift is a fine solution, I’ve recently been doing work on some bit-oriented HDLC-like protocols I’m convinced Erlang is the only language that can manipulate binary data very well at the bit level.
- codesections 5y ago
  Out of curiosity, what makes the Erlang syntax so good?
  - the_only_law 5y ago
    It's super easy to construct binaries and bitstrings even when you need to work with award sizes or set bits at weird positions and IMO looks a lot cleaner than a lot of shifting and boolean operators. For example constructing a 8-bit LAPB Information transfer control field might look like: build_info_control(SendSeq, RecvSeq, Poll) -> <<0:1, SendSeq/bitstring, Poll/bitstring, RecvSeq/bitstring>>. Where the `SendSeq` and `RecvSeq` are 3-bit sequence numbers... say one of them is `<<2:3>>` (0b010) and Poll is a single bit (you can see the format here: https://imgur.com/a/9bVBM0W https://imgur.com/a/9bVBM0W). This field would then be stuck into a binary representing the entire frame. This could probably be made a littler simpler, though, as I'm still rather new to Erlang. Note you also do get bit shift operators for cases when they’re an appropriate solution (`bsl` and `bsr`)
    - voidnullnil 5y ago
      (As someone strongly against adding new features to languages,) I've never understood where there would be any need for anything more complicated than list concatenation when assembling bits. In some language with list notation, (++ being concatenation of two lists) you could do something like this: [0] ++ sendSeq ++ recvSeq ++ [poll] say sendSeq was one bit but we still wanted it to take 3 bits: [0] ++ pad 3 sendSeq ++ poll ++ recvSeq given some "pad" function defined in a library The only reason it's "hard" in C is because the operations are induced from what the machine can do efficiently and without "a sufficiently smart compiler".
      - macintux 5y ago
        The bit syntax in Erlang is for deconstruction and assignment (pattern matching), not just assembling. The entire language is built around pattern matching to the point where it simply wouldn't exist otherwise, and I assume binary protocol handling was a core requirement when the language was designed since it was created for telecom switches.
      - Jtsummers 5y ago
        https://erlang.org/doc/programming_examples/bit_syntax.html https://erlang.org/doc/programming_examples/bit_syntax.html > say sendSeq was one bit but we still wanted it to take 3 bits: > [0] ++ pad 3 sendSeq ++ poll ++ recvSeq In Erlang you could do this to get something padded (or truncated) to the correct size: << 2:3 >> ;; corresponds to the 3 bits <<010>> So you can do something like this to ensure the precise bit size of each field: << 0:1, SendSeq:3, Poll:3, RecvSeq:3>>
        voidnullnil 5y ago
        Yaeh, my point was that it is trivial to define a pad function and call it instead of needing some syntax like Erlang. But now I see there is deconstruction too, which is more arguably useful to take the time to add syntax for.
      - spc476 5y ago
        C has the concept of bit fields, and this could be specified as: struct build_info_control { unsigned char : 1; unsigned char SendSeq : 3; unsigned char Poll : 1; unsigned char RecvSeq : 3; }; struct build_info_control control; control.SendSeq = sendSeq; control.Poll = true; control.RecvSeq = recvSeq; The downside of bit fields is that they are implementation specific---you'll have to check the compiler documentation to see if the bits are specified "most significant bit to least significant bit" or "least significant bit to most significant bit" (if that is indeed, important to the problem).
- dnautics 5y ago
  elixir too, since the underlying technology is the same (arguably it's even easier to read in elixir than erlang). This was super helpful when I was writing a dhcp server.
- kiadimoondi 5y ago
  Agreed. I was writing a port of the redis protocol to erlang for a personal project that's a server using said protocol as an interface for distributed MPSC "locking", and it was incredibly simple to implement because of erlang's binary strings and pattern matching. Same with base64/hex/etc. manipulations of strings into binary data. I've read a fair bit about how erlang is great for protocols, but hadn't experienced it myself (professionally or personally) until I decided to implement this project.
mdip 5y ago
I learned these operators in a college course I took while in High School[0]. I remember I had to make flash cards with examples and memorize throughout the semester. I kept mixing up & and | in comparison/setting. It's still rare that I use anything outside of those two operators in work code, and when I do it tends to get commented as a premature optimization during code reviews. [0] That's not a humble-brag, context provided b/c it's a time, due to 7 hours a day spent taking tests/memorizing and spent also learning algebra through calculus, I was at my absolute peek for learning this sort of thing.
marcosdumay 5y ago
The existence of a single pair of operators, instead of one for signed and another for unsigned shifts (with good names) make the operators impossible to remember to me. Ok, the article just made me remember they are not signed. But it's certain that the next time I need them, I won't remember it again.
CRConrad 5y ago
> I never found C style operators for bit twiddling to be intuitive (compared to assembly) even if you use the left angle brace to shift left. What I don't get: Are those operators present in C++ too -- wouldn't they clash with the "streaming" thingamajigs, isn't that what "<<" means nowadays?

cm2187 5y ago

Or perhaps for a rarely called function, and which was quicker to write via an inefficient but familiar method rather than spend any time figuring out how to do it in an optimal and correct way.