checking bits

[Mark]

lets say i have a char, and i want to check if the 3rd bit is 0 or 1...
how might i do this?

thanks!

 

[Mike Wahler]

lets say i have a char, and i want to check if the 3rd bit is 0 or 1...
how might i do this?

Learn about the bitwise operators,
e.g. | , & , etc.

Also you should used unsigned characters for this.

-Mike

 

[Mike Wahler]

Learn about the bitwise operators,
e.g. | , & , etc.

Also you should used unsigned characters for this.

Alternatively, there's the 'std::bitset' type
from the standard library.

-Mike

 

[Mark]

alright. thanks

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial/bitwise_operators.html

 

[Shark]

alright. thanks

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial/bitwise_operators.html

It will help if you want your answer to be the same regardless of
whether you are on a little endian or big endian machine. What you mean
by the '3rd' bit can have different meanings.

 

[Shark]

alright. thanks

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial/bitwise_operators.html

There is something about bit manipulations using #define here:
http://www.embedded.com/2000/0005/0005feat2.htm

9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear bit
3 of a. In both cases, the remaining bits should be unmodified.

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used. My optimal solution to this problem would
be:

#define BIT3 (0x1
<
<
3)
static int a;

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

 

[Victor Bazarov]

There is something about bit manipulations using #define here:
http://www.embedded.com/2000/0005/0005feat2.htm

9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear
bit 3 of a. In both cases, the remaining bits should be unmodified.

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used. My optimal solution to this problem would
be:

#define BIT3 (0x1
<
<
3)

Whoa!... What's wrong with your newsreading software? And why are
you writing "0x1" instead of simply "1"? Is there a difference?

static int a;

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

And why not have an argument for those functions? Something like

void set_bit3(int &a) { a |= BIT3; }

? Otherwise you only can use those functions to set or clear the
bits in some static object named 'a' in this translation unit...

V

 

[Shark]

And why not have an argument for those functions? Something like

void set_bit3(int &a) { a |= BIT3; }

? Otherwise you only can use those functions to set or clear the
bits in some static object named 'a' in this translation unit...

Well, I simply copied and pasted the code from
http://www.embedded.com/2000/0005/0005feat2.htm . The question was
aimed at programmers for embedded systems. Maybe they like coding this
way! But yes, if i were to write this code, I'd pass an argument and
not use a static int.

 

[Jim Langston]

Whoa!... What's wrong with your newsreading software? And why are
you writing "0x1" instead of simply "1"? Is there a difference?

Personally, I've always wanted to be able to do something like:
#define BIT3 0b00000100
but 0x is as close as you can get.
At least it gives the intent. Which would be the same reason he wouldn't do
#define BIT3 4
because the intent of 4 is not clear.

 

[Mark]

Personally, I've always wanted to be able to do something like:
#define BIT3 0b00000100
but 0x is as close as you can get.
At least it gives the intent. Which would be the same reason he wouldn't do
#define BIT3 4
because the intent of 4 is not clear.

well... the point of defining BIT3 as 4 would be so that it WOULD be
clear when you used "BIT3".. the definition itself doesn't need to be
quite so clear does it? anyways "BIT3" should tell you something about
your intent.

thanks for the help again guys.

 

[Shark]

well... the point of defining BIT3 as 4 would be so that it WOULD be
clear when you used "BIT3".. the definition itself doesn't need to be
quite so clear does it? anyways "BIT3" should tell you something about
your intent.

The meaning of "clear" is not clear here. Do you mean clear as in
clarity or clear as in "clear the bit"?

besides. if we #define BIT3 0b00000100 it assumes that we are working
on a 8-bit number, while in C++ the most basic unit (i could be wrong)
int is at least 2 bytes. With (0x1<<3) we just don't have to tell what
size primitives we are working on. At least that is my guess. Again, I
could be wrong.

 

[Luke Meyers]

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used.

Portable, sure. Type-safe, no. Maintainable, no. Recommendable,
absolutely not.

This is what const is for.

const unsigned char BIT3 = ...

#define BIT3 (0x1<< 3)

So you're starting counting at 0? I love zero-indexing as much as the
next fella, but that's not a reasonable convention when speaking in
terms of ordinal numbers. The rightmost bit is the first bit, not the
zeroth bit. The bit pattern you've produced is 00001000. Surely we
can all agree that's the *fourth* bit?

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

