Thread: Changing particular bits and detecting toggled bits

Originally Posted by Nordomus

1. I want to "NOT"(~) particular bits for example in 11001000 I would like to "NOT"(~) 3rd and 4th(counting from right) bit for example. I know I can use bit mask, yes? Even so I would also like to know if there is a way to do that without knowing actual bit word.

What do you mean by "actual bit word"? From what I see, you just need to create the mask (e.g., by left shifting 1), then use xor (i.e., the ^ operator) to toggle the desired bits.

Originally Posted by Nordomus

2. I want to count toggled bits in bit word, for example that from this previous bit word I would get "3" meaning 3 togged bits.

I think the usual recommendation is to peruse this webpage on Bit Twiddling Hacks

Try something like
cout << (int)c << endl;

If you typed in say 3, and get 3 back, you're good.
If you get back say 51, then your inputs are characters, not integers.

The problem is that you are reading in your start and end bit numbers as characters. So if you enter 1 you actually get the decimal value 49. Try this:

Code:

#include <iostream>
using namespace std;
 
int main() {
    char ch;
    int start, end;

    cout << ("Enter character which bits will be inverted:");
    cin >> ch;
    cout << ("Enter starting bit range to change:");
    cin >> start;
    cout << ("Enter last bit range to change:");
    cin >> end;
 
    uint8_t m = ~0;
    m >>= 8 - (end - start + 1);
    m <<= start - 1;

    ch ^= m;
    cout << ch << '\n';
 
    return 0;
}

Originally Posted by Nordomus

Although exercise I was given requires me to use int8_t, is it impossible with that type?

Where is that exercise from?
If it's from a website, post the link.
If it's from a book, give the title of the book and post the exercise verbatim.

To be honest, it seems like some kind of bug to me.
http://www.cplusplus.com/reference/i...perator%3E%3E/

The standard stream extractors don't recognise the fixed width integer types at all, so you're kind of left at the mercy of whatever the implementation decides to give you.

Where the implementation decides that uint8_t has any kind of 'char' flavour to it, then >> will give you '1' rather than 1. Which is rather contradictory given the expectation that all you wanted was a small unsigned integer.

But if your implementation gives you an int flavoured uint8_t, then >> will always give you a 1 (which is what you wanted and expected to begin with).

I couldn't find anything in the standard which indicates that any of the xxx8_t types will always/sometimes be the underlying char type with the same signedness.

Mmm, is it even possible to specialise >> to 'do the right thing' with an xxx8_t without the compiler getting carried away and resolving the typedef down to a bare 'char', where you end up with '1' instead of 1?