How to implement this?

T

Till Crueger

Use a variable of char type and each bit of it indicates if a button is
pressed or not. For example,

0010010

tells that 3rd and 7th buttons are pressed down.

How to set bit to to 1 or 0 in C++? How to check to see if the 6th bit
is set to 1 or 0?

Define the Flags for the buttons you need. Something like

#define FIRST 1
#define SECOND 2
#define THIRD 4

[...]

then you can simply do an AND with the variable you want to check, and see
wether the result is zero or not. For setting you can do an OR.

Alternatively to the defines you could produce an array which will contain
the appropriate flags.

Till
 
A

ad

Use a variable of char type and each bit of it indicates if a button is
pressed or not. For example,

0010010

tells that 3rd and 7th buttons are pressed down.

How to set bit to to 1 or 0 in C++? How to check to see if the 6th bit is
set to 1 or 0?

Thanks!
 
J

John Harrison

ad said:
Use a variable of char type and each bit of it indicates if a button is
pressed or not. For example,

0010010

tells that 3rd and 7th buttons are pressed down.

How to set bit to to 1 or 0 in C++? How to check to see if the 6th bit is
set to 1 or 0?

Thanks!

x |= (1 << n); // set bit n to 1

x &= ~(1 << n); // set bit n to 0

if (x&(1 << n)) // true if bit n is 1

john
 
J

John Harrison

Actually to me that looks like the 1st and 4th buttons

0000001 // zeroth button
0000010 // first button
0000100 // second button

etc.

I'm not trying to quibble semantics, but read my previous reply in light of
how I define zeroth bit, first bit, second bit etc.

john
 
S

Siemel Naran

#define FIRST 1
#define SECOND 2
#define THIRD 4

Why not const int?

then you can simply do an AND with the variable you want to check, and see
wether the result is zero or not. For setting you can do an OR.

How about flipping a bit? For that we can use exclusive or, for which the
symbol is ^. Please let me know if this is correct.

// suppose a byte is 4 bits, CHAR_BITS = 4
int a=0x03 // 0011
a ^= 0x01; // 0011 ^ 0001 = 0010
a ^= 0x01; // 0010 ^ 0001 = 0011
 
O

Old Wolf

John Harrison said:
x |= (1 << n); // set bit n to 1

x &= ~(1 << n); // set bit n to 0

if (x&(1 << n)) // true if bit n is 1

These should probably be 1UL instead of 1, because of the case where
x is [unsigned] 'long' and sizeof(long) > sizeof(int).
 
R

Rolf Magnus

Siemel said:
Why not const int?

Why not enum?
How about flipping a bit? For that we can use exclusive or, for which
the symbol is ^. Please let me know if this is correct.

// suppose a byte is 4 bits, CHAR_BITS = 4

CHAR_BITS is never 4. It is at least 8.
int a=0x03 // 0011
a ^= 0x01; // 0011 ^ 0001 = 0010
a ^= 0x01; // 0010 ^ 0001 = 0011

Yes, that's correct.
 
K

Kevin Goodsell

Rolf said:
CHAR_BITS is never 4. It is at least 8.

