Title: Questions & Answers

answer = Metre(len1-len2);

This letter raises several interesting points as well as demonstrating something often missed by technical writers, even intelligent and diligent readers can face problems if they lack the assumed foundation knowledge.

I have a rigid definition of a pure value type - it has a public copy constructor and copy assignment operator (these can be either implicit or explicit). On the other hand a pure object type for me is one that has neither of these as public properties. A pure object has a location (a fixed address) and can only be passed by reference or accessed through a pointer.

Now all the facilities (algorithms and member functions of the template containers) provided by the STL function by copying items in the containers. In other words the items must be copyable - in my terms they must be values because they must be movable.

We could have had collections that held items via references had C++ references been like Java ones (reseatable). We can use collections of pointers to handle objects. But in this case note that we would have had to have had a very different design depending on whether we chose to have the collections own the object pointed at (i.e. responsible for deleting them) or not.

The choice made by the designers of the STL is the most versatile, but it also requires a greater degree of understanding. You have to be very careful of collections of pointers. You are probably better off with some form of smart-pointer with true copy semantics (auto_ptr will not do because of the ownership transfer semantics of its copy facilities) if you want to handle collections of objects.

It is probably hard to imagine how the STL could have been anything other than value based, but none-the-less it is important to explicitly understand this property if you are to use the STL correctly.

Now to that other question.

C++ provides two types of conversion, explicit ones via casts (either C-style, function style or new-style) or implicitly. For example:

int main (){
  double d = 1.0;
  d = (double) 2;  // C-style
  d = double(2);    // function style
  d = static_cast<double> (3);  // new-style
  d = 4;          // implicit
}

Note that the other new-style casts do something rather different and are not relevant here.

Implicit casts require the existence of either a standard conversion (such as those for the built-in types, derived to bass class etc.) or a sequence of such including not more than one user provided conversion. User provided conversions are of two kinds:

There are other possible conversions available for the three types of explicit cast but they are not relevant here, all you need to note is that explicit conversions are a strict superset of implicit ones. Also note that conversions are applied to values, not objects. Whenever the compiler is trying to resolve an expression it is free to try implicit conversions if no operators/functions have been supplied for the types of the constituent parts.

Let us now examine the assignment statement in question:

answer = Metre(len1-len2);

Consider the subexpression (len1-len2). The compiler checks to see if operator- has been provided for Metre types. It hasn't. So next it checks to see if there are any implicit conversions for Metre that convert values of Metre type to one for which an operator- has been defined. If it finds several possibilities, there are rules to try to resolve the choice. In this case it finds the conversion operator from Metre to double. It applies it to both len1 and len2 and completes the subtraction to get a double value.

Now if there were no cast it would look to see if there were an implicit conversion from double back to Metre. However the constructor that could do this conversion has been qualified as explicit.

The function style cast (constructor call) provides the explicit conversion from double to Metre so that the resulting value (temporary constructed by the explicit call) can be assigned to answer.

It is this liberty to search for conversion sequences (including at most one user defined conversion) that makes it so dangerous to provide conversion operators and single argument constructors that have not been qualified as explicit.

For a moment, consider the consequences of removing the explicit qualifier from the constructor for Metre:

int main(){
  Metre length =5.0, breadth = 2.0;
  Metre perimeter;
  perimeter = length * breadth;
  cout << perimeter;
}

I know the calculation is wrong but the compiler will not trap it because we will not have ensured that square metres cannot be implicitly converted to metres. Of course this is a pretty poor example but I hope it gives you an idea as to the dangers of providing implicit conversions for user defined types.