要實現屬性與否？

我發現了一些關於如何在C++中實現類屬性功能的方法。似乎有一些合理的解決方法可以使其正常工作。要實現屬性與否？

我的問題是，隨着管理語言中屬性的流行，我是否應該花費精力和代碼破壞（或其他）來實現代碼中屬性的可能性？

假設我要爲其他人使用調用庫，是否需要足夠的屬性來驗證額外的代碼？

2010-06-29 Veaviticus

除非您在混合中添加反射（能夠在運行時識別對象上存在哪些屬性），屬性無非是getter和setter的語法糖。在這種情況下，不妨使用getter和setter。儘管如此，使用反射的屬性確實可以用於C++程序。 Qt處理這個quite nicely。

2010-06-29 17:52:43 Cogwheel

+1，但我不同意QT處理它很好。任何人都可以通過一個單獨的編譯器/預處理器來處理反射/內省，該編譯器/預處理器增加了C++語言的擴展。 – stinky472 2010-06-29 23:13:08

@ stinky472：沒錯，但他們也可能做得很糟糕。 ;）我只是覺得Qt的實現本身就很好。 – Cogwheel 2010-07-01 20:55:30

這樣做你可以從使用訪問器函數中獲得什麼？在我看來，編碼時應該發揮語言的優勢，而不是模仿其他語言。所以我會對這個沒有投票。但是，如果您正在使用MANAGED C++編寫代碼，並且要定期使用此代碼與C＃進行交互，並且由於某種原因，您希望使本機C＃程序員更容易使用後端，則可能是值得的。

2010-06-29 17:51:15 Rokujolady

這更多的只是句法性質。我目前正在與一些主要使用c＃編寫的朋友一起開發一個項目，而我主要使用C++。該項目是在標準的C++，但他們抱怨缺乏屬性。 – Veaviticus 2010-06-29 18:21:13

類似於屬性的私有成員訪問器的一個優點：您可以參考它。 – 2010-06-29 20:45:30

@Mike：如果希望擁有「像C＃這樣的屬性」，這是不相關的，因爲你不能在C＃中引用（或通過引用等）屬性。 – 2010-06-29 22:47:10

如果正確完成，屬性實際上可以防止代碼被破壞。它允許您更改下面的屬性的實現，而無需調用者更改其代碼，甚至不用擔心。

例如，假設您有一個Socket類，它帶有一個套接字號。作爲一個屬性來實現一個int並存儲它。

但是你的老闆說你不應該接受低於1024的套接字號。你的屬性可以改變爲掃描並且不接受這個值。

對調用者代碼沒有改變。

編輯：對問題的輕微誤解......我將屬性表示爲正常的存取函數。

2010-06-29 17:52:07

如果你的答案與問題無關，那麼你應該刪除它。 – 2010-06-29 17:58:47

屬性不是慣用的標準C++ - 這一事實證明，沒有任何單一的「屬性」庫被廣泛使用。在合規的C++中正確實現它們的複雜性是非常重要的，與直接調用訪問器方法相比，它的好處很小，而且主要是風格。在我看來，這不值得費心。

2010-06-29 17:55:54

QT具有相當廣泛的用途。我不特別關心它，但反射對於通過屬性編輯器設計小部件非常有用。 – stinky472 2010-06-29 23:14:24

Qt僅將屬性用作元數據概念（以配對獲取者和設置者）。它們沒有在客戶端代碼中公開 - 你仍然是手動調用訪問器爲'name（）'和'setName（）'等。問題看起來像屬性作爲語法糖（如在C＃中）。 – 2010-06-30 00:02:56

我曾經試圖在C++中實現類似於Matlab結構的東西，即可以添加命名字段的結構。在此之後，我成爲堅定的信奉「不與語言打架」的原則。

2010-06-29 17:56:48 Dima

努力使一種編程語言像另一種編程語言一樣行爲通常是inner platform effect的特例。

我同意他人 - 只是使用getters和setter。

如果您真的需要C++中的屬性，也許您已經將它們作爲語言擴展。我認爲Visual C++的確 - 對於託管的C++來說，幾乎可以肯定的，但也可能是非託管的。就我個人而言，我使用它們的唯一原因是託管C++以適應.NET約定。

除此之外，爲此創建一個內部平臺幾乎肯定會導致比解決問題更多的問題。

2010-06-29 18:44:52 Steve314

回答