You opion on "should the limit in bitfields be removed?"

Discussion in 'C++' started by tmartsum, Oct 4, 2005.

  1. tmartsum

    tmartsum Guest

    I have a discussion in comp.std.c++

    After a (bit stupid) suggestion on representing a fixed
    'big' length int I moderated it to

    "Bitfields-ints should be allowed to have any fixed length"
    I got no replys on my moderated suggestion.
    (I am asking you your opinion of this - I do not really have a
    C++-problem)

    Eg. The following would be the case:
    struct Intof512bit
    {
    unsigned int m_repint1 : 512; // not legal now. Why not allow it ?
    // Ok it is legal if sizeof(int) >= 64 (not likely)
    };

    struct Intof1024bit
    {
    unsigned int m_repint2 : 1024;
    };

    The following would be the behavior

    Intof512bit i1;
    Intof1024bit i2;

    // math on i1 and i2 are done the expected way.
    int x = i1.m_repint1; // Warning (probably) truncating int

    std::cout << i1.m_repint1; // Warning (probably) truncating int.
    // you will have to do that yourself. (or maybe there should be a
    standard macro)

    int z = static_cast<int>( i1.m_repint1); // Ok programmer hopefully
    knows what (s)he is doing - no warning
    int v = (int) i1.m_repint1; // Ok programmer hopefully knows what (s)he
    is doing - no warning

    int func_a()
    {
    return i1.m_repint1; // Warning (probably) truncating int
    }

    void func_b(int u);
    func_b(i1.m_repint1); // // Warning (probably) truncating int


    Intof512bit.m_repint1 = x; // No problem
    i1.m_repint1 = i2.m_repint2; // Warning truncating int
    int* y = &(i1.m_repint1); // Error - cannot take adress of bitfield
    integer.

    sturct SizeRulesStruct
    {
    unsigned int m_vrepint1 : 11;
    unsigned int m_vrepint2 : 512;
    unsigned int m_vrepint3 : 11;
    }

    What is sizeof(SizeRulesStruct) ? Compiler-dependend. When having a
    word that is forced to go over serveral words it may be put by itself
    or it may be compact. (The result sould be between 67 to 72)

    I feelt my suggestion a bit justified by looking at
    "The C++ programming language" by Bjarne Stroustrup - C.8.1

    struct PPN
    {
    unsigned int PFN : 22; // Page frame number
    ...
    }

    I guess this does not have to compile since the only C++-guarantee is
    that int is at least 16 bit. And 22>16 so if int is 16 bits this code
    is simply rejected (therefore it is a bad example) and if not a reason
    then still it gives an example on how a real juru misses that his code
    might not work in all cases because the language has a restriction.

    I know I can find a bitint several places - and I just might. However I
    have seen some implementend in C++. However on "normal" CPUs a compiler
    would probably could do it at least a factor 2 better than even a real
    good C++-program. (Since assemblercode can make use of the carryflag.)
    (I know some are written in assembler too - and I know I could also
    just write my own compiler eg by modifing gcc) but it is not the point.

    It would be a new application for bitfields that are normally not used
    that much today and it would remove in my opion a limit where there is
    too much focus on making it easy for the compilewriters and too little
    on the language.

    I know that changes are poor to change the language. There are some
    conservative gurus. Some of them would probably argue "We only have
    bitfields in C++ to be C compatible". But still I really cannot see why
    this size-restriction should not be removed. Can you ?
    Or do you like the idea ?

    Give me your opinion.
    If you think it is a bad idea then please argue.
    (Not just "your idea sucks" =) )
    tmartsum, Oct 4, 2005
    #1
    1. Advertising

  2. tmartsum

    Greg Guest

    tmartsum wrote:
    > I have a discussion in comp.std.c++
    >
    > After a (bit stupid) suggestion on representing a fixed
    > 'big' length int I moderated it to
    >
    > "Bitfields-ints should be allowed to have any fixed length"
    > I got no replys on my moderated suggestion.
    > (I am asking you your opinion of this - I do not really have a
    > C++-problem)
    >
    > Eg. The following would be the case:
    > struct Intof512bit
    > {
    > unsigned int m_repint1 : 512; // not legal now. Why not allow it ?
    > // Ok it is legal if sizeof(int) >= 64 (not likely)
    > };
    >


    >
    > I know that changes are poor to change the language. There are some
    > conservative gurus. Some of them would probably argue "We only have
    > bitfields in C++ to be C compatible". But still I really cannot see why
    > this size-restriction should not be removed. Can you ?
    > Or do you like the idea ?
    >
    > Give me your opinion.
    > If you think it is a bad idea then please argue.
    > (Not just "your idea sucks" =) )


    Shouldn't the focus of C++ as distinct from C be on classes and other
    high level programming? And isn't vector<bool> an unlimited bitfield -
    but done the C++ way: with greater abstraction, fewer machine
    dependencies, amd better type safety?

    Personally, I don't think that unlimited bitfields are needed in C++
    because they are already supported.

    Greg
    Greg, Oct 4, 2005
    #2
    1. Advertising

  3. tmartsum

    tmartsum Guest

    Thanks for your opinion.

    I was suprised to find out that vector<bool> is compact, but still
    there are no math on it (or?). There were 2 reasons for my suggestion
    1) Remove a limit that serves compiler-writers - but making the
    language poorer
    2) Do fast math on a fixed sized int.
    tmartsum, Oct 6, 2005
    #3
  4. tmartsum

    Shezan Baig Guest

    tmartsum wrote:
    > I was suprised to find out that vector<bool> is compact, but still
    > there are no math on it (or?). There were 2 reasons for my suggestion



    I think std::bitset would fit your requirements.

    Hope this helps,
    -shez-
    Shezan Baig, Oct 6, 2005
    #4
  5. On 6 Oct 2005 03:02:42 -0700, "tmartsum" <> wrote:

    >I was suprised to find out that vector<bool> is compact


    If you need this for interacting with legacy code expecting monolithic
    blocks of bytes/bits, I'm afraid that vector<bool> won't work.
    vector<bool> is not really implemented as a contiguous array of bits
    through a contiguous area of bytes, but usually using some other
    integral type such as int or char. You might want to look at code for
    some existing implementations of vector<bool>, e.g. STLPort, to see
    what I mean.

    std::bitset, OTOH, uses real bits. However, the semantics are
    different than std::vector.

    --
    Bob Hairgrove
    Bob Hairgrove, Oct 6, 2005
    #5
  6. tmartsum

    Greg Guest

    Bob Hairgrove wrote:
    > On 6 Oct 2005 03:02:42 -0700, "tmartsum" <> wrote:
    >
    > >I was suprised to find out that vector<bool> is compact

    >
    > If you need this for interacting with legacy code expecting monolithic
    > blocks of bytes/bits, I'm afraid that vector<bool> won't work.
    > vector<bool> is not really implemented as a contiguous array of bits
    > through a contiguous area of bytes, but usually using some other
    > integral type such as int or char. You might want to look at code for
    > some existing implementations of vector<bool>, e.g. STLPort, to see
    > what I mean.
    >
    > std::bitset, OTOH, uses real bits. However, the semantics are
    > different than std::vector


    No, the C++ language standard requires that vector<bool> be implemented
    as a bitset - one bit per boolean value. std::vector<bool> is a
    specialization of std::vector and is not a generic vector of "bool"
    types. Nor is it really a "vector" either, for that matter.

    It is a bitset.

    Greg
    Greg, Oct 6, 2005
    #6
  7. On 6 Oct 2005 04:32:29 -0700, "Greg" <> wrote:

    >
    >Bob Hairgrove wrote:
    >> On 6 Oct 2005 03:02:42 -0700, "tmartsum" <> wrote:
    >>
    >> >I was suprised to find out that vector<bool> is compact

    >>
    >> If you need this for interacting with legacy code expecting monolithic
    >> blocks of bytes/bits, I'm afraid that vector<bool> won't work.
    >> vector<bool> is not really implemented as a contiguous array of bits
    >> through a contiguous area of bytes, but usually using some other
    >> integral type such as int or char. You might want to look at code for
    >> some existing implementations of vector<bool>, e.g. STLPort, to see
    >> what I mean.
    >>
    >> std::bitset, OTOH, uses real bits. However, the semantics are
    >> different than std::vector

    >
    >No, the C++ language standard requires that vector<bool> be implemented
    >as a bitset - one bit per boolean value. std::vector<bool> is a
    >specialization of std::vector and is not a generic vector of "bool"
    >types. Nor is it really a "vector" either, for that matter.
    >
    >It is a bitset.
    >
    >Greg


    The standard provides a specialization of vector for bool, but I
    couldn't find anywhere that says it has to be a bitset. It might be a
    bitset, but I couldn't find anything in section 23.2.5 which says it
    has to be. Of course, I might need to look somewhere else. Please
    correct me if I am wrong by pointing out chapter and verse in the C++
    standard...I am admittedly a little dense at times, but I do try to
    make an honest effort. At any rate, there are implementations out
    there which don't use a bitset.

    My point was this: We have a guarantee that the elements of a vector
    occupy a contiguous area of memory. Therefore, I can declare a
    vector<char> and pass the address of its first element to a function
    expecting a char* or const char*. This doesn't hold true for
    vector<bool>, though, since the type returned by operator[] is a class
    that "simulates the behavior of references of a single bit in
    vector<bool>". IOW, as we all knew anyway, it isn't possible to take
    the address of a single bit.

    So although we know that the memory occupied by the vector elements is
    contiguous, we can't really do anything with it except twiddle the
    bits and read or write the individual elements one at a time. Even if
    I KNOW that the data is kept as contiguous bits from element 0 through
    size()-1, I cannot DO anything with it because I cannot take the
    address of any of its elements (including element 0) and expect that
    to point to anything meaningful. This may serve the purpose the OP had
    in mind. However, std::bitset has to_string and to_ulong which could
    prove to be more practical when interfacing with legacy code.

    --
    Bob Hairgrove
    Bob Hairgrove, Oct 6, 2005
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doris Cox
    Replies:
    0
    Views:
    520
    Doris Cox
    Dec 2, 2003
  2. Dennis
    Replies:
    0
    Views:
    673
    Dennis
    Dec 2, 2003
  3. Dennis
    Replies:
    0
    Views:
    426
    Dennis
    Dec 2, 2003
  4. Don Grover

    Urgent Opion wanted.

    Don Grover, Nov 14, 2003, in forum: XML
    Replies:
    1
    Views:
    423
    Scott Mohekey
    Nov 15, 2003
  5. tmartsum
    Replies:
    0
    Views:
    283
    tmartsum
    Oct 4, 2005
Loading...

Share This Page