標量類型和運算符重載的成員函數

Question

我一直在想C++可能有的一些可能的功能，有誰知道他們爲什麼不被支持？

1. 內置類型的成員函數。這似乎不是必要的，但仍然是一個有趣的功能。僞代碼示例：int int::getFirstBit(void) {return *this & 1;} ... int a = 2; a.getFirstBit();這看起來可能沒有用處，但也不難實現。由此產生以下想法：
2. 成員函數在類定義之外。我不明白爲什麼這不應該被支持，除了與訪問限制（公共，保護，私人等）和封裝的衝突，但也許只有structs可以有這個功能。
3. 運算符爲非對象類型重載，這可能是用於指針或數組。

我知道這些功能不是非常必要，但它們看起來還是很酷的。是因爲他們似乎不必要或因爲他們會引起許多頭痛？

Answer 1

我知道這些功能不需要太多，但他們似乎仍然很酷。是因爲他們似乎不必要或者因爲他們會引起許多頭痛？

其他部分的一部分。添加到語言中的每個新功能都會增加語言，編譯器和程序的複雜性。一般來說，除非有真正的激勵需求（或者新功能有助於編寫更簡單更安全的程序），否則不會添加功能。

由於特定的功能，你建議：

1-成員函數內建類型

沒有必要，你可以做你想做與自由函數的成員函數做什麼相同的成本和用戶代碼的唯一區別是函數的參數在.之前或括號內。

唯一不能用自由函數完成的事情是動態分派（多態），但既然你不能從這些類型派生，你也不能有多態性。再次，爲了能夠做到這一點，您需要2.

2-成員函數在類定義之外。

我知道你的意思是擴展方法與C＃一樣，可以將新方法添加到外部類型中。這個功能的用途很少，如果沒有它，就不夠簡單。然後是複雜性。

目前，編譯器看到類的單一定義，並且能夠確定可應用到該類型的元件的所有部件的方法。這包括virtual功能，這意味着，編譯器可以在一旦確定虛擬函數表（而虛表不是標準，所有的實現使用它們）。如果您可以在類定義之外添加虛擬方法，則不同的翻譯單元會看到不同類型的不兼容視圖。調度到第三個虛函數可能會在一個.cpp文件中調用foo，但在另一箇中調用bar。解決這個問題時，如果不將鏈接階段的大部分推遲到將二進制文件加載到內存中執行，這幾乎是不可能的，推遲它將意味着語言模型的重大變化。

如果限制功能非虛函數，事情變得更簡單的通話將被直接調度的功能，但儘管如此，即使這將意味着複雜的其他水平。使用C++中的單獨編譯模型，您最終必須爲原始類和擴展方法編寫標頭，並將它們都包含在要使用它的翻譯單元中，在大多數情況下，您可以簡化在原始頭文件中將這些相同的方法聲明爲真正的成員方法（或者自由函數，自由函數構成用戶定義類型的接口的一部分！）

此外，允許這將意味着代碼中的簡單拼寫錯誤可能意外結果。目前，編譯器驗證成員函數的定義是否具有正確的聲明，如果允許這種檢查將被刪除，並且在聲明或定義中寫入名稱時出現簡單的錯字將導致兩個單獨的函數而不是快速修復編譯器錯誤。對於非對象類型

語言

3-運算符重載允許對所有用戶定義的類型，其中包括類和枚舉運營商的過載。對於其餘類型，有一組已經定義好的精確語義不能改變的運算符。再次，對於單獨的編譯模型，這意味着1+2在不同的翻譯單元中可能意味着不同的東西，特別是includes的精確組合可能會改變程序的語義，並且這會造成嚴重破壞 - 您會刪除頭中的依賴項，並且，消除了包括包含該過載const char* + int，這反過來又意味着在"Hi" + 2代碼，包括您的標題的變化，從用戶定義的操作，以得到一個指針到該字符串的NUL終止子的語義。這是真的危險，因爲它意味着程序的一部分中的簡單更改可能會導致程序的其他部分不正確。

即使組合針對當前沒有意義（char* + int*），您可以使用普通的功能，以提供相同的操作。請記住，你應該只重載操作時，在你模擬該操作的領域自然理解爲具有特定的語義，這就是爲什麼你可以過載對於用戶定義類型，但指針是不是你的域的一部分，而是語言的一部分，並且在語言中沒有對於什麼意思的自然定義。運算符重載的目的是使代碼更具可讀性，並且在沒有自然定義的任何上下文中，運算符重載具有完全相反的效果。

Answer 2

1. 因爲你可以寫一個自由的函數來做同樣的事情。 「成員函數」是否會更加可取，以抵消在標準中批准這個標準並讓編譯器供應商實現它的巨大成本？
2. 外面的地方到底在哪？
3. 請1.