ertain objects must be converted to a low-level representation and vice versa. Programmers using std::string objects, for instance, have to convert them to bare char pointers, as in the following example:

string inf="mydata.txt";ifstream infile(inf.c_str());//const char* required 

Similarly, POSIX programmers need to convert objects to file descriptors to use native system calls.

How to automate conversions of objects to their underlying types without compromising code safety?

Use conversion operators and explicit constructors to create objects with a dual-interface while avoiding ill-behaved conversions.

Demonstrating the Problem
Commercial and financial applications often represent monetary values as objects rather than native floating-point types. There are several good reasons for this approach:

• Type-safety: Human errors are detected more easily this way.
• Portability: As implementation details are hidden from users, your code becomes more portable.
• Business logic: A class allows you to enforce business logic rules. For example, a US dollar class knows that a dollar has 100 cents whereas a Kuwaiti dinar class knows that a dinar has 1000 fils. This knowledge affects I/O formatting, for example.

Here’s a simplified class representing US currency:

class USD{private: __int64 dollars; //or long long, depending on compiler  int cents;public: USD(__int64 d=0, int c=0) :   dollars(d), cents(c) {}friend bool operator==(const USD& d1, const USD& d2); //...other overloaded operators and functions};

Alas, many math functions such as pow() and sqrt() will accept only floating-point variables. To overcome this problem it might seem tempting to overload relational and arithmetic operators. However, you’ll soon discover that this incurs excessive code writing, testing and maintenance for no real purpose. What you really want is a dual interface: class USD should provide the advantages of a real object listed above while offering a safe and automatic conversion to fundamental types in the appropriate contexts.

Using Conversion Operators
A conversion operator converts its object to a different type automatically in an appropriate context. In class USD, the most natural conversion is to double:

USD payment(203, 67);

In this case, you want a conversion of the payment object to the floating point value 203.67.

A conversion operator has no return value (it’s deduced from the operator’s name) and it takes no arguments either:

class USD{public: operator double() //conversion operator {  double temp=(dollars*100)+cents;  return temp/100; }};

Let’s see how it works. Suppose you want to increase payment by 5 percent:

double res=payment*1.05; //res=210.70

This works fine because the conversion operator automatically converts payment to the value 200.67 before the multiplication. However, there is a serious flaw in the design of class USD. Consider the following statement:

payment=payment*1.05; //bad

Now, payment equals 210.00, which is certainly not the expected result. Let’s see why.The right-hand sub-expression payment*1.05 is evaluated first. As you’ve just seen, this part is kosher and produces the correct result. The problem is with the assignment. The compiler evaluates the assignment expression as follows:

payment=USD(__int64(200.67*1.05), 0);

The result of the multiplication expression is implicitly converted to an integral type (thus losing the fraction part) and is then used as an argument of a temporary USD object. That’s why it yielded such an embarrassing result.

Declaring Constructors ‘explicit’
To correct this flaw, first declare the constructor explicit:

class USD {public: explicit USD(__int64 d=0, int c=0):   dollars(d), cents(c){}...

This way, only assignments of USD objects will be accepted:

payment=USD(payment*1.05); //fine payment=payment*1.05; //compilation error 

Adding another Constructor
The second fix is to add another constructor that takes an argument of type double:

class USD {public: explicit USD(double val) {  dollars=val; //copy the integral part  long double temp=(val-dollars)*100; //extract cents  //avoid truncation e.g., .6699 to 66 rather than 67  cents=temp+0.5; }};

Here again, the constructor is declared ‘explicit’ to avoid inadvertent assignments. To increase payment by 5 percent, use the following form instead:

payment=USD(payment*1.05); 

Now, everything’s in order. Inadvertent conversions by a promiscuous constructor are blocked, whereas well-behaved conversions to double that rely on the conversion operator are permitted.

Better Safe than Sorry
Programmers often moan about the lack of a const char * conversion operator in class std::string. If std::string had such an operator, you could write

string filename;ifstream inf(filename);

Instead of the ugly:

ifstream inf(filename.c_str());

However, the C++ standardization committee decided not to include a conversion operator of this kind in std::string because it might cause nasty bugs in certain libraries in which char * are used extensively. In this case, the committee adhered to the “better safe than sorry” idiom. By contrast, objects contain a conversion operator to type void* which enables you to use them like this:

ifstream inf("myfile");if (inf) //using void * conversion operator //use the fileelse  //failure

When you design your own classes, consider which automatic conversions are desirable and which ones should be disabled. Then, enable legitimate conversions by defining the appropriate conversion operators while blocking undesirable conversions by declaring constructors explicit.