Pretty appalling. Why on earth would someone write a function specific
to one bit position? I'd vastly prefer something like the following
(switching back to zero-index mode):

typedef unsigned char Byte;

inline Byte const nth_bit(size_t n) { return 0x1 << n; }
inline Byte const set_bit(Byte src, size_t n) { return src |
nth_bit(n); }
inline Byte const clear_bit(Byte src, size_t n) { return src &
~nth_bit(n); }

Luke

 

[Luke Meyers]

The meaning of "clear" is not clear here. Do you mean clear as in
clarity or clear as in "clear the bit"?
Clarity.

besides. if we #define BIT3 0b00000100 it assumes that we are working
on a 8-bit number, while in C++ the most basic unit (i could be wrong)
int is at least 2 bytes. With (0x1<<3) we just don't have to tell what
size primitives we are working on. At least that is my guess. Again, I
could be wrong.

You are wrong. The most basic unit is char. See section 3.9.1 of the
standard. That said, the size of a char is not guaranteed to be 8
bits. However, as in mathematics, leading zeros are implicit. That's
why we can say 0x1 rather than 0x0001 or 0x00000001.

Luke

 

[Shark]

Well, once again you are forgetting the context. That question and the
remark I posted was from an embedded programmer's perspective. They
worry too much about how many functions are defined where, how much
memory and crap are assigned.

 

[Luke Meyers]

Well, once again you are forgetting the context. That question and the
remark I posted was from an embedded programmer's perspective. They
worry too much about how many functions are defined where, how much
memory and crap are assigned.

Please don't top-post. I don't know what you mean by "once again," nor
do I see how anything I said is any less applicable to embedded
programmers. On the contrary, defining a *single* function to handle
bit-setting logic rather than a separate function for each individual
bit is exactly the kind of economy embedded systems programmers are
concerned with.

What exactly did you think was wrong about what I said? Would you care
to comment on the relative technical merits of the two solutions?

Luke

 

[Shark]

Please don't top-post. I don't know what you mean by "once again," nor
do I see how anything I said is any less applicable to embedded
programmers. On the contrary, defining a *single* function to handle
bit-setting logic rather than a separate function for each individual
bit is exactly the kind of economy embedded systems programmers are
concerned with.

Oh well, the evils of top posting

I use google to read this ng so I see a nice "thread" of everyone's
replies and OP and sometimes I forget to scroll all the way down and
snip this and snip that because the context is a couple of lines above.
My bad.
This thread on google is here:
http://groups.google.com/group/comp...hread/89d12baaa66af592/cecb0b3712efb881?tvc=2

I made the original quote from this link:
http://www.embedded.com/2000/0005/0005feat2.htm

The particular question 9 reads as follows:

Bit manipulation
9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear bit
3 of a. In both cases, the remaining bits should be unmodified.

and the solution was:

#define BIT3 (0x1
<
<
3)
static int a;

copied verbatim (and source was mentioned in my post). So basically
I've been corrected a couple of times for something I referenced from
another site I only know that the question was aimed at embedded
programmers and maybe someone who actually works as one can tell why
you'd write a macro to set some bit.

I worked on windows ce devices once and there were some weird things
going on all over the code, but the terminal was fast enough (400mhz)
to run badly written mfc apps that leaked memory. There were also some
hardcore programmer who programmed for single chip barcode scanners and
tried to squeeze out every single clock cycle they could. Frankly I
don't know what is the reason behind this #define except that it helps
skip some symbols that a code-with-functions will put in the compiled
code. But as always, I could be wrong. I don't have much experience in
the industry.

What exactly did you think was wrong about what I said? Would you care
to comment on the relative technical merits of the two solutions?

First, I didn't really say you were wrong. I wanted to say that the
posting I made wasn't really a general solution, but was an answer to a
question. The question made a specific demand.: write two functions
that do the following, and the given answer satisfied the requirement.
So I was only pointing out the context.

Regarding the relative merits, I'd like to run away from the battle so
I can fight another day. I just don't have enough experience with
embedded devices to make a comparison. Maybe someone else can shed a
light. I hope the meaning of "is" is "clear" now! Peace

 

[Luke Meyers]

I made the original quote from this link:
http://www.embedded.com/2000/0005/0005feat2.htm

Ah, no wonder. It's not even a C++ article, it's explicitly a C
article. How embarassing!

So basically
I've been corrected a couple of times for something I referenced from
another site I only know that the question was aimed at embedded
programmers and maybe someone who actually works as one can tell why
you'd write a macro to set some bit.

