Checking bits states

Discussion in 'C++' started by cozzzy, Feb 5, 2006.

  1. cozzzy

    cozzzy Guest


    I have an unsigned int variable, which is really a set of bits.
    So what I need, is to check specific bit state: on/off (0 or 1).
    For example, I need to know is the 16-th bit is on.
    How can I do it?

    cozzzy, Feb 5, 2006
    1. Advertisements

  2. cozzzy

    TB Guest

    cozzzy sade:
    Use the operators &, |, ^,~, << and >> when dealing with bit patterns.
    Any decent c++ book should cover this.
    TB, Feb 5, 2006
    1. Advertisements

  3. cozzzy

    cozzzy Guest

    Thanks for your answer.
    But the fact is I do know that operators &, |, ^,~, << and >> are what
    I need.
    But I'm not very familiar with bit logics.
    So maybe someone can give me a simple hint?
    cozzzy, Feb 5, 2006
  4. cozzzy

    Kai-Uwe Bux Guest

    You might consider using std::bitset<> instead.


    Kai-Uwe Bux
    Kai-Uwe Bux, Feb 5, 2006
  5. unsigned int x;

    /*...manipulate 'x'....*/

    /* fixed pitch font req'd to view the following... */
    /* 1111 11
    * bit nbrs: 5432 1098 7654 3210
    * ---- ---- ---- ----
    * binary: 1000 0000 0000 0000 = hex 0x8000
    * ----
    * bit vals when set: 8421
    /* if bit number 15 (the 16th bit) is set in 'x' */
    if ( x & 0x8000 )
    /* do stuff... */

    Larry I Smith, Feb 5, 2006
  6. cozzzy

    cozzzy Guest

    Thanks a lot!
    cozzzy, Feb 5, 2006
  7. Why? What are the advantages for someone who has "an unsigned int
    variable, which is really a set of bits"? Im really interested.

    Roland Pibinger
    Roland Pibinger, Feb 5, 2006
  8. cozzzy

    Kai-Uwe Bux Guest

    To someone who does not know the typical bit fiddling idioms that go with
    using an unsigned int as a set representation, std::bitset<> clearly has
    the advantage of a much nicer interface. Keep in mind that my advise was
    addressing someone who did not know how to treat an unsigned int as a set
    of bits.

    However, for someone who does know the bit fiddling idioms, std::bitset<>
    still reduces the likelihood of glitches. After all, these expressions with
    bit shifting and xor-ing and stuff are all a little bit error prone.


    Kai-Uwe Bux
    Kai-Uwe Bux, Feb 5, 2006
  9. cozzzy

    persenaama Guest

    After all, these expressions with bit shifting and xor-ing
    Come on, testing if 16th bit is set is not Rocket Science - it's
    fundamentals of the language, and for crying out loud, computer
    science. Knuth would roll in his grave is he were dead.
    persenaama, Feb 6, 2006
  10. cozzzy

    roberts.noah Guest

    I disagree. Things that normally work when dealing with bitmasks don't
    with bitset. For instance: if (bits & VALUE) has to be instead if
    ((bits & VALUE).any()) as I recall when using it.

    std::bitset<> is useful for values larger than the bitsize of whatever
    the largest type is in your system. When implementing bitboards for
    chinese chess I used it (board is 90 squares) but I can't imagine it
    being particularly useful for anything else.
    roberts.noah, Feb 6, 2006
  11. cozzzy

    Kai-Uwe Bux Guest

    Maybe that "things that normally work when dealing with bitmasks don't with
    bitset"; however, this kind of frustrated expectations hardly applies to
    someone "who does not know the typical bit fiddling idioms".

    That too.

    Well, if you see an advantage for std::bitset in some cases, then why would
    you want to maintain a second set of language idioms for the same task just
    in those cases where your number of flags happens to be less than
    <implementation defined constant>?

    Also, I find that the std::bitset idioms convey intend more clearly. I would

    if ( flag[3] ) {...} or flag[3] = true;


    if ( flag & 8 ) {...} or flag |= 8;

    any day. However, I agree that things like these are very much a matter of


    Kai-Uwe Bux
    Kai-Uwe Bux, Feb 7, 2006
  12. cozzzy

    JustBoo Guest

    Well, chalk-up yet another subject you know nothing about. That
    doesn't stop you from commenting with a boatload of assumptions
    though does it.

    The people who do embedded programming are laughing *at* you, pal;
    not with you. Additionally, there are thousands if not tens of
    thousands of programs "out there" that monitor, control and test
    hardware. All kinds of hardware.
    You have never heard of using C++ to interface - read and write - to
    hardware registers? I said hardware registers... ooo, boy. You can
    use std::bitsets to do that.

    Once again, I did my first video disc recorder/player in the early
    nineties. That's what software engineers do; learn to program real
    world problem domains. Not just learn one myopic academic subject
    and then discount anything and everything they've never heard of.


    And I didn't even mention device drivers... oh, I just did.

    Some drink at the fountain of knowledge... others just gargle.
    JustBoo, Feb 7, 2006
  13. cozzzy

    roberts.noah Guest

    Good for you Mr. "Boo".

    Thanks for the links.
    roberts.noah, Feb 7, 2006
  14. cozzzy

    roberts.noah Guest

    What about if (flag & 7)?

    Also I recall another thing that bugged me: the above would have to be
    flag & std::bitset<X>(7). This does make some amount of sense given
    what you are actually meaning to do but the added complexity often
    isn't necessary. I use bitset when I need what it offers, otherwise I
    use a type that fits the mask I am working with.
    Certainly. I've certainly seen worst attempts at creating a generic
    bitmask type.
    roberts.noah, Feb 7, 2006
  15. cozzzy

    persenaama Guest

    If using std::bitset, it sounds awfully like bad engineering practise -
    using "magic" numbers, certainly it would be better practise to use
    symbolic names for hardware registers and design the API around that.
    At that stage using bit-fields, bitset, boolean arithmetic, whatnot,
    doesn't make any difference. It's just implementation detail.

    However, recommending std::bitset because it is *simpler*, is
    suspectible: is it really simpler not to learn the language you using
    than use some specific class written on top of the language
    *fundamentals* like AND, OR, XOR. It seems these days be simpler not to
    know what the hell you are doing and just use shrink-wrapped class. I
    disagree with that: I want to know what I am doing, call me weird.
    persenaama, Feb 7, 2006
  16. cozzzy

    Kai-Uwe Bux Guest

    persenaama wrote:

    Hm, would you apply the same kind of reasoning to basic data structures
    like doubly linked lists or search trees? These are also clearly
    fundamentals of compupter science and everybody should known how to
    implement them. Do you then suspect anybody who recommends the use of
    std::list<> or std::map<> of promoting laziness and ignorance?


    Kai-Uwe Bux
    Kai-Uwe Bux, Feb 7, 2006
  17. cozzzy

    persenaama Guest

    Hm, would you apply the same kind of reasoning to basic data structures
    What kind of reasoning would that be? Everybody doesn't have to
    implement bitwise operations.

    Thank you for not quoting what you are replying to, without that what
    you are asking almost makes sense. It would make sense if I was
    proposing something like that, but I am not. Here's what I wrote,

    "recommending std::bitset because it is *simpler*, is suspectible"

    If you think, that I think that writing own std::list implementation is
    simpler, then your question would make any sense to begin with. Your
    question is based on incorrect assumption, I won't humor you by
    defending a point of view that exists only in your own imagination.

    I don't have a problem using std::bitset. I do have a problem keeping a
    straight face if someone uses std::bitset for the reason that do not
    understand bitwise and.
    persenaama, Feb 8, 2006
  18. cozzzy

    Kai-Uwe Bux Guest

    I did quote a complete paragraph. And it was exactly that paragraph that I
    responded to. I have no idea, what you are talking about.
    You also wrote, and I quoted:

    "It seems these days be simpler not to know what the hell you are doing and
    just use shrink-wrapped class. I disagree with that: I want to know what I
    am doing, call me weird."

    Now, how and why does that reasoning not apply to std::list<> and
    Nope, my question makes sense, if "to know what the hell you are doing" as
    opposed to "using shrink-wrapped class" is an alternative on which, you
    seem to say, we ought to come down on the side of knowing what we are

    Well, I am glad to learn that you did not meant what I read. I am pretty
    sure though that I read it because you wrote it.

    Thanks for this clarification.


    Kai-Uwe Bux
    Kai-Uwe Bux, Feb 8, 2006
  19. cozzzy

    roberts.noah Guest

    IMHO it does. You should implement a linked list and a binary tree at
    least once so that you understand what they are doing. Once that is
    done though there is no reason to continue doing so unless you have a
    good reason why the standard containers aren't what you need. These
    classes are mature, robust, and well optimized most of the time and
    they have good interfaces that meet a wide variety of requirements
    though obviously not everything.

    By using primatives and bitwise operators you aren't reinventing the
    wheel like you do by not using standard containers. Primatives and
    bitwise operators and the bitset class provide very similar services
    and interfaces. The bitwise operators just aren't capable of dealing
    with masks past a certain size. Until you're dealing with masks of
    that size (and honestly that isn't very often) the differences between
    primatives and bitset are simply a matter of taste and style.
    roberts.noah, Feb 8, 2006
  20. cozzzy

    persenaama Guest

    The reasoning aimed to establish that I rather know what I am doing
    than code with hunch and feeling (at best). In that sense the reasoning
    DOES apply to std::list and std::map, I feel confident that I know how
    to use them efficiently and safely.

    The discussion was about ways to check if a bit is set.

    Checking if a bit is set, is a simple bitwise-and, which incidetally is
    built-in into the language: library, standard or any other kind is not

    Using std::bitset is not frowned upon by yours truly, but using it as
    replacement for knowledge of what bitwise-and is and advice leading to
    the same outcome is something that I DO regard with highest suspicion.
    persenaama, Feb 8, 2006
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.