This article identifies some semantic gaps in the C programming language and discusses bridging the semantic gap using C++. I had always regretted the fact the C programming language had no explicit support for values sometimes best represented as single bits, such as TRUE or FALSE. C programmers often use

typedef unsigned char Boolean;

BitArray x, b;
x[5] = b[6];

typedef unsigned long BitArray;
BitArray x, b;
int t;
t = bitx(b,6); /* extract bit position 6, length 1 */
bitd(x,5,t);   /* deposit into bit position 5, length 1 */

class BitArray {
public:
    BitArray();
    int operator[](int);
    void set(int value, int pos);
private:
    unsigned long _data;
};

BitArray x, b;
x.set(b[6],5);

If we want to abandon member function set and allow operator[] to be a modifiable 1value (an expression that can receive a value by being placed on the left hand side of an assignment statement), we typically overload operator[] to return a reference to an element of the array. Then we let the operator= actually perform the transfer of the value. We typically see operator[] overloaded as follows:

class IntArray {
public:
    int& operator[](int sub){
        {...}
    ...
};

IntArray x, b; x[6] = b[5];

1) We cannot return a reference to a single bit.

2) The function for fetching an element out of the array is identical to the function for storing an element. (In both cases we merely return a reference to the element).

These constraints are clearly not a problem when implementing an array of int because our function return type is a reference to an int. The problem, then, is how to access (fetch and deposit) the elements of an array of bits using operator[] and operator=.

The focus of the remainder of this article will be to examine some important features of the C++ language and develop a technique to solve the problem of returning a reference to a bit. Later, we will note that this is not the only place where type constraints make the naive use of operator[] difficult, so we can apply this technique elsewhere.

void func(const BitArray & x)
{
    if (x[0] == 1)
        ...
}

Sometimes, in copy constructors for example, we are not permitted to pass by value. The problem with the above fragment of code is that the compiler will complain that we are modifying the object x. This is not actually true, of course, we are just examining it. Nevertheless, we can observe that we will sometimes be using operator[] to modify a BitArray object and other times we will need to explicitly state that operator[] will not modify the object. We can use the const feature to overload operator[]. We now modify the definition of class BitArray:

class BitArray {
public:
    int& operator[](int sub)
        {...}
    int operator[](int sub) const
        {...}
...
};

   BitArray x, b;
   x[6] = b[5];

1) the address of the representation of the array object (here the address of an unsigned long)

2) the subscript

3) the length of the bit field (in this example it is assumed to be one)

4) the value to be deposited in the array of bits.

The problem, then, is to communicate these four pieces of information to the operator= function.

To communicate the first three pieces of information we introduce a new class whose declaration looks something like this:

   class BitField {
   public:
       BitField(unsigned long *data, unsigned int pos, unsigned width);
       void operator=(unsigned long rhs);
   private:
       unsigned long *_data;
       int _pos;
       int _width;
   };

class BitArray {
public:
    BitField operator[](int) {
        {...}
    int operator[](int) const {
        {...}
...
};

BitArray x, b;
x[6] = b[5];

The compiler then looks for an appropriate assignment function and notes that class BitField has such a member function. This is then used to perform the actual masking to deposit the new value into the unsigned long which holds the actual representation of the array of bits. We might consider ourselves finished at this point. However, there is still another potential problem. If we code in the tradition of many C programmers, we may want to use a feature whereby we are allowed to have multiple assignments within a single statement, like the following:

BitArray x;
x[3] = x[2] = x[1] = x[0] = 1;

How can we make our new class BitField compatible with other built-in types in C? The key to this problem is to consider something counterintuitive. We normally don't think of operator= as a function that returns a value. But this exactly why we are permitted to write expressions such as a = b = c in C and C++. We now have a definition of BitField that looks like this:

class BitField {
public:
    BitField(unsigned long *data, unsigned int pos, unsigned int width);
    BitField& operator=(unsigned long rhs);
private:
    unsigned long *_data;
    int _pos;
    int _width;
};

BitField operator=(unsigned long)

BitArray x;
x[3] = x[2] = x[1] = x[0] = 1;

class BitField {
public:
    operator unsigned long() {
    {...}
};

BitArray x;
x[3] = x[2] = x[1] = x[0] = 1;

There is one scenario in which the conversion operator does not work as we would like. Consider some arbitrary constructor that accepts an integer, and a function that accepts a const argument of that type:

struct X{
    X(unsigned int x){cout << "Create X =" << x << endl; }
};
void f(const X& x){cout << "Function f"; }

main(){
    X a;
    f(a[1]); //error
    const X temp = a;
    f(temp[1]); //OK
}