if( a == (unsigned char) ~b ) ...

A

The comparison should evaluate to false. You must be careful in both C and C++ when you try to do any operation on integral types smaller than an int, because the compiler promotes the operands to a larger size before doing the operation. The effect of these promotions becomes most obvious in cases like the above, where the code is twiddling individual bits, but promotion can also lead to surprises for ordinary arithmetic operations.

Tracking through the language definitions to understand these effects, we should begin by looking at the ~ operator. The C Standard defines ~ in section 3.3.3, Unary Operators, which says:

The result of the ~ operator is the bitwise complement of its operand (that is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set). The integral promotion is performed on the operand, and the result has the promoted type.

(To find corresponding language in the ANSI/ISO C++ working paper, look in section 5.3.1.) Note the first clause of the second sentence: "The integral promotion is performed..." That's the key to the behavior seen here. To find out what that means, turn to the definition of "integral promotions," found in section 3.2.1.1 (section 4.5 in the C++ working paper):

A char, a short int, or an int bit-field, or their signed or unsigned varieties, or an enumeration type, may be used in an expression wherever an int or unsigned int may be used. If an int can represent all values of the original type, the value is converted to int; otherwise, it is converted to an unsigned int. These are called the integral promotions. All other arithmetic types are unchanged by the integral promotions.[footnote omitted]

In the above case an int can represent every value that an unsigned char can hold, so the unsigned char that is the operand of ~ will be promoted to int. The result is exactly what he describes: 0xFE becomes 0x00000FE, and applying ~ to this value produces 0xFFFFFF01.

We're not done yet, though. Now let's figure out how to handle the == operator. Section 3.3.9, Equality Operators (section 5.10 in the C++ working paper), refers us to section 3.3.8, Relational Operators (section 5.9 in the C++ working paper). In this case, both operands to the == operator have arithmetic type (that is, neither one is a pointer), so the language definition tells us that "the usual arithmetic conversions are performed." The purpose of these usual arithmetic conversions is to bring the operands of a binary operator to a common type. The definition, found in section 3.2.1.5 (section 5 in the C++ working paper), is a bit tedious, but in this case it means that since one operand of the == operator is of type int and the other is smaller, the smaller one should be promoted to int. So the value in a is promoted to int, giving 0x00000001. Comparing this with 0xFFFFFF01 (~b), the two values are clearly not equal.

Integral promotions are designed to preserve values. The compiler promotes the unsigned char 0xFE to the integer 0x000000FE, because 0X000000FE has the same numeric value as 0xFE. Preserving value does not guarantee, however, that bit manipulations on the two variables will produce the same results.

The questioner's suggestion works because the conversion back to unsigned char throws away the high-order bits that the compiler added in order to convert 0xFE into an int. Personally, I prefer to mask out the extra bits instead of using a cast:

   if( a == ((~b)&UCHAR_MAX)) ...

   if( a == (unsigned char)(-b) ) ...

Q

This is my understanding, given the following code fragments:

   class foo {
   public:
      void ConstFunc () const;
      void NonConstFunc ();
   };

   foo aFoo;

   const foo *p = &aFoo;    // 1

   const foo * const q = &aFoo; // 2

2. In //2 above, both q and the referenced object are const.

Am I correct?

A

Not quite. It's a bit tricky to read declarations that mix pointers and const qualifiers, and programmers often get confused by declarations like these. The best way to approach these declarations is to start with the identifier being declared and read the declaration from right to left. For example, in the declaration marked //1, the identifier being declared is p. Reading from right to left, we discover that p is a pointer to an object of type foo which is const. So your comment that p is const is incorrect. p can be changed to point to a different object, but the object that p points to at any time cannot be changed through the pointer p. The following code fragment demonstrates this:

   foo bFoo;
   p = &bFoo; // valid: p is not const
   p->NonConst Func( );
      // invalid: *p is const
   p->ConstFunc( ); // valid

   q = &bFoo; // invalid: q is const

   foo const *r = &aFoo;

   const foo const *s = &aFoo;

