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

[tmartsum]

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" =) )

 

[Greg]

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

 

[tmartsum]

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.

 

[Shezan Baig]

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-

 

[Bob Hairgrove]

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.

 

[Greg]

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

 

[Bob Hairgrove]

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.