CHAR_BITS could be 4. But CHAR_BIT (at least, the CHAR_BIT that is
#defined in <climits>) cannot be. ;)

I'm sure he knows it cannot actually be 4. I believe he was just
simplifying.

-Kevin
 
S

Siemel Naran

Sure, that makes sense too. For generic names like FIRST, I thought of ints
first. For specific names like ios::in, ios__out, I think of enums first.
Either way seems just as good for generic names.

Why not enum?


CHAR_BITS is never 4. It is at least 8.

Right. I was simplying as Kevin points out.
Yes, that's correct.

Thanks.
 
S

Siemel Naran

Old Wolf said:
"John Harrison" <[email protected]>:
x |= (1 << n); // set bit n to 1

x &= ~(1 << n); // set bit n to 0

if (x&(1 << n)) // true if bit n is 1

These should probably be 1UL instead of 1, because of the case where
x is [unsigned] 'long' and sizeof(long) > sizeof(int).

Is there a promotion from int -> long in expressions like int<<long? If so,
then we could make either 1 or n into an unsigned long, right?

What about the case where x is an enum. Then how do we know what to use for
1 or n? Sometimes unsigned short is appropriate, sometimes unsigned int,
unsigned long, unsigned long long if our compiler supports this. If we had
typeof then we'd just say { x |= (typeof(X)1 << typeof(X)n). Or do we have
to use std::bitset here?
 
K

Kevin Goodsell

Siemel said:
Old Wolf said:
"John Harrison" <[email protected]>:
x |= (1 << n); // set bit n to 1

x &= ~(1 << n); // set bit n to 0

if (x&(1 << n)) // true if bit n is 1

These should probably be 1UL instead of 1, because of the case where
x is [unsigned] 'long' and sizeof(long) > sizeof(int).


Is there a promotion from int -> long in expressions like int<<long?

I don't believe so. I was reading this in the standard (well, actually
the C99 standard, so if there's a difference in C++ then this won't
apply) the other day, and basically both sides undergo the integer
promotions independently, I think. int promotes to int, so it won't change.
If so,
then we could make either 1 or n into an unsigned long, right?

I suppose, but it's not the case (unless I'm mistaken). Probably best to
make that left-hand-side an unsigned type. The rules for shifting signed
types get a little confusing, but it boils down to undefined and
implementation-defined results in several cases (when shifting negative
values, or overflowing).
What about the case where x is an enum. Then how do we know what to use for
1 or n? Sometimes unsigned short is appropriate, sometimes unsigned int,
unsigned long, unsigned long long if our compiler supports this. If we had
typeof then we'd just say { x |= (typeof(X)1 << typeof(X)n). Or do we have
to use std::bitset here?

I don't know that much about enums.

-Kevin
 
O

Old Wolf

Siemel Naran said:
Old Wolf said:
x |= (1 << n); // set bit n to 1

x &= ~(1 << n); // set bit n to 0

if (x&(1 << n)) // true if bit n is 1

These should probably be 1UL instead of 1, because of the case where
x is [unsigned] 'long' and sizeof(long) > sizeof(int).

Is there a promotion from int -> long in expressions like int<<long? If so,
then we could make either 1 or n into an unsigned long, right?

Nope. There is for '+', '-' etc. but not for the shift operators.
What about the case where x is an enum. Then how do we know what to use for
1 or n? Sometimes unsigned short is appropriate, sometimes unsigned int,
unsigned long, unsigned long long if our compiler supports this. If we had
typeof then we'd just say { x |= (typeof(X)1 << typeof(X)n). Or do we have
to use std::bitset here?

[Note - this discussion applies to the case where the above expressions
are implemented as macros (otherwise , if it's a function or direct
expression, then typeof(x) is known)]

It doesn't matter if the type is too long because the compiler
will optimise it down. Also I wonder if you could get uber-portability
with (((x)&0)+1) instead of just (1), or something. That does introduce
he side-effect of evaluating (x) twice in the testing expression though.

If we are in C++ (as the NG suggests :) ) then they can just be
implemented as template functions without much difficulty, eg.
template<typename T> void set_bit(T &x, int n) { x |= T(1) << n; }
or something similar where you pass in x and return the answer, etc.
This also lets you have some sort of verification that 'n' is in
range, if you so desire.

Finally, if x were an enum, you would probably cast it to something
before calling these functions (or not do bit manipulation
on enums :)
 
S

Siemel Naran

Old Wolf said:
If we are in C++ (as the NG suggests :) ) then they can just be
implemented as template functions without much difficulty, eg.
template<typename T> void set_bit(T &x, int n) { x |= T(1) << n; }
or something similar where you pass in x and return the answer, etc.
This also lets you have some sort of verification that 'n' is in
range, if you so desire.

Makes sense.
Finally, if x were an enum, you would probably cast it to something
before calling these functions (or not do bit manipulation
on enums :)

The central question: what is the 'something'?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,164
Messages
2,570,898
Members
47,439
Latest member
shasuze

Latest Threads

Top