我的老師不像其他人那樣打字。 有誰知道他在做什么？

Question

我的老師在我們的一個鑄造示例中包含了以下幾行。 c是Circle類的對象，它繼承自Point類。 在我尋找“我可以將Point類的對象轉換為Circle類型嗎？”這個問題的答案時我發現他使用的語法與我訪問過的每個網站都不同。 這些網站都使用static_cast和dynamic_cast語法。 他不會在測試中使用 static_cast 和 dynamic_cast，我只是想知道他在使用什么以及它是如何運作的。

另外，如果您對我是否可以將基礎對象強制轉換為派生類型有答案，我非常感謝您。

output << "the center of the circle is at " << (Point) c; 
// casting `Circle` object `c` with type `(Point)`, calls the first overloaded >stream insertion operator"

Answer 1

(Point)c被稱為“C 風格”類型轉換。 這基本上可以被認為是一種蠻力施法，它盡其所能使施法成功。 這意味着它最終可能導致static_cast 、 const_cast甚至reinterpret_cast 。

當遇到 C 風格的強制轉換表達式時，編譯器嘗試將其解釋為以下強制轉換表達式，按以下順序：

• const_cast
• static_cast
• static_cast 后跟 const_cast
• reinterpret_cast
• reinterpret_cast 后跟 const_cast

來源： https : //en.cppreference.com/w/cpp/language/explicit_cast

來自 Stroustrup 本人：

最好避免顯式類型轉換（通常稱為強制轉換以提醒您它們用於支撐損壞的東西）。

和

C 風格的強制轉換應該被棄用，取而代之的是命名強制轉換。

Stroustrup, Bjarne。 C++ 之旅（C++ 深入系列）（Kindle 位置 7134）。 培生教育。 Kindle版。

所以推薦使用命名演員表。 在實踐中，我仍然會遇到使用 C 風格強制轉換的專業代碼，因為它使代碼更加簡潔和可讀，而且——如果你知道自己在做什么——通常在使用它的地方等同於static_cast 。 就其價值而言，我認為 C 風格的強制轉換是可以的，如果出於這些原因在上下文中使用它，這很明顯會導致static_cast ，而 Stroustrup 是從過度面向對象的角度來看他對強制轉換的普遍蔑視。 但是您應該更喜歡命名的演員表。

你的老師可能正在使用 C 風格的演員表作為一個看起來不那么可怕的演員表介紹。

Answer 2

到目前為止的答案沒有涵蓋(Point) c; 實際上確實如此。 假設Circle沒有明確定義operator Point ：

這與static_cast<Point>(c) 。 它創建一個臨時Point對象，該對象由Point的復制構造函數初始化，並以c作為參數。 這是有效的，因為無論好壞，基類復制構造函數都可以綁定到派生對象。

需要明確的是，它不是對Circle的Point部分的任何類型的引用。 它正在制作Circle的Point部分的副本。 這稱為切片。 它丟失了信息的所有“圓圈”部分。

我建議不要這樣做。 如果沒有演員，代碼會更好。 我想也許Point和Circle都定義了operator<<重載，他想明確選擇Point 1； 在這種情況下，您應該使用static_cast<Point&>(c)或等效的(Point&)c來查看圓而不是切片。

注意。 首先從 Point 推導出 Circle 也是可疑的； 繼承應該代表“is-a”關系（而不是“has-a”）； 但圓不是一個點。

進一步閱讀： 什么是對象切片？

Answer 3

這是一個 C 風格的轉換，如果可用，將使用“c.operator Point()”，否則它的行為與“reintrepret_cast(c)”相同