C++ 轉換運算子與 explicit 建構子：構建安全雙重介面的藝術

問題：隱式轉換的雙面刃

物件常需轉換為底層型別 (如 std::string → const char*，fstream → 檔案描述符)。但不經意的隱式轉換會導致驚人的 bug。如何在保留便利性的同時，嚴守型別安全？

案例研究：貨幣類別 USD

初始設計：轉換運算子到 double

class USD {
    __int64 dollars;
    int cents;
public:
    USD(__int64 d=0, int c=0) : dollars(d), cents(c) {}
    // 隱式轉換運算子
    operator double() {
        double temp = (dollars * 100) + cents;
        return temp / 100;
    }
};

使用便利：

USD payment(203, 67);  // $203.67
double res = payment * 1.05; // 自動轉換 → 213.8535 ✅

災難場景：賦值回原物件

payment = payment * 1.05; // ❌ 結果變成 $213.00 (丟失美分！)

原因剖析：

1. payment * 1.05 觸發轉換運算子 → double 213.8535。
2. 賦值 payment = 213.8535 需轉換回 USD。
3. 編譯器隱式呼叫建構子 USD(__int64(213.8535), 0) → dollars=213, cents=0。
4. 小數部分被靜默截斷！

解決方案：雙重防線

防線一：explicit 建構子——阻擋隱式建構

class USD {
    // ...
public:
    explicit USD(__int64 d=0, int c=0) : dollars(d), cents(c) {} // 禁止隱式建構
    // ...
};

效果：

payment = USD(payment * 1.05); // ✅ 顯式建構，編譯通過
payment = payment * 1.05;      // ❌ 編譯錯誤：無隱式建構路徑

防線二：精確的 double 建構子——正確處理小數

class USD {
    // ...
public:
    explicit USD(double val) {
        dollars = static_cast<__int64>(val);          // 整數部分
        long double temp = (val - dollars) * 100;     // 小數部分 ×100
        cents = static_cast<int>(temp + 0.5);         // 四捨五入避免截斷誤差
    }
};

現在 USD(payment * 1.05) 正確構造 $213.85 (四捨五入)。

標準庫的選擇：安全優先

• std::string 無 const char* 轉換運算子，強制用 .c_str()，避免 C API 混用導致 bug。
• fstream 有 operator void*() (或 explicit operator bool() C++11)，支援 if (inf) 判斷流狀態，風險可控。

設計準則：啟用/禁用清單

現代 C++ (C++11+) 增強

• explicit operator bool()：顯式轉換運算子，僅在布林語境 (if, while, !) 隱式觸發，其他場合需 static_cast，完美解決「安全布林判斷」需求。
• 刪除函數 = delete：徹底禁用特定轉換/建構路徑。

掌握轉換運算子與 explicit 的配合，即掌握了 C++ 型別系統的「閘門控制權」——讓合法轉換暢通無阻，將危險隱式轉換拒之門外。