In general, a const qualifier applies to the thing to its left. When a const qualifier is the first thing in a declaration it doesn't have anything to its left, so it applies to the thing to its right. Some programmers adopt a coding convention that does not allow use of const as the first thing in a declaration. They require that the const qualifier always come after the thing it applies to. These programmers would not use the form we used to define p, but would use the form used for r. Personally, I'm in the habit of writing the const first when it applies to a type name, so I would have a hard time with such a coding convention. But if you find that you are confused by these declarations, it might be useful to adopt this convention so that you always write things in the same way.

It's also important to understand that creating a pointer to a const object does not mean that that object can never be modified. It only means that the pointer itself cannot be used to modify the object. Consider the following:

   const foo *t = &aFoo;
   t->NonConst Func( );
      // invalid: calling a non-const
      // member function on a const object

   foo *u = &aFoo;
   u->NonConst Func();
      // valid: not a const object

Q

My question relates to assigning a derived to a derived. I have implemented assignment by defining assignment operators for base and derived classes. But I also have tried supplying an assignment operator only in the base (Base& Base::operator=(const Base&)) and having it call a virtual protected helper function, setEqual. However, the Annotated Reference Manual [ARM] says assignment operators are not inherited (see below) I am now wondering why the base class's assignment operator is invoked for a derived-to-derived assignment.

ARM section 13.4.3:

The assignment operator=() must be a nonstatic member function; it is not inherited (12.8). Instead, unless the user defines operator= for a class X, operator= is defined, by default, as memberwise assignment of the members of class X.

A

In order to understand what this paragraph means we need to look at the meaning of "inherited." Here's a simple pair of classes that will show how this works:

   class Base
   {
   public:
      void Member( );
      Base& operator = ( const Base& );
   };

   class Derived : public Base
   {
   public:
      int data;
   };

   Derived;
   d.Member( );

The assignment operator works a little differently. There's a good reason for that, though. Suppose the assignment operator was simply inherited, like any other member function. What would the following code do?

   Derived d1;
   d1.data = 3;

   Derived d2;
   d2.data = 0;

   d2 = d1;

In fact, that's what the quoted section of the ARM says should happen. Derived does not provide its own assignment operator, so the proper action for the compiler is to copy all of the members of Derived when this assignment is performed. This is made clearer in section 12.8, which says, in part,

Memberwise assignment and memberwise initialization implies that if a class X has a member or base of a class M, M's assignment operator and M's copy constructor are used to implement assignment and initialization of the member or base, respectively, in the synthesized operations.

Actually, this wording is also found in the ANSI/ISO C++ working paper, which clarifies many of the little issues in the language definition. In particular, the working paper introduces the notion of a synthesized operation, an important term that allows us to talk about these things more easily. In general, every class has a default constructor, a copy constructor, and an assignment operator. If the appropriate operation is not explicitly defined in the class definition, the compiler will synthesize one.

In our example, the assignment

   d2 = d1;

Now let's see how this applies in the example posed by your original question:

   class Base
   {
   public:
      Base& operator = ( const Base& b )
         {
         setEqual( b );
         return *this;
         }
   private:
      virtual void setEqual( const Base& b )
         {
         BaseData = b.BaseData;
         }
      int BaseData;
   };

   class Derived : public Base
   {
   private:
      void setEqual( const Base& b );
      int DerivedData;
   };

   void Derived::setEqual( const Base& b )
   {
      Base::setEqual( b );
      Derived *d = dynamic_cast<Derived*>(&b);
      if ( d != 0)
         DerivedData = d->DerivedData;
   }

   Base b;
   Derived d;
   d.Base::operator=(b);

But let's go a step further, and look at what actually happens in the more usual case:

   Derived d1, d2;
   d2 = d1;

How can we avoid this double assignment? Easy: don't fight the compiler. Write each class to handle its own assignments, either through the synthesized assignment operator or through an explicit assignment operator. Don't worry about derived classes: they'll take care of themselves.