Well, you referenced it; presumably you thought it was somehow
relevant/helpful.

First, I didn't really say you were wrong. I wanted to say that the
posting I made wasn't really a general solution, but was an answer to a
question. The question made a specific demand.: write two functions
that do the following, and the given answer satisfied the requirement.
So I was only pointing out the context.

I could get on your case for disregarding the *relevant* context (a C++
newsgroup, the OP's question etc.), but... nah....

Regarding the relative merits, I'd like to run away from the battle so
I can fight another day.

Werd, and cheers to that. Nice posting with you.

Luke

 

[Shark]

Ah, no wonder. It's not even a C++ article, it's explicitly a C
article. How embarassing!


Well, you referenced it; presumably you thought it was somehow
relevant/helpful.

Yes it is helpful. That example provided a way to set/unset 3rd bit of
an int. And I was referencing it because it is useful to the OP's
purpose.

If you can explicitly set the 3rd bit of the char's copy, and then
compare the result with the original then you can determine if the 3rd
bit is set or not.

int check3rdbit(char a)
{
char a='A';
char b= set3rdbitof(a); //returns a char with 3rd bit set
explicitly
if(a==b) then return THIRD_BIT_IS_SET;
else return THIRD_BIT_IS_NOT_SET;
}

I thought that should be obvious So I wasn't off topic. Plus, if its
explicitly C, what makes it not C++? after all that page wasn't
discussing implicit void* casts to char* and like!!!

I could get on your case for disregarding the *relevant* context (a C++
newsgroup, the OP's question etc.), but... nah....

haha. "Quien en tiempo huye, en tiempo acude."

 

[Luke Meyers]

If you can explicitly set the 3rd bit of the char's copy, and then
compare the result with the original then you can determine if the 3rd
bit is set or not.

int check3rdbit(char a)

Yes, but the point is that it's just silly to hard-code '3' into the
function. What happens when you're interested in bit 4 and bit 7?
Write two new functions? Or write a single function that can handle
any of these cases?

I thought that should be obvious So I wasn't off topic. Plus, if its
explicitly C, what makes it not C++? after all that page wasn't
discussing implicit void* casts to char* and like!!!

Well, C is not C++. The fact that C++ has a C-like subset does not
mean that any "good C practice" is a good C++ practice. Implicit void*
casts to char are one example. Another is the use of #define for
constants. There's absolutely no reason to do that in C++.

Nobody said it was off-topic. Just lousy advice.

haha. "Quien en tiempo huye, en tiempo acude."

Vad sa du?

Luke

 

[Shark]

Yes, but the point is that it's just silly to hard-code '3' into the
function. What happens when you're interested in bit 4 and bit 7?
Write two new functions? Or write a single function that can handle
any of these cases?

Yes I agree with you. I am against the use of c++ preprocessor to
define globals (partly because I read Scott Meyers). But the snippet I
was demonstrating was correct in itself (due to closure, i think.
Question satisfied by answer, and answer is to the point). Meep!

If I were to write something like this for my own use, I'd write
exactly what you suggested. But if I am quoting from another
source....and if they have a good reason for writing a macro instead of
function, then ranting is pointless.

Well, C is not C++. The fact that C++ has a C-like subset does not
mean that any "good C practice" is a good C++ practice. Implicit void*
casts to char are one example. Another is the use of #define for
constants. There's absolutely no reason to do that in C++.

Well, C != C++ obviously, but C is a subset of C++. Just because you
are using a C++ compiler shouldn't mean you must use all the WMDs that
C++ provides. Lets use some polymorphism to relate C and C++, maybe the
most crude way to represent it is this:

class C++ : public C {
// insert stroustrupism here
http://jun.artcompsci.org/miscs/C++_legend.html
// override structs, unions, implicit void* conversions.....
};

so what does polymorphism tell you? if you derive from a base class,
there is an "is-a" relationship between the base class and derived
class. So basically C++ is a type of C. (That is also true for most
compilers, they convert C++ code to C and then use a C compiler to
create an executable.)

Does that mean anywhere you can use C you can also use C++? Sure you
can! Does that mean C++ is C? Open question. Because years of
conditioning by books, professors, and crappy recruiters looking for
"C++ Professionals" has skewed the answer in favor of "no".

Nobody said it was off-topic. Just lousy advice.
Meep!


Vad sa du?

translates into english as "He that fights and runs away, lives to
fight another day."